On Mon, Mar 25, 2013 at 10:03:20PM -0600, lonat_front@xxxxxxx wrote: > Hi everyone, > > I have used btrfs as a work partition with compression=zlib. The compression ratio is not satisfied to me. > So you probably want compress-force=zlib. With just compress we will bail out of the compression if the compressed pages are larger than the original size, which means if you wrote a particular file and then copmressed it with gzip you'd possibly see different results, but if you do compress-force=zlib then you'll see behavior more like gzip. > I tracked my workloads in btrfs. The zlib module (zlib.c) seems work well: write size of each write operation in writepage function can be compressed into about 20%. > > I suspent the workloads may impact the btrfs behavior. My workloads include really a large number of overwrite operations. > > I briefly reviewed the code about the space reclaim in btrfs, and found the btrfs kicks the defrag off when the overwritten range is smaller than 16KB, And this is the only method of reclaiming freed extents with compression. Am I right? It's 64k, and what do you mean reclaiming freed extents? The freed extents will be reclaimed once they are completely overwritten. > > So my question is if btrfs can successfully reclaim the overwritten space when the cleaner thread can not be started, such as in the case that each overwrite operation is larger than 16KB? Not sure what you mean by reclaim. They won't be defragged if the overwrite is above 64k, but if any write is less than 64k then it will defrag the whole file. Thanks, Josef -- 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
