kernel work week of 3-Feb-2010 HEADS UP

[Michael Neumann]

2010/2/5 Matthew Dillon <dillon at apollo.backplane.com>

:Is the concern that people would be more inclined to remove an SSD than a
:regular drive by mistake, or that splitting off the log could lead to an
:"oops, I forgot that the log was separate" situation when changing out
:drives?  Or something else?
:
:It seems like an odd thing to worry about, to be honest.  If you can't
:trust users not to start removing important components from their
:systems...
:
:MAgnus

    Well, true enough.  I guess the real issue I have is that one
    is dedicated a piece of equipment to a really tiny piece of the
    filesystem.  Though I can't deny the utility of having a fast fsync().
    If the storage system is big enough then, sure.  If you're talking
    about going from one physical drive to two though it probably isn't
    worth the added complexity it just to get a fast fsync().I probably don't understand well enough what it would mean if we havethe 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 writeoperations 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)?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 partitionson disk, a sync would then sync both partitions, wouldn't it?Regards,
  Michael