On 9/5/00, 5:26:29 AM, Daniel Phillips wrote
> 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
> > > 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.
I'm not against sending the old size, it could be useful. But, your
truncate operation wants to find the old size on its own. If the data in
the on disk stat data is at all out of date (likely if you allow the
dirty inode list to do your inode flushing, and have a crash) you need to
find the real size of the file before truncating it.
Of course, fsck fixes this, and logging (or phasing) the inode with each
file size modification should do the same, but if you're not fscking on
dirty mount, it is probably a good idea to verify the file size during a
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to firstname.lastname@example.org
Please read the FAQ at http://www.tux.org/lkml/
This archive was generated by hypermail 2b29 : Thu Sep 07 2000 - 21:00:22 EST