touch-packages team mailing list archive

[Theodore Ts'o <tytso@xxxxxxx>]

As the file system gets more and more full, the free space gets more and
more fragmented.  This results in disastrous performance hits for files
that are written when the file system gets full, and then when you later
try to read them, you will suffer similar disastrous performance hits.

This is of course much more notable on HDD, but even on SSD's, a random
write workload is always going to result in greater flash wear and lower
performance than a sequential write workload --- particularly on the
cheaper flash that you would expect to see in tablets and phones (i.e.,
eMMC flash) --- and even some of the crappier desktop SSD's.

Now, if you have an Intel or Samsung SSD, this might not matter as much
(although you will still see a performance hit) --- but having mke2fs
figure out whether you have a competently implemented flash translation
layer, or a spectacularly crappy one (since on phones they calculate the
BOM cost down to the hundredth or thousandth of a cent, and that extra
25 cents worth of better FTL license fees and controller memory is Just
Too Damn High :-), is just too much complexity to put into mke2fs's
program logic.    It's better to have a simple, well defined default,
and then if you know for sure that you have a system where you don't
mind highly fragmented files, to adjust the root reserve.

As far as the server and the cloud, for the cloud, it won't really
matter since guest OS's generally have relatively small amounts of
space.  And Ubuntu has stopped caring about the enterprise server market
a long time ago.   As far as the cloud host OS, there's a heck of a lot
more tuning you need to do if you what a high-performing,
price/performance competitive offering, such that adjusting the root
reserve is the very least of your problems....

In any case, this is not something I intend to change for upstream,
either in e2fsprogs or the Debian package.  If the Ubuntu release
engineers want to make a change, they are of course free to do so.  But
I wouldn't recomend it.

-- 
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which is subscribed to e2fsprogs in Ubuntu.
https://bugs.launchpad.net/bugs/1340448

Title:
  5% reservation for root is inappropriate for large disks/arrays

Status in “e2fsprogs” package in Ubuntu:
  Confirmed

Bug description:
  mke2fs (and it's ext3 and ext4 analogs) still default to reserving 5%
  of the filesystem for root.  With the size of modern disks and arrays
  this isn't a terribly sensible default, e.g. if I have a 10Tb array,
  mke2fs will reserve 500Gb for root.

  Obviously this is both tunable at FS creation time and fixable after
  the fact but I still think we should try and improve the defaults.

  Given the size of modern disks, I think it'd make sense to either a)
  only reserve a smaller amount (e.g. 1%) or b) reserve n% if the
  filesystem is << NNN GB and otherwise reserve NN GB.

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/e2fsprogs/+bug/1340448/+subscriptions