Messages in this thread | | | Date | Fri, 17 Oct 2003 08:48:08 +0200 | From | Jens Axboe <> | Subject | Re: [PATCH] ide write barrier support |
| |
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@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
| |