Messages in this thread |  | | From | Daniel Phillips <@innominate.de> | Subject | Re: [patchlet] Removing unneeded line in vmtruncate() (2.4.0-t8p1) | Date | Tue, 05 Sep 2000 11:26:29 +0200 |
| |
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/
|  |