Re: [RFC] [PATCH] ext3 nanosecond timestamps

On Jun 26, 2006  15:05 +0200, Andreas Gruenbacher wrote:
> > In addition to nanosecond timestamps (in earlier patches), this patch
> > uses the 2 remaining bits in the __u32 to extend the unix epoch on
> > 64-bit platforms.  This is done in an INCOMPATIBLE way with earlier
> > patches, so if those patches are in use anywhere (e.g. SLES?)
> 	Not on a SUSE/Novell product at least.

OK, good to hear.  I wasn't sure because you were the original author.

> > then it
> > would be important to know that.  The reason for the incompatible change
> > is that putting the epoch bits at the bottom gives us more flexibility
> > to shift the EXT3_EPOCH_BITS if we really need to do that in the future.
> > This is not a critical part of the change, and as yet this code is not
> > in use anywhere AFAIK so it can be modified.
> 
> At full resolution the nanoseconds require 30 bits, so two bits are available 
> for the epoch. We could give up some precision in favor of more epoch bits, 
> but this would be an incompatible change no matter how we split the fields. 
> So I don't object to using the format you propose, but I also don't see the 
> benefit compared to splitting off the two topmost bits.

True.  One of the reasons I did it this way was because originally I was
thinking to use 4 or 5 bits for the epoch and 28 or 27 for the ns part.

The reasoning is that I suspect this sort of packed format (sec+nsec in 64
bits) will become important in the future and we may as well get it right.
Even if the change is INCOMPAT to go to a larger epoch, at least the same
code can be used for all filesystems (i.e. make EPOCH_BITS a per-super
variable, should we need to do so).

Stephen also mentioned that CPU/clock speeds are increasing a great deal
and having high-resolution timestamps is probably more important than
having a larger epoch (for now at least ;-).

> > Index: linux-stage/fs/ext3/super.c
> > +		if (sbi->s_inode_size > EXT3_GOOD_OLD_INODE_SIZE)
> > +			sb->s_time_gran = 1 << (EXT3_EPOCH_BITS - 2);
> 
> Could you please test for s_inode_size >= sizeof(struct ext3_inode) instead?

No, because "sizeof(struct ext3_inode)" is growing as new fields are added.
The next s_inode_size multiple is 256 bytes, and we definitely will have the
timestamps within any inode larger than GOOD_OLD_INODE_SIZE.

> > Index: linux-stage/include/linux/ext3_fs.h
> >  	} osd2;				/* OS dependent 2 */
> >  	__le16	i_extra_isize;
> >  	__le16	i_pad1;
> > +	__le32	i_ctime_extra;	/* extra Change time      (nsec << 2 | epoch) */
> > +	__le32	i_mtime_extra;	/* extra Modification time(nsec << 2 | epoch) */
> > +	__le32	i_atime_extra;	/* extra Access time      (nsec << 2 | epoch) */
> > +	__le32  i_extra_reserved1;
> >  };
> 
> We can easily increment i_extra_isize to make room for more fields available, 
> so what is  i_extra_reserved1 good for?

I am of the same opinion, but Stephen and Ted think that even the nsec
timestamps are cause for concern because it is possible for inodes to have
the in-memory timestamps updated, but not the on-disk timestamps (due to
lack of space in the in-core inode from EAs, along with a full external EA
block) and that might confuse "make" or something.

They consider this important enough to want to reserve an extra field for
future use that will always be present (if RO_COMPAT_NS_TIMESTAMP is set).

> What bothers me is the number of inode updates due to atime-inly updates that 
> a sb->s_time_gran of 1 may have: with second granularity as we have 
> currently, there will be at most one inode atime update per second for each 
> inode (see fs/inode.c:touch_atime()). A higher time resolution will lead to 
> many more atime updates, and for some applications / access patterns, this 
> may become a real performace problem.
> 
> Do we really need the same level of consistency for atime updates as for
> other inode updates? Otherwise, how about figuring out a way of delaying
> atime updates for a while, or at least cancelling out atime-only updates
> when the  next atime-only update arrives?

I have no strong love for atime, and ns-resolution atime isn't very important
to me.  That said, there is no current mechanism to have different resolution
for atime updates than mtime and ctime.  touch_atime() also compares fs
resolution timestamps, so it will always mark the inode dirty, even if we
don't store it to disk.

> Alternatively, would sticking with second or so atime resolution (but not for 
> mtime and ctime) be an option? I can't think of anything that fundamentally 
> relies on the atime.

I think most apps are happy with atime resolution in the minutes range.
They really only want to know that a file HAS been accessed, but don't
particularly care exactly when.

Cheers, Andreas
--
Andreas Dilger
Principal Software Engineer
Cluster File Systems, Inc.


Using Tomcat but need to do more? Need to support web services, security?
Get stuff done quickly with pre-integrated technology to make your job easier
Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo
http://sel.as-us.falkag.net/sel?cmd=lnk&kid=120709&bid=263057&dat=121642