linux-fsdevel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Arnd Bergmann <arnd.bergmann@linaro.org>
To: "Ted Ts'o" <tytso@mit.edu>
Cc: Alex Lemberg <Alex.Lemberg@sandisk.com>,
	HYOJIN JEONG <syr.jeong@samsung.com>,
	Saugata Das <saugata.das@linaro.org>,
	Artem Bityutskiy <dedekind1@gmail.com>,
	Saugata Das <saugata.das@stericsson.com>,
	linux-ext4@vger.kernel.org, linux-fsdevel@vger.kernel.org,
	linux-mmc@vger.kernel.org, patches@linaro.org, venkat@linaro.org,
	"Luca Porzio (lporzio)" <lporzio@micron.com>
Subject: Re: [PATCH 2/3] ext4: Context support
Date: Tue, 19 Jun 2012 15:17:26 +0000	[thread overview]
Message-ID: <201206191517.26687.arnd.bergmann@linaro.org> (raw)
In-Reply-To: <20120618174214.GA1506@thunk.org>

On Monday 18 June 2012, Ted Ts'o wrote:
> On Sat, Jun 16, 2012 at 05:41:23PM +0000, Arnd Bergmann wrote:
> > 
> > * We cannot read from write-only large-unit context, so we have to
> >   do one of these:
> >    a) ensure we never drop any pages from page-cache between writing
> >       them to the large context and closing that context
> >    b) if we need to read some data that we have just written to the
> >       large-unit context, close that context and open a new rw-context
> >       without the large-unit flag set (or write in the default context)
> 
> If we ever a read on the inode in question, we close the large-unit
> context.  That's the simplest thing to do, since we then don't need to
> track which blocks had been written from the inode.  And in general,
> if you have a random read/write workload, large-unit contexts probably
> won't help you.  We mainly would need this when the workload is doing
> large sequential writes, which is *easy* to optimize for.

right.

> > * All writes to the large-unit context have to be done in superpage
> >   size, which means something between 8 and 32 kb typically, so more
> >   than the underlying fs block size
> 
> Right, so we only enable the large-unit context when we are in
> ext4_da_writepages() and we can do the first write in a way that meets
> the requirements (i.e., the write starts aligned on the erase block,
> and is a multiple of the superpage size).  The moment we need to do a
> read (see above) or a write which doesn't meet the large-unit
> restrictions, we close the large-unit context.
> 
> (This is why I asked the question about whether there are performance
> penalties for opening and closing contexts.  If it requires flushing
> the NCQ queues, ala the trim request, then we might need to be more
> careful.)

I believe it should only require flushing that one context, although
a specific hardware implementation might be worse than that. Maybe
Luca or Alex can comment on this.

> > * We can only start the large unit at the start of an erase block. If
> >   we unmount the drive and later continue writing, it has to continue
> >   without the large-unit flag at first until we hit an erase block
> >   boundary.
> 
> My assumption was that when you umount the drive, the file system
> would close all of the contexts.

Yes, makes sense. This is probably required to ensure that the data
has made to the drive, at least for the large contexts, but it is
definitely required for housekeeping of contexts if we manage them
from the block layer.

	Arnd

  reply	other threads:[~2012-06-19 15:17 UTC|newest]

Thread overview: 42+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2012-06-11 10:46 [PATCH 1/3] block: Context support Saugata Das
2012-06-11 10:46 ` [PATCH 2/3] ext4: " Saugata Das
2012-06-11 11:41   ` Artem Bityutskiy
2012-06-11 12:27     ` Ted Ts'o
2012-06-12 12:21       ` Saugata Das
2012-06-12 12:32         ` Ted Ts'o
2012-06-12 13:29         ` Arnd Bergmann
2012-06-12 14:26           ` Saugata Das
2012-06-12 14:55             ` Arnd Bergmann
2012-06-12 18:19               ` Ted Ts'o
2012-06-12 20:07                 ` Arnd Bergmann
2012-06-12 20:41                   ` Ted Ts'o
2012-06-13 19:44                     ` Arnd Bergmann
2012-06-13 20:00                       ` Ted Ts'o
2012-06-13 20:43                         ` Arnd Bergmann
2012-06-14  2:07                           ` Ted Ts'o
2012-06-14 16:14                             ` Nicolas Pitre
2012-06-14 16:24                               ` Artem Bityutskiy
2012-06-14 17:05                               ` Ted Ts'o
2012-06-14 19:08                                 ` Nicolas Pitre
2012-06-15  9:19                                   ` Arnd Bergmann
2012-06-15 21:30                                     ` Ted Ts'o
2012-06-16  6:49                                       ` Arnd Bergmann
2012-06-14 21:55                             ` Arnd Bergmann
2012-06-15  5:18                               ` Andreas Dilger
2012-06-15  9:25                                 ` Arnd Bergmann
2012-06-15  9:40                                   ` Andreas Dilger
2012-06-15 10:54                                     ` Arnd Bergmann
2012-06-15 22:04                               ` Ted Ts'o
2012-06-15 22:25                                 ` Andreas Dilger
2012-06-16  7:14                                   ` Arnd Bergmann
2012-06-16  7:28                                     ` Arnd Bergmann
2012-06-16  7:26                                 ` Arnd Bergmann
2012-06-16 13:49                                   ` Ted Ts'o
2012-06-16 17:41                                     ` Arnd Bergmann
2012-06-18 17:42                                       ` Ted Ts'o
2012-06-19 15:17                                         ` Arnd Bergmann [this message]
2012-06-20 15:09                                           ` Luca Porzio (lporzio)
2012-06-20 15:46                                             ` Arnd Bergmann
2012-06-22 13:29                       ` Artem Bityutskiy
2012-06-22 14:07                         ` Luca Porzio (lporzio)
2012-06-11 10:46 ` [PATCH 3/3] mmc: " Saugata Das

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=201206191517.26687.arnd.bergmann@linaro.org \
    --to=arnd.bergmann@linaro.org \
    --cc=Alex.Lemberg@sandisk.com \
    --cc=dedekind1@gmail.com \
    --cc=linux-ext4@vger.kernel.org \
    --cc=linux-fsdevel@vger.kernel.org \
    --cc=linux-mmc@vger.kernel.org \
    --cc=lporzio@micron.com \
    --cc=patches@linaro.org \
    --cc=saugata.das@linaro.org \
    --cc=saugata.das@stericsson.com \
    --cc=syr.jeong@samsung.com \
    --cc=tytso@mit.edu \
    --cc=venkat@linaro.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).