Re: [PATCH] ide write barrier support

[Jens Axboe]

On Thu, Oct 16 2003, Mudama, Eric wrote:
> 
> 
> > -----Original Message-----
> > From: Greg Stark
> >
> > Ideally postgres just needs to call some kind of fsync 
> > syscall that guarantees
> > it won't return until all buffers from the file that were 
> > dirty prior to the
> > sync were flushed and the disk was really synced. It's fine 
> > for buffers that
> > were dirtied later to get synced as well, as long as all the 
> > old buffers are
> > all synced.
> 
> This checkpointing doesn't exist in ATA, only in SCSI I think.  You can get
> similar behavior in ATA-7 capable drives (which I don't think are on the
> market yet) by issuing FUA commands.  These will not return good status
> until the data is on the media, and they can be intermingled with other
> cached writes without destroying overall performance.
> 
> If there was some way to define a file as FUA instead of normal, then you'd
> know every write to it would be on the media if the status was good.
> However, you may have committed your journal or whatever and have possibly
> significantly stale data on the drive's cache in the user data area.
> 
> As far as the actual file-system call mechanism to achive this, I have no
> idea... I know very little about linux internals, I just try to answer
> disk-related questions.

Yes that would be very nice, but unfortunately I think FUA in ATA got
defined as not implying ordering (the FUA write would typically go
straight to disk, ahead of any in-cache dirty data). Which makes it less
useful, imo.

-- 
Jens Axboe

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/