On 07/24/2017 10:25 AM, David Sterba wrote:
Thanks for the extensive historical summary, this change really deserves
it.
Decoupling the assumptions about the device's block management is really
a good thing, mount option 'ssd' should mean that the device just has
cheap seeks. Moving the the allocation tweaks to ssd_spread provides a
way to keep the behaviour for anybody who wants it.
I'd like to push this change to 4.13-rc3, as I don't think we need more
time to let other users to test this. The effects of current ssd
implementation have been debated and debugged on IRC for a long time.
The description is great, but I'd love to see many more benchmarks. At
Facebook we use the current ssd_spread mode in production on top of
hardware raid5/6 (spinning storage) because it dramatically reduces the
read/modify/write cycles done for metadata writes.
If we're going to play around with these, we need a good way to measure
free space fragmentation as part of benchmarks, as well as the IO
patterns coming out of the allocator.
At least for our uses, ssd_spread matters much more for metadata than
data (the data writes are large and metadata is small).
Thanks again,
Chris
--
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
