Messages in this thread | | | Date | Fri, 17 Oct 2003 20:08:01 +0200 | From | Jens Axboe <> | Subject | Re: [PATCH] ide write barrier support |
| |
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
- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
| |