lkml.org 
[lkml]   [2009]   [Feb]   [16]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: ext2 + -osync: not as easy as it seems
On Thu, Feb 12 2009, Eric Sandeen wrote:
> Jens Axboe wrote:
> > On Wed, Jan 14 2009, Jan Kara wrote:
> >>> I'm not sure what you mean; if the barrier operation isn't flushing
> >>> all of the caches all the way out to the iron oxide, it's not going to
> >>> be working properly no matter where it is being called, whether it's
> >>> in ext4_sync_file() or in jbd2's journal_submit_commit_record().
> >> Well, I thought that a barrier, as an abstraction, only guarantees that
> >> any IO which happened before the barrier hits the iron before any IO which
> >> has been submitted after a barrier. This is actually enough for a
> >> journalling to work correctly but it's not enough for fsync() guarantees.
> >> But I might be wrong...
> >
> > It also guarentees that when you get a completion for that barrier
> > write, it's on safe storage. Think of it as a flush-write-flush
> > operation, in the presence of write back caching.
>
> (sorry for chiming in so late)
>
> Jens, isn't this just the way it's implemented today? At some point
> couldn't a barrier bio simply be a reordering barrier that the storage
> can use when destaging the write cache, rather than the heavy-handed
> flush-write-flush we have today?
>
> I guess it's a question of the intended semantics of a barrier bio, vs.
> today's implementation based on current hardware functionality...

Right, the current implementation is largely an artefact of what we can
do with todays hardware. It would be quite reasonable to decouple the
flush from the reordering, if we were able to support that on the
hardware side.

--
Jens Axboe



\
 
 \ /
  Last update: 2009-02-18 12:23    [W:0.157 / U:0.376 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site