Re: [patch?] truncate and timestamps

[Andrew Morton]

Alan Cox <[e-mail]> wrote:
>
> On Gwe, 2003-05-23 at 02:17, [e-mail]
> wrote:
> > Andries had shown that there is _no_ consensus.  Ergo, POSIX can take
> > a hike and we should go with the behaviour convenient for us.  It's that
> > simple...
> 
> Skipping the update on a truncate not changing size is a performance win
> although not a very useful one.

It makes the AIM7 & AIM9 numbers look good ;)

An open(O_TRUNC) of a zero-length file is presumably not totally uncommon,
so not calling into the fs there may benefit some things.

> I don't think we can ignore the standard
> however. For one it simply means all the vendors have to fix it so they
> can sell to Government etc. 

I think this patch will put us back to the 2.4 behaviour while preserving
the speedup.  It's a bit dopey (why do the timestamp update in the fs at
all?) but changing this stuff tends to cause subtle problems...

diff -puN fs/attr.c~truncate-timestamp-fix fs/attr.c
--- 25/fs/attr.c~truncate-timestamp-fix	2003-05-22 22:10:18.000000000 -0700
+++ 25-akpm/fs/attr.c	2003-05-22 22:14:06.000000000 -0700
@@ -68,10 +68,17 @@ int inode_setattr(struct inode * inode, 
 	int error = 0;
 
 	if (ia_valid & ATTR_SIZE) {
-		if (attr->ia_size != inode->i_size)
+		if (attr->ia_size != inode->i_size) {
 			error = vmtruncate(inode, attr->ia_size);
-		if (error || (ia_valid == ATTR_SIZE))
-			goto out;
+			if (error || (ia_valid == ATTR_SIZE))
+				goto out;
+		} else {
+			/*
+			 * We skipped the truncate but must still update
+			 * timestamps
+			 */
+			ia_valid |= ATTR_MTIME|ATTR_CTIME;
+		}
 	}
 
 	lock_kernel();

_