Re: kernel work week of 3-Feb-2010 HEADS UP

[Matthew Dillon <dillon@xxxxxxxxxxxxxxxxxxxx>]

:I probably don't understand well enough what it would mean if we have
:the root volume and especially the UNDO log on a very fast SSD. Would the
:only
:thing that is improved be the fsync performance, or would normal write
:operations also benefit a little from it (not the actual writes, but
:because
:writes can be queued and issued more optimal by the disk, not waiting
:for the UNDO log to be synced to disk)?

    Only fsync() is synchronous.  So even though the backend flusher
    also uses the disk sync command it is asynchronous and the frontend
    user program(s) will not notice it much.  Also the UNDO area is
    linear, so for each flush sequence you are talking one or two
    seeks.  Not that big a deal for an asynchronous operation.

    We could put the forward log on the SSD and leave the UNDO log
    area alone.  Maybe.  It would take some serious recoding and isn't
    on my list but it is worth thinking about.

:While I am asking questions, here is another one:
:When an ATA_SYNC (or _FLUSH?) command is issued to the disk, is this
:global for all outstanding blocks to be written to disk, or is it possible
:to
:specify a logical block number range? For example, if we'd have two
:partitions
:on disk, a sync would then sync both partitions, wouldn't it?
:
:Regards,
:
:  Michael

    I'm pretty sure there is no specified range.  It applies to all
    disk write I/O which has completed from the point of the host
    (and is thus likely sitting in the drive's RAM cache).

    SCSI has ordered tags but they aren't really all that reliable
    as an abstraction.

    There have been proposals for improving the command but this is
    the ATA command set we are talking about here, so don't expect
    them to actually do something good.

					-Matt
					Matthew Dillon 
					<dillon@backplane.com>