I think the biggest problem is how we can reclaim the space when the extent is a compressed one. In this case, we may need to read and decompress data in the extent, and then compress the valid range to generate a new extent. Is this process a performance killer? At 2013-03-27 02:03:57,"Josef Bacik" <jba...@fusionio.com> wrote: >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
