linux-kernel - Re: [PATCH 02/18] xstat: Add a pair of system calls to make extended file stats available [ver #6]

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-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <20100807093057.7683bedd@notabene>
Date:	Sat, 7 Aug 2010 09:30:57 +1000
From:	Neil Brown <neilb@...e.de>
To:	Steve French <smfrench@...il.com>
Cc:	Jeremy Allison <jra@...ba.org>, Jeff Layton <jlayton@...hat.com>,
	utz lehmann <lkml123@...4n2c.de>,
	Linus Torvalds <torvalds@...ux-foundation.org>,
	Volker.Lendecke@...net.de, David Howells <dhowells@...hat.com>,
	Jan Engelhardt <jengelh@...ozas.de>,
	linux-cifs@...r.kernel.org, linux-nfs@...r.kernel.org,
	samba-technical@...ts.samba.org, linux-kernel@...r.kernel.org,
	viro@...iv.linux.org.uk, linux-fsde@...per.es
Subject: Re: [PATCH 02/18] xstat: Add a pair of system calls to make
 extended  file stats available [ver #6]

On Thu, 5 Aug 2010 22:55:06 -0500
Steve French <smfrench@...il.com> wrote:

> On Thu, Aug 5, 2010 at 10:38 PM, Neil Brown <neilb@...e.de> wrote:
> > On Thu, 5 Aug 2010 16:52:18 -0700
> > Jeremy Allison <jra@...ba.org> wrote:
> 
> >> Don't add it as an EA. It's *not* an EA, it's a timestamp.
> >
> > I'm curious.  Why do you particularly care what interface the kernel uses to
> > provide you with access to this attribute?
> >
> > And given that it is an attribute that is not part of 'POSIX' or "UNIX", it
> > would seem to be an extension - an extended attribute.
> > As the Linux kernel does virtually nothing with this attribute except provide
> > access, it seems to be a very different class of thing to other timestamps.
> > Surely it is simply some storage associated with a file which is capable of
> > storing a timestamp, which can be set or retrieved by an application, and
> > which happens to be initialised to the current time when a file is created.
> >
> > Yes, to you it is a timestamp.  But to Linux it is a few bytes of
> > user-settable metadata.  Sounds like an EA to me.
> >
> > Or do you really want something like BSD's 'btime' which as I understand it
> > cannot be set.  Would that be really useful to you?
> 
> Obviously the cifs and SMB2 protocols which  Samba server support can
> ask the server to set the create time of a file (this is handled
> through xattrs today along with the "dos attribute" flags such as
> archive/hidden/system), but certainly it is much more common (and
> important) to read the creation time of an existing file.
> 

Just a point of clarification - when you say it is common and important to be
able to read the creation time on an existing file, and you still talking in
the context of cifs/smb windows compatibility, or are you talking in the
broader context?
If you are referring to a broader context could be please give more details
because I have not heard any mention of any real value of creation-time out
side of window interoperability - have such a use clearly documented would
assist the conversation I think.

If on the other hand you are just referring the the windows interoperability
context ... given that you have to read an EA if the create-time has been
changed, you will always have to read and EA so having something else is
pointless ... or I'm missing something.

> 
> > Is there something important that I am missing?
> 
> It is another syscall that Samba server would have to make - and xattr
> performance is extremely slow on some file systems (although
> presumably this one would be more likely to be stored in inode and
> perhaps not as bad on ext4, cifs and a few others such as ntfs).
> 
> 

Obviously if we were to make xattrs the preferred way to get create time out
of the filesystem we would want to make sure it is efficient.
It would seem to make perfect sense to add a 'getxattrat' syscall and allow an
AT_NONBLOCK flag (which would probably be useful for statat too).  The
AT_NONBLOCK flag would only get attributes if they were available immediately
without going to storage/network/whatever.

And if it is simply a case of too many syscalls per file, then
getxattrat_multi would seem to be the most general way to go.

NeilBrown
--
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/