All of lore.kernel.org
 help / color / mirror / Atom feed
From: Eric Sandeen <sandeen@redhat.com>
To: tytso@mit.edu
Cc: Ext4 Developers List <linux-ext4@vger.kernel.org>
Subject: Re: [PATCH v4 0/3] dioread_nolock patch
Date: Fri, 15 Jan 2010 14:17:31 -0600	[thread overview]
Message-ID: <4B50CD5B.9050804@redhat.com> (raw)
In-Reply-To: <20100115201521.GE7256@thunk.org>

tytso@mit.edu wrote:
> On Fri, Jan 15, 2010 at 01:52:45PM -0600, Eric Sandeen wrote:
>> At least as far as that last bit goes, simply having the extents
>> feature is not sufficient; we allow both formats of files to exist
>> on a filesystem with the extents feature turned on.
> 
> ... and I guess someone could be appending to a legacy file when the
> system crashes.  I suppose we can at least exempt extent files from
> ordered mode handling.
> 
>> As to the general idea I'll have to give it more thought. :)
> 
> Yeah, and we need to do a lot of performance and functional testing.
> Jiaying has done a lot of testing of this in the past couple of
> months, but more testing, especially power fail testing, is definitely
> a good thing.  I also want to do power fail testing for journal
> checksums and async commits so we can turn that feature on by default,
> since with those features enabled, it almost doubles fs_mark
> performance.  (Async commit is now badly named, what it does is
> reduces the number of write barriers needed from two per commit to
> just one.  But we do need to test it some more...)

At one point google was planning to devise a power-fail test
harness.  Any news on that?

> This was more of a statement of intentions than a "we'll turn this on
> by default in 2.3.34".  I figure we'll merge first, and then change
> the default later, and still later we'll simplify the code paths by
> removing the old code path.
> 
> Speaking of which, something more to think about --- does anybody
> still care about nobh mode?  It was necessary to preserve lowmem for
> 32-bit kernels with lots of memory, and it was mainly useful for
> database workloads.  But with 64-bit kernels, it's not clear the
> tradeoffs of not caching the block number are really worth it any
> more.  What would people think about potentially dropping the nobh
> option and write paths from ext4?

I have no special love for it personally, and I don't run into
fedora users or red hat customers using it, as far as I know.

-Eric


  reply	other threads:[~2010-01-15 20:17 UTC|newest]

Thread overview: 23+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2010-01-15 19:30 [PATCH v4 0/3] dioread_nolock patch Theodore Ts'o
2010-01-15 19:30 ` [PATCH v4 1/3] ext4: mechanical change on dio get_block code in prepare for it to be used by buffer write Theodore Ts'o
2010-01-17 14:36   ` Aneesh Kumar K. V
2010-01-17 16:19     ` Eric Sandeen
2010-01-17 16:42       ` Aneesh Kumar K. V
2010-01-18  3:57       ` tytso
2010-01-15 19:30 ` [PATCH v4 2/3] ext4: use ext4_get_block_write in " Theodore Ts'o
2010-01-16  2:17   ` tytso
2010-01-17 14:21   ` Aneesh Kumar K. V
2010-01-18  5:25     ` Jiaying Zhang
2010-01-15 19:30 ` [PATCH v4 3/3] ext4: Use direct_IO_no_locking in ext4 dio read Theodore Ts'o
2010-01-17 14:19   ` Aneesh Kumar K. V
2010-01-15 19:39 ` [PATCH v4 0/3] dioread_nolock patch Ric Wheeler
2010-01-15 19:52 ` Eric Sandeen
2010-01-15 20:15   ` tytso
2010-01-15 20:17     ` Eric Sandeen [this message]
2010-01-15 21:47       ` Michael Rubin
2010-01-22 20:47         ` Valerie Aurora
2010-02-20  0:56           ` Michael Rubin
2010-02-23  0:36             ` Andreas Dilger
2010-02-16 21:07 ` Darrick J. Wong
2010-02-17 19:34   ` Jiaying Zhang
2010-02-19 21:25     ` Darrick J. Wong

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=4B50CD5B.9050804@redhat.com \
    --to=sandeen@redhat.com \
    --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.