RE: [PATCH] ide write barrier support

[Mudama, Eric]

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

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