On Oct 05, 2006 15:57 +0200, Bj�rn JACKE wrote:
> I would like to know if there are any plans to introduce a creation
> timestamp in future ext3/4 versions. Having a 4th timestamp saving the
> creation time would be very good for projekts like Samba for example.
> It would be important that creation time can also be set manually
> later on by some system call. Systems like FreeBSD's UFS and Solais'
> ZFS already support creation times. Unfortunately Linux doesn't have
> such a thing standarized anywhere but it would be geat if it would.
>
> Are there any plans to add this?
I've given this some thought for adding as part of the nsec timestamp
patch. That is more feasable if we move the nsec ctime into the main
inode to double as the version field.
Cheers, Andreas
--
Andreas Dilger
Principal Software Engineer
Cluster File Systems, Inc.
On Thu, Oct 05, 2006 at 09:19:37AM -0600, Andreas Dilger wrote:
> On Oct 05, 2006 15:57 +0200, Bj�rn JACKE wrote:
> > I would like to know if there are any plans to introduce a creation
> > timestamp in future ext3/4 versions. Having a 4th timestamp saving the
> > creation time would be very good for projekts like Samba for example.
> > It would be important that creation time can also be set manually
> > later on by some system call. Systems like FreeBSD's UFS and Solais'
> > ZFS already support creation times. Unfortunately Linux doesn't have
> > such a thing standarized anywhere but it would be geat if it would.
> >
> > Are there any plans to add this?
>
> I've given this some thought for adding as part of the nsec timestamp
> patch. That is more feasable if we move the nsec ctime into the main
> inode to double as the version field.
Shoehorning an extra creation time field into the inode is relatively
easy, but it's also necessary to have system calls to get and set the
creation time. The stat structure doesn't have room for the creation
time, so that means a new version of the stat structure exported the
kernel, and a new version of the stat structure exported by glibc.
So there are VFS and glibc changes necessary to make this be useful.
But that doesn't prevent us from reserving space in the inode and
starting to fill it in with the creation time, although it may be
quite a while before it will be easily available to user programs like
Samba.
- Ted
On 2006-10-05 at 12:55 -0400 Theodore Tso sent off:
> > I've given this some thought for adding as part of the nsec timestamp
> > patch. That is more feasable if we move the nsec ctime into the main
> > inode to double as the version field.
>
> Shoehorning an extra creation time field into the inode is relatively
> easy, but it's also necessary to have system calls to get and set the
> creation time. The stat structure doesn't have room for the creation
> time, so that means a new version of the stat structure exported the
> kernel, and a new version of the stat structure exported by glibc.
>
> So there are VFS and glibc changes necessary to make this be useful.
> But that doesn't prevent us from reserving space in the inode and
> starting to fill it in with the creation time, although it may be
> quite a while before it will be easily available to user programs like
> Samba.
yes, probably. But it's a reasonable effort to start that at some
time. It's good if ext3 developers have it in mind already now.
Should I open a feature request at bugzilla.kernel.org for the needed
VFS changes?
Bjoern
On Oct 05, 2006 12:55 -0400, Theodore Tso wrote:
> > I've given this some thought for adding creation time as part of the nsec
> > timestamp patch. That is more feasable if we move the nsec ctime into
> > the main inode to double as the version field.
>
> Shoehorning an extra creation time field into the inode is relatively
> easy, but it's also necessary to have system calls to get and set the
> creation time. The stat structure doesn't have room for the creation
> time, so that means a new version of the stat structure exported the
> kernel, and a new version of the stat structure exported by glibc.
For Lustre and NFSv4, an in-kernel interface is sufficient.
I was thinking that as a preliminary userspace interface we can use
getxattr with a standard name like user.crtime. Storing the crtime
directly in the inode is more efficient than a separate EA, but it would
also be compatible if Samba wanted to use real EAs to store this in the
absence of large inodes.
Cheers, Andreas
--
Andreas Dilger
Principal Software Engineer
Cluster File Systems, Inc.