On Sat, 2020-06-27 at 18:41 -0600, Chris Murphy wrote:
On Sat, Jun 27, 2020 at 4:30 PM Konstantin Kharlamov
<hi-angel(a)yandex.ru>
> Good for you. But you're trying take take decision for all other peoples, so
> you
> need to take into account not everyone has NVMe or SSD. HDDs that many
> people
> are also using are much slower. This means your "1 second vs 0.5 second"
can
> easily turn into "5 seconds vs 10 seconds" (and not necessarily
linearly).
I'm not making any claims about sysroot on HDD.
Okay, in this case, unless benchmarks prove BTRFS to be performant enough on HDD
are provided, I suggest the proposal should be modified to exclude HDDs from
being considered as a BTRFS target.
FWIW, I was just thinking about it, and I came up with example you may like
which shows exactly why BTRFS is bad for HDD. Consider development process. It
includes rewriting source files over and over: you do `git checkout foo` and
files are overwritten, you change a file in text editor, and it gets
overwritten. And since BTRFS is CoW, it will always write files to a new place.
As result, after some time, if you try to build the project, it gonna take much
longer time just because BTRFS has to read files from a bunch of different
places, and HDD are really bad at this.
If you take a non-CoW FS, this problem doesn't exist by design.