From: Andrew Morton <akpm@digeo.com>
To: Alan Cox <alan@lxorguk.ukuu.org.uk>
Cc: viro@parcelfarce.linux.theplanet.co.uk, torvalds@transmeta.com,
Andries.Brouwer@cwi.nl, linux-kernel@vger.kernel.org
Subject: Re: [patch?] truncate and timestamps
Date: Mon, 26 May 2003 18:17:33 -0700 [thread overview]
Message-ID: <20030526181733.2d43976e.akpm@digeo.com> (raw)
In-Reply-To: <1053992553.17151.18.camel@dhcp22.swansea.linux.org.uk>
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();
_
next prev parent reply other threads:[~2003-05-27 1:06 UTC|newest]
Thread overview: 13+ messages / expand[flat|nested] mbox.gz Atom feed top
2003-05-23 0:17 [patch?] truncate and timestamps Andries.Brouwer
2003-05-23 0:30 ` Linus Torvalds
2003-05-23 1:17 ` viro
2003-05-23 2:42 ` Andrew Morton
2003-05-23 5:11 ` Trond Myklebust
2003-05-23 5:25 ` Trond Myklebust
2003-05-23 3:14 ` David Schwartz
2003-05-26 23:42 ` Alan Cox
2003-05-27 1:17 ` Andrew Morton [this message]
2003-05-23 18:02 ` Kai Henningsen
2003-05-23 19:07 ` Andries Brouwer
-- strict thread matches above, loose matches on Subject: below --
2003-05-22 19:09 Andries.Brouwer
2003-05-22 23:20 ` Andrew Morton
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20030526181733.2d43976e.akpm@digeo.com \
--to=akpm@digeo.com \
--cc=Andries.Brouwer@cwi.nl \
--cc=alan@lxorguk.ukuu.org.uk \
--cc=linux-kernel@vger.kernel.org \
--cc=torvalds@transmeta.com \
--cc=viro@parcelfarce.linux.theplanet.co.uk \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).