lkml.org 
[lkml]   [2000]   [Sep]   [5]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
From
SubjectRe: [patchlet] Removing unneeded line in vmtruncate() (2.4.0-t8p1)
Date
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

--
Daniel
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
Please read the FAQ at http://www.tux.org/lkml/

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