[lkml]   [2000]   [Sep]   [5]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
SubjectRe: [patchlet] Removing unneeded line in vmtruncate() (2.4.0-t8p1)

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
Please read the FAQ at

 \ /
  Last update: 2005-03-22 12:38    [W:2.144 / U:0.004 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site