All of lore.kernel.org
 help / color / mirror / Atom feed
From: Ted Ts'o <tytso@mit.edu>
To: Jan Kara <jack@suse.cz>
Cc: linux-ext4@vger.kernel.org, Andrew Morton <akpm@linux-foundation.org>
Subject: Re: [PATCH RFC 0/3] Block reservation for ext3
Date: Sat, 9 Oct 2010 14:03:58 -0400	[thread overview]
Message-ID: <20101009180357.GG18454@thunk.org> (raw)
In-Reply-To: <1286583147-14760-1-git-send-email-jack@suse.cz>

On Sat, Oct 09, 2010 at 02:12:24AM +0200, Jan Kara wrote:
> 
>   currently, when mmapped write is done to a file backed by ext3, the
> filesystem does nothing to make sure blocks will be available when we need
> to write them out.

Hmm, you've done all of this work already, so this isn't the best time
to suggest this, but I wonder if we've explored all of the
alternatives that might allow for a less drastic set of changes to
ext3, just out of stability's sake.

How often do legitimate workloads mmap a sparse file then write into
it?  As I recall, the original POSIX.1 spec didn't allow mmap beyond
the end of the file; this I believe was lifted later on (at least I
don't see it in SUSv3 spec).

If it's not all that common, then other options are:

1) Fail an mmap with EINVAL if there is an attempt to map a file
region which is either sparse or extends beyond the end of a file.
This is probably not a great alternative, but it's a possibility.

2) Allocate all of the pages that are not allocated at mmap time.
Since ext3 doesn't have space for an uninitialized bit, we'd have to
either (2a) forcing a disk write out for all of the newly initialized
pages, or (2b) keep track of the allocated disk blocks in memory, but
don't actually write the block mappings to the indirect blocks until
the blocks are actually written out.  (This last might be just as
complex, alas).

3) Keep a global counter of sparse blocks which are mapped at mmap()
time, and update it as blocks are allocated, or when the region is
freed at munmap() time.

#3 might be much simpler, at the end of the day.  Note that there are
some Japanese customers that really freaked with ext4 just because it
was *different*, and begged a distribution not to ship ext4 because it
might destablize their customers.  Not that I think we are obliged to
listen to some of the more extremely conservative customers, but there
was something nice about telling people (well, if you want something
which is nice and stable and conservative, you can pick ext3).

Do really have legitimate and common workloads which are allocating
blocks by writing into an mmapped region?  I wasn't aware of such
beasts, but maybe they are out there...

					- Ted

  parent reply	other threads:[~2010-10-09 18:04 UTC|newest]

Thread overview: 13+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2010-10-09  0:12 [PATCH RFC 0/3] Block reservation for ext3 Jan Kara
2010-10-09  0:12 ` [PATCH 1/3] vfs: Unmap underlying metadata of new data buffers only when buffer is mapped Jan Kara
2010-10-09  0:12 ` [PATCH 2/3] vfs: Implement generic per-cpu counters for delayed allocation Jan Kara
2010-10-09  7:44   ` Christoph Hellwig
2010-10-09  0:12 ` [PATCH 3/3] ext3: Implement delayed allocation on page_mkwrite time Jan Kara
2010-10-09 18:03 ` Ted Ts'o [this message]
2010-10-11 14:28   ` [PATCH RFC 0/3] Block reservation for ext3 Jan Kara
2010-10-11 21:59     ` Andrew Morton
2010-10-12 23:14       ` Jan Kara
2010-10-13  0:17         ` Ted Ts'o
     [not found]         ` <AANLkTimqbW7+wsXVoLa1Tx0K3VaDfrYKUE8owyD1VUxO@mail.gmail.com>
2010-10-13  8:49           ` Amir G.
2010-10-13 16:14             ` Amir G.
2010-10-14 15:57               ` Jan Kara

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=20101009180357.GG18454@thunk.org \
    --to=tytso@mit.edu \
    --cc=akpm@linux-foundation.org \
    --cc=jack@suse.cz \
    --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.