touch-packages team mailing list archive

[Theodore Ts'o <tytso@xxxxxxx>]

I just don't think an adaptive algorithm is going to be worth the
complexity.  It will invariably get it wrong for some work load or
another.   At which point more people will start kvetching and opening
bug reports.

For one thing, it matters a lot what the average size is of the files
being stored on a file system.   For example, if the average file size
is 4k, then you can fill it to 100% without suffering any performance
degradation.    It will also depend on the distibution of the files and
whether you just write once and be done, or whether files are constantly
being deleted and inserted, potentially with different sizes.

It also matters whether the user cares about performance or capacity.
Disks have essentially not changed the average seek time, while doubling
in capacity every 18 months or so (with this trend only only slowing
down in the past year or two).   So if you consider the average seek per
GB of capacity, it's been dropping with every single disk generation.
As a result, there are probably many applications which are now no
longer constrained by disk capacity, but by seek capacity (i.e., by the
number of spindles).     I've even seen examples of shops that have
deliberately not gotten the latest 6TB or 8TB disks, because they are
spindle constrained, and so they are better off buying 2T or 4T disks.

This last is why I really don't think it's worth while to worry about
that last 51GB if you have a 1T disk.    Adding complexity to the
calculation just makes it harder for system administrators to understand
what is going on, and with the seeks per GB dropping like a stone over
the past few decades, for many shops performance is far more important
than the value of that 51GB (which in dollar values, given today's costs
in disk, is approximately $2.50 USD.   In terms of minutes of a system
administrators time, or a software engineers time, you've no doubt
wasted far more than that in discussing 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