tech-kern archive

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index][Old Index]

Re: Proposal: B_ARRIER (addresses wapbl performance?)

On Thu, Oct 30, 2008 at 08:17:04PM -0400, Thor Lancelot Simon wrote:
> On Thu, Oct 30, 2008 at 01:28:21PM -0700, Bill Stouder-Studenmund wrote:
> > On Wed, Oct 29, 2008 at 05:51:09PM -0400, Thor Lancelot Simon wrote:
> >
> > The problem is that this won't help. Ordered tags will relate the 
> > sequencing of commands relative to each other. The journal, however, 
> > doesn't care about the relative ordering of operations, it wants to know 
> > when the writes to the journal have hit stable storage.
> > 
> > The key problem is that, on SCSI disks with the write cache enabled, a
> > write command can complete by writing to the cache.
> But SCSI disks don't lie like this unless explicitly configured to, and
> with proper use of tags, there is no need to configure them that way;
> there is no performance benefit.
> Never mind that if they have power protection, it's still safe to do so.
> So from my point of view, this does precisely what WAPBL needs -- render
> it just as safe as a non-journalled filesystem, or safer, while radically
> improving performance.

Until someone turns off the disk caches. Or more accurately forgets to 
turn them off. My understanding is that all disks come with caches enabled 
these days.

Or worse yet, is unable to turn them off because users complain vehimently 
about reduced performance.

So I now have to say I strongly object to this proposal. The only way
WAPBL would work correctly (not just nicely, but _correctly_) is if 
administrators take an explicit overal-performance-reducing step.

Once again, why not just add FUA suport? It does _exactly_ what we want, 
and all of the fallback cases (i.e. what to do if we can't do what we 
want) are what we do now with the cache flushing.

And FUA would be higher performance than using tags this way. The 
difference is that using tags means the ordered tag has to wait for all 
writes, not just ones to the journal area. So if we had a lot of 
outstanding non-metadata i/o, journal writes get stuck waiting for it.

Take care,


Attachment: pgpkrzPUK0PPn.pgp
Description: PGP signature

Home | Main Index | Thread Index | Old Index