On Tue, Mar 26, 2013 at 10:27:34AM -0600, yiletian wrote: > Yes, I use compress-force=zlib for my partition. > > Consider this scenario. > > We first write a file with size of 256KB. Assume all data is compressed to > 128KB size, > btrfs create a extent item in extent-tree to record the 128KB disk range > (named E). > and btrfs also creates a single file extent to records the disk range of E. > > Then we overwrite from 16KB to the end of file, with size of 240KB. > Btrfs will create a new file extent for the overwritten range. > That is, the file has two file extents: the first one is to record the first > 16KB and the second one record the remaining 240KB. > > Then we are in a dilemma: > 1. the first one only occupies a disk range of 16KB, but entire E is reserved > for it. This is because the __btrfs_drop_exte nts function do not decrease > the number of back refs of E. > 2. because the overwritten range is large enough, the compress_file_range > does not call btrfs_add_inode_defrag to kick off a defrag for the file > automatically. > > With this dilemma, how can btrfs reclaim the 112KB disk range (at least) > recorded in E. >
Oh yeah welcome to btrfs, you must be new here ;). So yeah this is the way it works, until we overwrite the entire extent we don't reclaim any of the space. This includes the "prealloc an 8 gig vm image and then random write inside of it" workload, you could end up using up to 16gb in the worst case scenario. The thing we could do to fix this would be to instead of splitting the file extents and then inc'ing the ref of the original extent we instead split the extent ref as well, so we can reclaim this space. It's on my list of things to do down the road, but it keeps getting supplanted by other priorities. THanks, Josef -- 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
