DragonFly BSD
DragonFly kernel List (threaded) for 2010-02
[Date Prev][Date Next]  [Thread Prev][Thread Next]  [Date Index][Thread Index]

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

From: Michael Neumann <michaelneuma@xxxxxxxxxxxxxx>
Date: Fri, 5 Feb 2010 11:31:53 +0100

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

   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?



[Date Prev][Date Next]  [Thread Prev][Thread Next]  [Date Index][Thread Index]