1From: "Aneesh Kumar K. V" <aneesh.kumar@linux.vnet.ibm.com> 2Subject: Re: [RFC][PATCH 06/10] cifs: define inode-level cache object and register them 3Date: Sun, 27 Jun 2010 23:47:21 +0530 4Lines: 100 5Message-ID: <871vbscpce.fsf@linux.vnet.ibm.com> 6References: <20100625125306.7f9b1966@tlielax.poochiereds.net> <4C24A606.5040001@suse.de> <1277220214-3597-1-git-send-email-sjayaraman@suse.de> <9822.1277312573@redhat.com> <22697.1277470549@redhat.com> <18628.1277502398@redhat.com> <20100625182651.36800d06@tlielax.poochiereds.net> <AANLkTilOTrHLvLv4XWYZO6xCnYZgYT7gO2M-oKZ6VvqM@mail.gmail.com> <OFB55E8EC7.E8DD23D5-ON8725774E.0004921E-8825774E.0004CC31@us.ibm.com> 7Mime-Version: 1.0 8Content-Type: text/plain; charset=utf-8 9Content-Transfer-Encoding: QUOTED-PRINTABLE 10Cc: David Howells <dhowells@redhat.com>, 11 Jeff Layton <jlayton@redhat.com>, 12 Jeff Layton <jlayton@samba.org>, linux-cifs@vger.kernel.org, 13 linux-fsdevel@vger.kernel.org, linux-kernel@vger.kernel.org, 14 samba-technical@lists.samba.org, 15 Suresh Jayaraman <sjayaraman@suse.de> 16To: Mingming Cao <mcao@us.ibm.com>, Steve French <smfrench@gmail.com>, 17 "DENIEL Philippe" <philippe.deniel@cea.fr> 18X-From: linux-kernel-owner@vger.kernel.org Sun Jun 27 20:18:00 2010 19Return-path: <linux-kernel-owner@vger.kernel.org> 20Envelope-to: glk-linux-kernel-3@lo.gmane.org 21Received: from vger.kernel.org ([209.132.180.67]) 22 by lo.gmane.org with esmtp (Exim 4.69) 23 (envelope-from <linux-kernel-owner@vger.kernel.org>) 24 id 1OSwQZ-0003Kh-Vu 25 for glk-linux-kernel-3@lo.gmane.org; Sun, 27 Jun 2010 20:18:00 +0200 26Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand 27 id S1754631Ab0F0SRq convert rfc822-to-quoted-printable (ORCPT 28 <rfc822;glk-linux-kernel-3@m.gmane.org>); 29 Sun, 27 Jun 2010 14:17:46 -0400 30Received: from e23smtp07.au.ibm.com ([202.81.31.140]:52430 "EHLO 31 e23smtp07.au.ibm.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org 32 with ESMTP id S1753837Ab0F0SRl convert rfc822-to-8bit (ORCPT 33 <rfc822;linux-kernel@vger.kernel.org>); 34 Sun, 27 Jun 2010 14:17:41 -0400 35Received: from d23relay05.au.ibm.com (d23relay05.au.ibm.com [202.81.31.247]) 36 by e23smtp07.au.ibm.com (8.14.4/8.13.1) with ESMTP id o5RIHbfJ012483; 37 Mon, 28 Jun 2010 04:17:37 +1000 38Received: from d23av03.au.ibm.com (d23av03.au.ibm.com [9.190.234.97]) 39 by d23relay05.au.ibm.com (8.13.8/8.13.8/NCO v10.0) with ESMTP id o5RIHW9f1130634; 40 Mon, 28 Jun 2010 04:17:32 +1000 41Received: from d23av03.au.ibm.com (loopback [127.0.0.1]) 42 by d23av03.au.ibm.com (8.14.4/8.13.1/NCO v10.0 AVout) with ESMTP id o5RIHVcR027534; 43 Mon, 28 Jun 2010 04:17:32 +1000 44Received: from skywalker.linux.vnet.ibm.com ([9.77.196.78]) 45 by d23av03.au.ibm.com (8.14.4/8.13.1/NCO v10.0 AVin) with ESMTP id o5RIHMFl027485; 46 Mon, 28 Jun 2010 04:17:24 +1000 47In-Reply-To: <OFB55E8EC7.E8DD23D5-ON8725774E.0004921E-8825774E.0004CC31@us.ibm.com> 48User-Agent: Notmuch/ (http://notmuchmail.org) Emacs/24.0.50.1 (i686-pc-linux-gnu) 49Sender: linux-kernel-owner@vger.kernel.org 50Precedence: bulk 51List-ID: <linux-kernel.vger.kernel.org> 52X-Mailing-List: linux-kernel@vger.kernel.org 53Archived-At: <http://permalink.gmane.org/gmane.linux.kernel/1003357> 54 55On Fri, 25 Jun 2010 17:52:24 -0700, Mingming Cao <mcao@us.ibm.com> wrot= 56e: 57>=20 58>=20 59> Steve French <smfrench@gmail.com> wrote on 06/25/2010 04:05:30 PM: 60>=20 61> > Steve French <smfrench@gmail.com> 62> > 06/25/2010 04:05 PM 63> > 64> > To 65> > 66> > Jeff Layton <jlayton@samba.org>, "Aneesh Kumar K.V" 67> > <aneesh.kumar@linux.vnet.ibm.com>, Mingming Cao/Beaverton/IBM@IBMUS 68> > 69> > cc 70> > 71> > David Howells <dhowells@redhat.com>, Suresh Jayaraman 72> > <sjayaraman@suse.de>, linux-cifs@vger.kernel.org, linux- 73> > fsdevel@vger.kernel.org, linux-kernel@vger.kernel.org, samba- 74> > technical@lists.samba.org, Jeff Layton <jlayton@redhat.com> 75> > 76> > Subject 77> > 78> > Re: [RFC][PATCH 06/10] cifs: define inode-level cache object and 79> > register them 80> > 81> > On Fri, Jun 25, 2010 at 5:26 PM, Jeff Layton <jlayton@samba.org> wr= 82ote: 83> > > 84> > > On Fri, 25 Jun 2010 22:46:38 +0100 85> > > David Howells <dhowells@redhat.com> wrote: 86> > > 87> > > > Jeff Layton <jlayton@samba.org> wrote: 88> > > > 89> > > > > Looks like it mostly uses the ctime. IMO, the mtime would be = 90a 91> better 92> > > > > choice since it changes less frequently, but I don't guess th= 93at it 94> > > > > matters very much. 95> > > > 96> > > > I'd've thought mtime changes more frequently since that's 97> > altered when data is 98> > > > written. =C2=A0ctime is changed when attributes are changed. 99> > > > 100> > > 101> > > IIUC, updating mtime for a write is also an attribute change, and= 102 that 103> > > affects ctime. According to the stat(2) manpage: 104> > > 105> > > =C2=A0 =C2=A0 =C2=A0 The field st_ctime is changed by writing or = 106by setting 107> > =C2=A0inode =C2=A0informa- 108> > > =C2=A0 =C2=A0 =C2=A0 tion (i.e., owner, group, link count, mode, = 109etc.). 110> > > 111> > > > Note that Ext4 appears to have a file creation time field in it= 112s 113> inode 114> > > > (struct ext4_inode::i_crtime[_extra]). =C2=A0Can Samba be made = 115to use 116> that? 117> > > > 118> > > 119> > > Is it exposed to userspace in any (standard) way? It would be han= 120dy to 121> > > have that. While we're wishing...it might also be nice to have a 122> > > standard way to get at the i_generation from userspace too. 123> > > 124> > 125> > Yes - I have talked with MingMing and Aneesh about those (NFS may 126> > someday be able to use those too).=C2=A0 An obstacle in the past ha= 127d been 128> > that samba server stores its own fake creation time in an ndr encod= 129ed 130> > xattr which complicates things. 131> > 132> > MingMing/Annesh - 133> > Xattr or other way to get at birth time? 134> > 135> > 136>=20 137> Not yet, 138> The ext4 file creation time only accesable from the kernel at the mo= 139ment. 140> There were discussion 141> to make this information avaliable via xattr before, but was rejected= 142, 143> since most people 144> agree that making this info avalibele via stat() is more standard. Ho= 145wever 146> modifying stat() would imply 147> big interface change. thus no action has been taken yet. 148 149NFS ganesha pNFS also had a requirement for getting i_generation and 150inode number in userspace. So may be we should now look at updating 151stat or add a variant syscall that include i_generation and create time 152in the return value 153 154-aneesh 155 156 157