Re: [patchlet] Removing unneeded line in vmtruncate() (2.4.0-t8p1)

From: Daniel Phillips (news-innominate.list.linux.kernel@innominate.denews-innominate.list.linux.fsdev)
Date: Tue Sep 05 2000 - 04:26:29 EST

Alexander Viro wrote:
> On Fri, 1 Sep 2000, Tigran Aivazian wrote:
> > Rasmus, you introduced a bug because you removed the code but left the
> > comment around. now /* this should go into ->truncate */ is there and very
> > confusing - what should go into ->truncate?
> ... except that comment is there for purpose. Expanding ->truncate()
> should not set ->i_size until it's done with the metadata. You don't want
> mappings on the part currently being expanded. It doesn't matter for ext2
> and friends, but it's a problem for FAT and friends.

Ah, I'm glad I stumbled on this message because I was just getting
ready to make an argument about why setting ->i_size shouldn't be done
in vmtruncate, at least not before the fs-specific truncate is done.
OK, I'll summarize here anyway: as it stands, a valuable piece of
information - the previous size of the file - is getting stepped on
just before inode->i_op->truncate(inode) gets called. This leads to
some messy posturing if you need to know the old size before going to
the new size.

The clean solution would be:

  inode->i_op->truncate(inode, offset);

Which means changing every filesystem, and also breaking out-of-kernel
filesystems, albeit in a nice easy-to-understand way.

Setting ->i_size could then be done as the last step in vmtruncate, or
the fs could could do it and vmtruncate could check to ensure it was
done - it doesn't make much difference. But having the old size
available does make an awful lot of difference.

Is this change imminent/done, or should I go ahead and do my
just-for-now workaround?

*** sighs and gets out the hacksaw

To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to
Please read the FAQ at

This archive was generated by hypermail 2b29 : Thu Sep 07 2000 - 21:00:22 EST