Re: Snapshot Cleaner not Working with inode_cache
Am 20.02.2013, 02:14 Uhr, schrieb Liu Bo bo.li@oracle.com: I think I know why inode_cache keeps us from freeing space, inode_cache adds a cache_inode in each btrfs root, and this cache_inode will be iput at the very last of stage during umount, ie. after we do cleanup work on old snapshot/subvols, where we free the space. A remount will force btrfs to do cleanup work on old snapshots during mount. This may explain the situation. thanks, liubo I don't know how long the code behaves that way, but this is exactly what I see here on debian kernel 3.2.35. Norbert -- To unsubscribe from this list: send the line unsubscribe linux-btrfs in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Snapshot Cleaner not Working with inode_cache
On Fri, Feb 22, 2013 at 11:16:22AM +0100, Norbert Scheibner wrote: Am 20.02.2013, 02:14 Uhr, schrieb Liu Bo bo.li@oracle.com: I think I know why inode_cache keeps us from freeing space, inode_cache adds a cache_inode in each btrfs root, and this cache_inode will be iput at the very last of stage during umount, ie. after we do cleanup work on old snapshot/subvols, where we free the space. A remount will force btrfs to do cleanup work on old snapshots during mount. This may explain the situation. thanks, liubo I don't know how long the code behaves that way, but this is exactly what I see here on debian kernel 3.2.35. A patch to fix it is now in btrfs-next, so we may not be bitten any more. thanks, liubo -- To unsubscribe from this list: send the line unsubscribe linux-btrfs in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Snapshot Cleaner not Working with inode_cache
I've encountered an issue where the space from previously deleted snapshots is not being freed up by the cleaner thread. I'm only encountering this issue when I mount with the inode_cache option. I've reproduced this on a 3.7.9 kernel merged with the latest for-linus branch. No additional patches are involved. My testing partition is 16 GB. There is nothing in dmesg indicating any issues. A simple manual test can reproduce the issue on my box (1) Format a fresh, scratch btrfs partition (it would probably work with an existing test partition, but I always like to test things that seem broken on a scratch partition). (2) Mount partition (my options are -o compress-force=lzo,inode_cache). My mount command was: mount -o compress-force=lzo,inode_cache /dev/sda7 /mnt/benchmark/ (3) Make a subvolume: cd /mnt/device; btrfs su create test1 (4) Untar kernel sources to the subvolume: cd test1; tar -xpf path/to/kernel/source/tarball I believe anything you use to populate the subvolume is sufficient. (5) Make a note of the disk usage: df -T /mnt/device (6) Remove the subvolume: cd ..; btrfs su delete test1 (7) Wait 2 minutes, and notice that the space has not been freed up. I've waited much longer, but I forget the exact timeout on the cleaner thread. df -T /mnt/device If I unmount and remount the partition with the same mount options, the cleaner will begin to correctly free the space. I've never used the inode_cache option before, so I'll try a few other kernels to see if this is a regression. -- To unsubscribe from this list: send the line unsubscribe linux-btrfs in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Snapshot Cleaner not Working with inode_cache
On Tue, Feb 19, 2013 at 02:22:27PM -0600, Mitch Harder wrote: I've encountered an issue where the space from previously deleted snapshots is not being freed up by the cleaner thread. I'm only encountering this issue when I mount with the inode_cache option. I've reproduced this on a 3.7.9 kernel merged with the latest for-linus branch. No additional patches are involved. My testing partition is 16 GB. There is nothing in dmesg indicating any issues. A simple manual test can reproduce the issue on my box (1) Format a fresh, scratch btrfs partition (it would probably work with an existing test partition, but I always like to test things that seem broken on a scratch partition). (2) Mount partition (my options are -o compress-force=lzo,inode_cache). My mount command was: mount -o compress-force=lzo,inode_cache /dev/sda7 /mnt/benchmark/ (3) Make a subvolume: cd /mnt/device; btrfs su create test1 (4) Untar kernel sources to the subvolume: cd test1; tar -xpf path/to/kernel/source/tarball I believe anything you use to populate the subvolume is sufficient. (5) Make a note of the disk usage: df -T /mnt/device (6) Remove the subvolume: cd ..; btrfs su delete test1 (7) Wait 2 minutes, and notice that the space has not been freed up. I've waited much longer, but I forget the exact timeout on the cleaner thread. df -T /mnt/device If I unmount and remount the partition with the same mount options, the cleaner will begin to correctly free the space. Hi Mitch, Good summary. I've never used the inode_cache option before, so I'll try a few other kernels to see if this is a regression. I think I know why inode_cache keeps us from freeing space, inode_cache adds a cache_inode in each btrfs root, and this cache_inode will be iput at the very last of stage during umount, ie. after we do cleanup work on old snapshot/subvols, where we free the space. A remount will force btrfs to do cleanup work on old snapshots during mount. This may explain the situation. thanks, liubo -- To unsubscribe from this list: send the line unsubscribe linux-btrfs in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html -- To unsubscribe from this list: send the line unsubscribe linux-btrfs in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
