DragonFly kernel List (threaded) for 2010-02
Re: kernel work week of 3-Feb-2010 HEADS UP
: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
:thing that is improved be the fsync performance, or would normal write
:operations also benefit a little from it (not the actual writes, but
: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
:specify a logical block number range? For example, if we'd have two
:on disk, a sync would then sync both partitions, wouldn't it?
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.