Re: [patch?] truncate and timestamps

From: Andrew Morton (akpm@digeo.com)
Date: Mon May 26 2003 - 20:25:30 EST


Alan Cox <alan@xxxxxxxxxxxxxxxxxxx> wrote:
>
> On Gwe, 2003-05-23 at 02:17, viro@xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx
> 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();

_

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/