linux-ext4.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Theodore Tso <tytso@mit.edu>
To: Alex Tomas <alex@clusterfs.com>
Cc: Andreas Dilger <adilger@clusterfs.com>, linux-ext4@vger.kernel.org
Subject: Re: Design alternatives for fragments/file tail support in ext4
Date: Fri, 13 Oct 2006 08:23:26 -0400	[thread overview]
Message-ID: <20061013122325.GA1668@thunk.org> (raw)
In-Reply-To: <m3y7rkeb69.fsf@bzzz.home.net>

On Fri, Oct 13, 2006 at 02:56:46PM +0400, Alex Tomas wrote:
> >>>>> Theodore Tso (TT) writes:
> 
>  TT> I suggest this be tunable by superblock field, and not by a /proc
>  TT> tunable.  This is the sort of thing which might be different
>  TT> per-filesystem, and the algorithm will be most effective if the
>  TT> filesystem always use the same cluster size from the time when it was
>  TT> first created.  I'd be happy to assign a superblock field for this
>  TT> purpose, and add the appropriate tune2fs support if we have general
>  TT> agreement on this point.
> 
> that would be good. there is even a stride option to mke2fs?

Yes, there is.  And just as we have -E stride=stripe-size and -E
resize=max-online-resize, we can also -E cluster-size=bytes parameter
in mke2fs.  It would also make sense to make this be something that
can be defaulted in /etc/mke2fs.conf, since even for IDE or SATA disks
it probably makes sense to make the cluster size be 16k or 32k or
maybe even higher.  We probably need to do some benchmarks to see
whether or not this makes sense.

							- Ted


  reply	other threads:[~2006-10-13 12:23 UTC|newest]

Thread overview: 9+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2006-10-11 13:55 Design alternatives for fragments/file tail support in ext4 Theodore Ts'o
2006-10-13  6:19 ` Michael Burschik
2006-10-13  8:10 ` Andreas Dilger
2006-10-13 10:49   ` Theodore Tso
2006-10-13 10:56     ` Alex Tomas
2006-10-13 12:23       ` Theodore Tso [this message]
2006-10-13 17:47         ` Andreas Dilger
2006-10-13 12:48 ` Erik Mouw
2006-12-02 11:02 ` Alex Tomas

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=20061013122325.GA1668@thunk.org \
    --to=tytso@mit.edu \
    --cc=adilger@clusterfs.com \
    --cc=alex@clusterfs.com \
    --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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).