Messages in this thread Patch in this message | | | Date | Mon, 26 May 2003 18:17:33 -0700 | From | Andrew Morton <> | Subject | Re: [patch?] truncate and timestamps |
| |
Alan Cox <alan@lxorguk.ukuu.org.uk> wrote: > > On Gwe, 2003-05-23 at 02:17, viro@parcelfarce.linux.theplanet.co.uk > 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@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
| |