Re: [PATCH] ide write barrier support

[Jens Axboe <axboe@suse.de>]

On Fri, Oct 17 2003, Mudama, Eric wrote:
> 
> 
> > -----Original Message-----
> > From: Jens Axboe [mailto:axboe@suse.de]
> >
> > 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.
> 
> None of the TCQ/FUA components of the spec mention ordering.  According to
> the "letter" of the specification, if you issue two queued writes for the
> same LBA, the drive has the choice of which one to do first and which one to
> put on the media first, which is totally broken in common sense land.
> 
> Luckilly, us drive guys are a bit smarter (if only a bit)...

Some of you? :)

> If you issue a FUA write for data already in cache, and you put the FUA
> write onto the media, there's no problem if you discard the cached data that
> you were going to write.
> 
> In drives with a unified cache, they'll always be consistent provided the
> overlapping interface transfers happen in the same order they were
> issued.... this is common sense.
> 
> However, you're right in that non-overlapping cached write data may stay in
> cache a long time, which potentially gives you a very large time hole in
> which your FUA'd data is on the media and your user data is still hangin' in
> the breeze prior to a flush on a very busy drive.

That's why for IDE I prefer handling it in software. Let the queue drain,
issue a barrier write, and continue. That works, regardless of drive
firmware implementations. As long as the spec doesn't make it explicit
what happens, there's no way I can rely on it.

Jens