lkml.org 
[lkml]   [2003]   [Oct]   [17]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
From
SubjectRE: [PATCH] ide write barrier support
Date


> -----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)...

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.
-
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/

\
 
 \ /
  Last update: 2005-03-22 13:58    [W:0.050 / U:0.412 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site