Messages in this thread | | | From | Daniel Phillips <> | Subject | Re: [patch] Updated ext2 to use new mark_buffers_dirty interface | Date | Tue, 05 Sep 2000 14:22:12 +0200 |
| |
(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 majordomo@vger.kernel.org Please read the FAQ at http://www.tux.org/lkml/
| |