public inbox for linux-scsi@vger.kernel.org
 help / color / mirror / Atom feed
From: James Bottomley <James.Bottomley@HansenPartnership.com>
To: Ric Wheeler <rwheeler@redhat.com>
Cc: Chris Mason <clmason@fusionio.com>,
	"Martin K. Petersen" <mkp@mkp.net>,
	"linux-scsi@vger.kernel.org" <linux-scsi@vger.kernel.org>
Subject: Re: atomic write & T10 standards
Date: Wed, 03 Jul 2013 08:37:09 -0700	[thread overview]
Message-ID: <1372865829.3601.41.camel@dabdike> (raw)
In-Reply-To: <51D442DD.8000001@redhat.com>

On Wed, 2013-07-03 at 11:27 -0400, Ric Wheeler wrote:
> On 07/03/2013 11:22 AM, James Bottomley wrote:
> > On Wed, 2013-07-03 at 11:04 -0400, Ric Wheeler wrote:
> >> Why not have the atomic write actually imply that it is atomic and durable for
> >> just that command?
> > I don't understand why you think you need guaranteed durability for
> > every journal transaction?  That's what causes us performance problems
> > because we have to pause on every transaction commit.
> >
> > We require durability for explicit flushes, obviously, but we could
> > achieve far better performance if we could just let the filesystem
> > updates stream to the disk and rely on atomic writes making sure the
> > journal entries were all correct.  The reason we require durability for
> > journal entries today is to ensure caching effects don't cause the
> > journal to lie or be corrupt.
> 
> Why would we use atomic writes for things that don't need to be
> durable?
> 
> Avoid a torn page write seems to be the only real difference here if
> you use the atomic operations and don't have durability...

It's not just about torn pages: Journal entries are big complex beasts.
They can be megabytes big (at least on xfs).  If we can guarantee all or
nothing atomicity in the entire journal entry write it permits a more
streaming design of the filesystem writeout path.

James
 


  reply	other threads:[~2013-07-03 15:37 UTC|newest]

Thread overview: 14+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
     [not found] <51D4365C.1030008@redhat.com>
     [not found] ` <20130703143844.14981.69152@localhost.localdomain>
     [not found]   ` <51D43B87.5090005@redhat.com>
     [not found]     ` <1372863655.3601.19.camel@dabdike>
2013-07-03 15:04       ` atomic write & T10 standards Ric Wheeler
2013-07-03 15:21         ` Chris Mason
2013-07-03 15:22         ` James Bottomley
2013-07-03 15:27           ` Ric Wheeler
2013-07-03 15:37             ` James Bottomley [this message]
2013-07-03 15:42               ` Ric Wheeler
2013-07-03 15:54                 ` Chris Mason
2013-07-03 18:31                   ` Ric Wheeler
2013-07-03 18:54                     ` Chris Mason
2013-07-03 18:55                       ` Ric Wheeler
2013-07-04  3:18                     ` Vladislav Bolkhovitin
2013-07-04 12:34                       ` Ric Wheeler
2013-07-05 15:34                         ` Elliott, Robert (Server Storage)
2013-07-05 16:49                           ` Ric Wheeler

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=1372865829.3601.41.camel@dabdike \
    --to=james.bottomley@hansenpartnership.com \
    --cc=clmason@fusionio.com \
    --cc=linux-scsi@vger.kernel.org \
    --cc=mkp@mkp.net \
    --cc=rwheeler@redhat.com \
    /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