Well, I don't know the internals of it, but it goes something like:
decide which half of the mirror is more current. Read blocks from this
partition, write to other. Periodically update raid-superblock or
something. The partitions in my case are on separate SCSI disks.
The thing about it is, it attempts to throttle the sync speed to not
interfere too much with operation of the system (background resync could
suck up all i/o 'cycles' and make a system unusable) by monitoring the
amount of requests through the raid device itself. The sysadmin can set a
'speed limit' in /proc to control this, but I have it really high, so it
*should* be syncing at max speed regardless of any i/o happening to the
raid device itself.
So it's a bit complicated. You'd have to look at the code or ask someone
(Neil Brown) who knows more about it.
.... I'm rebooting and looking at it again. Here's something strange, if
I let the system sit completely idle, the resync speed increases almost to
the 'normal' rate, but causing any (minor) disk activity in another window
causes the rate to plummet for minutes.
I think there's some strange interaction with the speed-limit code in the
raid1 resync.
David
P.S. I'll post my benchmark date if/when available.
-- /==============================\ | David Mansfield | | lkml@dm.cobite.com | \==============================/- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/