On 12/14/2011 10:27 AM, Josef Bacik wrote:
Except consider the case that the program was written intelligently and checks for errors on truncate. So he writes 100G, truncates to 50M, and the truncate fails and he closes the file and exits. Then somewhere down the road the inode is evicted from cache and we reboot the box. Next time the box comes up it only looks like a 50M file, except we're still taking up 100G of disk space, and we have no idea there's space there and it's still taken up in the allocator so it will just look like we've lost ~100G of space. This is why it's left there, so everything can be cleaned up.
I'm a little confused here. Is there a commit somewhere in there? How can the 100g allocation be committed, but not the i_size of the inode? Shouldn't either both or neither be committed? If both are committed, and then the truncate fails, then I would expect the system to come back up after a crash with the file still at 100g. That is, as long as the orphan item is not left in place after the failed truncate.
-- 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
