lists.openwall.net   lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  yescrypt  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  linux-hardening  linux-cve-announce  PHC 
Open Source and information security mailing list archives
 
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [thread-next>] [day] [month] [year] [list]
Message-ID: <871vbscpce.fsf@linux.vnet.ibm.com>
Date:	Sun, 27 Jun 2010 23:47:21 +0530
From:	"Aneesh Kumar K. V" <aneesh.kumar@...ux.vnet.ibm.com>
To:	Mingming Cao <mcao@...ibm.com>, Steve French <smfrench@...il.com>,
	"DENIEL Philippe" <philippe.deniel@....fr>
Cc:	David Howells <dhowells@...hat.com>,
	Jeff Layton <jlayton@...hat.com>,
	Jeff Layton <jlayton@...ba.org>, linux-cifs@...r.kernel.org,
	linux-fsdevel@...r.kernel.org, linux-kernel@...r.kernel.org,
	samba-technical@...ts.samba.org,
	Suresh Jayaraman <sjayaraman@...e.de>
Subject: Re: [RFC][PATCH 06/10] cifs: define inode-level cache object and register them

On Fri, 25 Jun 2010 17:52:24 -0700, Mingming Cao <mcao@...ibm.com> wrote:
> 
> 
> Steve French <smfrench@...il.com> wrote on 06/25/2010 04:05:30 PM:
> 
> > Steve French <smfrench@...il.com>
> > 06/25/2010 04:05 PM
> >
> > To
> >
> > Jeff Layton <jlayton@...ba.org>, "Aneesh Kumar K.V"
> > <aneesh.kumar@...ux.vnet.ibm.com>, Mingming Cao/Beaverton/IBM@...US
> >
> > cc
> >
> > David Howells <dhowells@...hat.com>, Suresh Jayaraman
> > <sjayaraman@...e.de>, linux-cifs@...r.kernel.org, linux-
> > fsdevel@...r.kernel.org, linux-kernel@...r.kernel.org, samba-
> > technical@...ts.samba.org, Jeff Layton <jlayton@...hat.com>
> >
> > Subject
> >
> > Re: [RFC][PATCH 06/10] cifs: define inode-level cache object and
> > register them
> >
> > On Fri, Jun 25, 2010 at 5:26 PM, Jeff Layton <jlayton@...ba.org> wrote:
> > >
> > > On Fri, 25 Jun 2010 22:46:38 +0100
> > > David Howells <dhowells@...hat.com> wrote:
> > >
> > > > Jeff Layton <jlayton@...ba.org> wrote:
> > > >
> > > > > Looks like it mostly uses the ctime. IMO, the mtime would be a
> better
> > > > > choice since it changes less frequently, but I don't guess that it
> > > > > matters very much.
> > > >
> > > > I'd've thought mtime changes more frequently since that's
> > altered when data is
> > > > written.  ctime is changed when attributes are changed.
> > > >
> > >
> > > IIUC, updating mtime for a write is also an attribute change, and that
> > > affects ctime. According to the stat(2) manpage:
> > >
> > >       The field st_ctime is changed by writing or by setting
> >  inode  informa-
> > >       tion (i.e., owner, group, link count, mode, etc.).
> > >
> > > > Note that Ext4 appears to have a file creation time field in its
> inode
> > > > (struct ext4_inode::i_crtime[_extra]).  Can Samba be made to use
> that?
> > > >
> > >
> > > Is it exposed to userspace in any (standard) way? It would be handy to
> > > have that. While we're wishing...it might also be nice to have a
> > > standard way to get at the i_generation from userspace too.
> > >
> >
> > Yes - I have talked with MingMing and Aneesh about those (NFS may
> > someday be able to use those too).  An obstacle in the past had been
> > that samba server stores its own fake creation time in an ndr encoded
> > xattr which complicates things.
> >
> > MingMing/Annesh -
> > Xattr or other way to get at birth time?
> >
> >
> 
> Not yet,
>  The ext4 file creation time only accesable from the kernel at the moment.
> There were discussion
> to make this information avaliable via xattr before, but was rejected,
> since most people
> agree that making this info avalibele via stat() is more standard. However
> modifying stat() would imply
> big interface change. thus no action has been taken yet.

NFS ganesha pNFS also had a requirement for getting i_generation and
inode number in userspace. So may be we should now look at updating
stat or add a variant syscall that include i_generation and create time
in the return value

-aneesh
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ