(reposted with non-mangled From address)
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 [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/
