Timofey Titovets posted on Sat, 20 May 2017 21:30:47 +0300 as excerpted: > 2017-05-20 20:14 GMT+03:00 Kai Krakow <[email protected]>: > >> BTW: What's the smallest block size that btrfs stores? Is it always >> PAGE_SIZE? I'm not familiar with btrfs internals...
Thanks for asking the question. =:^) I hadn't made the below conflicting patch sets association until I saw it. > https://btrfs.wiki.kernel.org/index.php/Manpage/mkfs.btrfs > AFAIK btrfs works with storage and account data by PAGE_SIZEd block, > so it's must be usefull to check if compressed size will give as at > least one PAGE_SIZE space. [Not a dev, just a btrfs list regular and btrfs user. If the devs say different...] While AFAIK, btrfs now saves data in page-size blocks (tho note that if the entire file is under a block it may be inlined into metadata depending on various limits, at least one of which is configurable)... There is a sub-page-size patch set that has already been thru several revision cycles and AFAIK, remains on the roadmap for eventual merge. You'd need to check the list or ask the devs about current status, but it's quite possible the current code checking for at least one byte of compression savings, instead of the at least PAGE_SIZE bytes of savings that at present would make more sense, is in anticipation of that patch set being merged. If the sub-page-size block patch-set is no longer anticipated to be merged in the relatively near future, it may be worth changing the compression profit checks to PAGE_SIZE minimum, as this patch set does, but the two patch sets clearly do conflict in concept, so merging this one is unlikely to be wise if the other one is still on track for merging. -- Duncan - List replies preferred. No HTML msgs. "Every nonfree program has a lord, a master -- and if you use the program, he is your master." Richard Stallman -- To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in the body of a message to [email protected] More majordomo info at http://vger.kernel.org/majordomo-info.html
