Re: [RFC] [PATCH] ext3 nanosecond timestamps

Hi Andreas,

On Wednesday, 21 June 2006 21:03, Andreas Dilger 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.
> 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.

> 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?

> 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?

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?

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.

Andreas

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