On Wed, Dec 14, 2011 at 10:34:45AM -0500, Josef Bacik wrote: > On Wed, Dec 14, 2011 at 10:14:13AM -0500, Phillip Susi wrote: > > On 12/14/2011 9:58 AM, Josef Bacik wrote: > > >There is no "underlying bug", there is a shitty situation, the shitty situation > > > > Maybe my assumptions are wrong somewhere then. You add the orphan > > item to make sure that the truncate will be finalized even if the > > system crashes before the transaction commits right? So if > > truncate() fails with -ENOSPC, then you shouldn't be trying to > > finalize the truncate on the next mount, should you ( because the > > call did not succeed )? > > > > Yes because otherwise we'll leak space since the i_size has been updated > already. The other option is to make btrfs_truncate_inode_items update i_size > as we truncate so if it fails we can delete the orphan item and then update the > inode with the new i_size, that way we don't leave the orphan item on disk and > we don't leak space. I'll see how doable this is. Thanks, If we fail with enospc though we're very likely to not be able to update the inode item. It may work, but the failure case will still be there where we can't make i_size match the file contents. -chris -- To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
