From: Eric Sandeen <sandeen@redhat.com>
To: Oren Elrad <elrad@brandeis.edu>
Cc: linux-ext4@vger.kernel.org
Subject: Re: [PATCH] mke2fs reserved_ratio default value is nonsensical
Date: Mon, 28 Mar 2011 13:30:53 -0500 [thread overview]
Message-ID: <4D90D3DD.9000709@redhat.com> (raw)
In-Reply-To: <AANLkTinZWJpV1tXvbrmUr740cSf5iyOOo7f=UCRb6ykK@mail.gmail.com>
On 3/28/11 1:27 PM, Oren Elrad wrote:
> On Mon, Mar 28, 2011 at 2:06 PM, Eric Sandeen <sandeen@redhat.com> wrote:
>> On 3/28/11 1:02 PM, Oren Elrad wrote:
>>> Undesired behavior; mke2fs defaults to reserving 5% of the volume for
>>> the root user. 5% of a 2TB volume is 100GB. The rationale for root
>>> reservation (syslogd, etc...) does not require 100GB. As volumes get
>>> larger, this default makes less and less sense.
>>>
>>> Proposal; If the user does not specify their preferred reserve_ratio
>>> on the command-line (-m), use the less of 5% or MAX_RSRV_SIZE. I
>>> propose 10GiB as a sensible maximum default reservation for root.
>>>
>>> Patch: Follows and http://capsid.brandeis.edu/~elrad/e2fsprog.gitdiff
>>>
>>> Tested on the latest git+patch, RHEL5 (2.6.18-194.17.1.el5) with a
>>> 12TB volume (which would reserve 600GB under the default!):
>>
>> There's been a bit of debate about this; is the space really saved
>> for root, or is it to stop the allocator from going off the rails
>> when the fs nears capacity? Both, really.
>>
>> I don't really have a horse in the race, but the complaint has certainly
>> come up before... it's just important to realize that the space isn't
>> only there for root's eventual use.
>>
>> No other fs that I know of enforces this "don't fill the fs to capacity"
>> common sense programatically, though.
>>
>> -Eric
>>
>
> [SNIP]
>
> Well, in my version you still get some reservation to prevent whatever
> woes (fragmentation, allocator slow-down) that accompany a nearly-full
> disk. If you think 25 or 50GiB is a more appropriate maximum default,
> I have no objections.
the question is, how much is enough? (isn't that always the question?) :)
What constitutes "nearly full?"
> Whatever the reason for reservation, more than 100GB is totally
> nonsensical IMHO.
That depends; 1% sounds small, until the total is a Petabyte.
For overall performance, it may well be the % that matters, not the
absolute number. It really could probably use more real investigation,
and less hand-waving (of which I am also guilty). :)
-Eric
> Oren Elrad
> Dept. of Physics
> Brandeis University
next prev parent reply other threads:[~2011-03-28 18:30 UTC|newest]
Thread overview: 9+ messages / expand[flat|nested] mbox.gz Atom feed top
2011-03-28 18:02 [PATCH] mke2fs reserved_ratio default value is nonsensical Oren Elrad
2011-03-28 18:06 ` Eric Sandeen
2011-03-28 18:27 ` Oren Elrad
2011-03-28 18:30 ` Eric Sandeen [this message]
2011-03-29 6:41 ` Rogier Wolff
2011-03-29 14:05 ` Theodore Tso
2011-03-29 15:26 ` Eric Sandeen
2011-03-29 16:00 ` Rogier Wolff
2011-03-29 16:57 ` Oren Elrad
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=4D90D3DD.9000709@redhat.com \
--to=sandeen@redhat.com \
--cc=elrad@brandeis.edu \
--cc=linux-ext4@vger.kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.