Prev: nfs client hang
Next: [PATCH net-next] sysfs: add attribute to indicate hw address assignment type
From: Jeremy Allison on 22 Jul 2010 14:10
On Thu, Jul 22, 2010 at 08:05:00PM +0200, Jan Engelhardt wrote:
>
> On Thursday 2010-07-22 20:02, Jeremy Allison wrote:
> >On Thu, Jul 22, 2010 at 12:58:50PM -0400, Trond Myklebust wrote:
> >>
> >> That would make it impossible to export the filesystem with NFSv2 and
> >> v3. They do rely on ctime checking for certain operations (e.g. deciding
> >> when to invalidate access and acl caches). NFSv4 needs this too if the
> >> filesystem has no dedicated change attribute.
> >>
> >> Still, I suppose the market for exporting the same filesystem with both
> >> NFS and Samba is limited...
> >
> >Ask NetApp about that :-). They have built a rather large
> >business on just that fact :-).
>
> What would ZFS do? :p

Get sued out of existence by software patent trolls who have lost
the ability to write code, apparently :-).
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo(a)vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
From: Jeremy Allison on 22 Jul 2010 14:20
On Thu, Jul 22, 2010 at 10:24:17AM -0700, Linus Torvalds wrote:
>
> And yes, I am also sure that there are applications that do depend on
> ctime semantics. Trond mentioned NFS serving, and that's unfortunate.
> I bet there are others. That's inevitable when you have 40 years of
> history. So I'm not claiming that re-using ctime is painfree, but for
> somebody that cares about samba a lot, I bet it's a _lot_ better than
> adding a new time that almost nobody actually supports as things stand
> now.

Samba mostly ignores ctime, for just the reasons you mention.
But re-using ctime as create time will lead to more horrible
confusion (IMHO).

Easier to add a btime field to stat (or whatever you want to
call it), especially as some of the filesystems already support it,
the code for it exists inside Samba and is working on other UNIX-style
OS'es, and for filesystems that don't support it, just return
zero or -1 in that field (which we already ignore).

> Of people can just use xattrs and do it all entirely in user space. I
> assume that's what samba does now, even outside of birthtime.

Yep. We even have to do that on systems with an immutable
btime to get Windows semantics.

Jeremy.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo(a)vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
From: Ted Ts'o on 22 Jul 2010 21:30
On Fri, Jul 23, 2010 at 11:03:47AM +1000, tridge(a)samba.org wrote:
>
> The other big difference from POSIX timestamps is that the
> CreationTime is settable on Windows, and some of the windows UI
> behaviour relies on this.

Well, not POSIX, because POSIX doesn't have CreationTime at all.
BSD's birthtime doesn't allow it to be set, and the question here is
largely philosophical. Does it literally mean "file creation time" in
terms of when the OS created the file, or does it mean "file" in the
sense of application contents. For example, if an application edits
the file and saves it out using "write file to foo.new; sync; rename
foo to foo.bak; rename foo.new to foo", should the creation time for
the newly written file "foo" be the time when the editor saved out the
file (i.e., when "foo.new" was created), or copied from the original
file "foo"'s creation time.

This is something (whether or not the application is allowed to set
the creation time) that I think makes sense to be either a filesystem
level mount option, or superblock tunable, or even a per-process
personality flag.

However, I think Linus's idea of using a per-process flag to control
whether or not "ctime" has the original POSIX semantics or some new
"creation time" semantics would lead to a huge amount of confusion.
Given that a number of new filesystems, including both ext4 and btrfs,
have creation time, it makes sense for us to have a fourth timestamp.
Whether or not our creation time is settable or not is a separate
question, and I don't think we need to follow BSD's lead on this. If
GNOME and/or KDE applications start using it, I could see this
becoming that gets wide adoption fairly quickly.

- Ted

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo(a)vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
From: tridge on 22 Jul 2010 22:20
Hi Ted,

> Does it literally mean "file creation time" in terms of when the OS
> created the file, or does it mean "file" in the sense of
> application contents. For example, if an application edits the
> file and saves it out using "write file to foo.new; sync; rename
> foo to foo.bak; rename foo.new to foo", should the creation time
> for the newly written file "foo" be the time when the editor saved
> out the file (i.e., when "foo.new" was created), or copied from the
> original file "foo"'s creation time.

In Windows this is can be controlled by applications, but it also is
done at the filesystem level in NTFS using a technique that Microsoft
call "File System Tunneling". If you create a file with the same name
within a short time (default 15s and settable in the registry) of when
the file previously existed then it will get the same CreationTime as
the previous file.

For details see http://support.microsoft.com/kb/172190

Some applications also do this regardless of the registry setting for
MaximumTunnelEntryAgeInSeconds. They use the ability to set the
CreationTime to get the same behaviour.

Cheers, Tridge
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo(a)vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
From: Björn Jacke on 23 Jul 2010 05:30
On 2010-07-22 at 21:21 -0400 Ted Ts'o sent off:
> Well, not POSIX, because POSIX doesn't have CreationTime at all.
> BSD's birthtime doesn't allow it to be set, and the question here is
> largely philosophical.

actually, it can (partly :). But the way it can be done is an insane hack:

<quote "http://ace.delos.com/kirk/">
To provide a sensible birth time for applications that are unaware of the birth
time attribute, we changed the semantics of the "utimes" system call so that if
the birth time was newer than the value of the modification time that it was
setting, it sets the birth time to the same time as the modification time. An
application that is aware of the birth time attribute can set both the birth
time and the modification time by doing two calls to "utimes". First it calls
"utimes" with a modification time equal to the saved birth time, then it calls
"utimes" a second time with a modification time equal to the (presumably newer)
saved modification time.
</quote>

Thus it can also be only be set more in the past.

Cheers
Bj�rn
--
SerNet GmbH, Bahnhofsallee 1b, 37081 G�ttingen
phone: +49-551-370000-0, fax: +49-551-370000-9
AG G�ttingen, HRB 2816, GF: Dr. Johannes Loxen
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo(a)vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
First  |  Prev  |  Next  |  Last
Pages: 1 2 3 4
Prev: nfs client hang
Next: [PATCH net-next] sysfs: add attribute to indicate hw address assignment type