2010/2/5 Matthew Dillon
<dillon@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 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)?
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
