All of lore.kernel.org
 help / color / mirror / Atom feed
From: Eric Sandeen <sandeen@redhat.com>
To: Theodore Tso <tytso@mit.edu>
Cc: Oren Elrad <elrad@brandeis.edu>, linux-ext4@vger.kernel.org
Subject: Re: [PATCH] mke2fs reserved_ratio default value is nonsensical
Date: Tue, 29 Mar 2011 10:26:29 -0500	[thread overview]
Message-ID: <4D91FA25.1080402@redhat.com> (raw)
In-Reply-To: <4731EEFB-561D-4393-81C9-B550F45964C6@mit.edu>

On 3/29/11 9:05 AM, Theodore Tso wrote:
> 
> On Mar 28, 2011, at 2:06 PM, Eric Sandeen wrote:
>> 
>> No other fs that I know of enforces this "don't fill the fs to
>> capacity" common sense programatically, though.
> 
> Actually, we (ext2) copied this from the BSD Fast File System (FFS)
> which used a default MINFREE of 10%.   For ext2 we decided to bring
> it down to 5%.   FreeBSD currently uses 8% as their default free
> ratio.

Clearly I don't know enough filesystems, I guess ;)

Should have said "linux filesystem" perhaps.

> The decrease does seem to be relative to the percentage of free
> space, from empirical experience, although no one I know of has done
> a formal analysis of the slowdown.   A lot depends on your workload,
> how much memory pressure you place on your system, etc.  I've
> actually started seeing slowdowns starting as early as 80% full when
> you're trying to allocate large chunks (1M to 8M) at a time, although
> this isn't something where I've gathered hard data; just what I've
> noticed from looking at different systems and their performance
> characteristics.
> 
> Fortunately disks are cheap, and lots of people end up buying far
> more disk space than they need, and so they naturally keep their file
> systems well under 75-80% full.
> 
> If someone wants to add some tuning parameters to mke2fs.conf, so
> they can set their own personal default free ratios, or even
> min_reserved_blocks and max_reserved_blocks settings, that's probably
> a reasonable patch to e2fsprogs that I'd be willing to accept. 

Hm I thought I had sent that, but it was only for the other two
semi-controversial behaviors.  :)

I agree, it seems like at least a decent first step to make it
more site/admin-configurable. 

-Eric


  reply	other threads:[~2011-03-29 15:26 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
2011-03-29  6:41   ` Rogier Wolff
2011-03-29 14:05   ` Theodore Tso
2011-03-29 15:26     ` Eric Sandeen [this message]
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=4D91FA25.1080402@redhat.com \
    --to=sandeen@redhat.com \
    --cc=elrad@brandeis.edu \
    --cc=linux-ext4@vger.kernel.org \
    --cc=tytso@mit.edu \
    /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.