Can someone elplain Synchronous Writes?

[Bill Moran]

Chris <cdtelting-ml at comcast.net> wrote:

> I did a search but was unable to find a good explanation of what 
> synchronous writes are in filesystems.  A disk can only write one block 
> of data at a time so I fail to see what is synchronous and why it is 
> slow.  Is synchronous used in this case to mean serialized file
> operations?

Sync writes means the data is written in the order it is updated, and
the OS doesn't do any reordering or optimizations.

> Also modern hard drives have write caches so doesn't that defeat 
> filesystem's consistency efforts?

No.  SCSI drives do tagged queuing, which means the OS can tell whether
or not the data has actually been written.  Tagged queuing allows the
OS to coordinate the efforts of its own cache and the drive cache.

> Lastly "soft updates" I think caches file system meta data so it updates 
> multiple records at once.  Isn't this similar to a hard drives write 
> cache and SCSI and now IDE's "native command queing" which reoders and 
> combines read and writes?

Similar, yes.  But those features are bad ideas.  Many an IDE HDD has been
hosed because it was caching data without the OS's knowledge.  SCSI uses
tagged queuing, which allows the OS to be aware of what has been written
and what is still in the queue.

If the OS requests that the data be written to the disk, the HDD should
oblige -- this allows the OS to guarantee FS consistency.  IDE drives
don't do this, SCSI do.  Apparently, newer SATA drives are more like
SCSI drives than IDE.

Softupdates is aware of the type of filesystem, and can therefore guarantee
that it commits data to the platter in a manner that will ensure FS
consistency.  The drive doesn't know what FS it has on it, so can't know
what data must be committed and when.  This is why IDE's method of caching
is dangerous.  Since SCSI allows the OS to find out what the drive has
commited, SCSI cache's can be used safely.

All programs have the option to call fsync(), which will not return until
the data they have written is successfully stored on the disk.  Many
programs (such as databases) use this to ensure that the is safely on
the disk before performing other actions, thus ensuring that the data
is never corrupted.  If the OS can not communicate with the drive cache
(as is the case with IDE) then these programs run the risk of massive
corruption in the event of a power failure (for example).

-- 
Bill Moran

Yea, I will drink thy blood gladly, that I may forget the blood of Beleg
my master, and the blood of Brandir slain unjustly.  I will slay thee
swiftly.

        Gurthang