Hi, On Fri, 2002-12-06 at 20:41, Andrew Morton wrote: > OK, I think I see what happened. > > In ext3_dirty_inode(), we open a transaction which reserves just > a single disk block. Because that is all we expect to write. > > But when you get all the way down to ext3_do_upodate_inode(), > the corrupted inode data leads the filesytem to think that > the file has a size larger than 2G. > > This triggers the logic in ext3_do_update_inode() which updates > the superblock to say "this filesystem now has files which are > larger than 2G". > > But that requires a journalled superblock write. We didn't > reserve a second block in the transaction for that, and blam. > A robust fix for this is to update all callers of ext3_do_update_inode() > to reserve an additional block for that eventuality. Most callers already have it. EXT3_SINGLEDATA_TRANS_BLOCKS already includes the superblock, because data-touching operations already need to include updates to the free-blocks counts in the sb. So most of the paths really should be safe: when a file initially becomes that large, we should be accounting for an sb write already. But in the case where the sb state is incorrect when we get a mark_inode_dirty(), we need to be able to correct it there, so I think it's actually more correct simply to reserve the extra block just inside ext3_dirty_inode()'s transaction. Cheers, Stephen _______________________________________________ Ext3-users@redhat.com https://listman.redhat.com/mailman/listinfo/ext3-users
