On Tue, Mar 16, 2010 at 3:25 PM, Justin Maggard [off-list ref] wrote:

On Tue, Mar 16, 2010 at 2:52 PM, Neil Brown [off-list ref] wrote:

quoted

On Tue, 16 Mar 2010 14:32:55 -0700
Justin Maggard [off-list ref] wrote:

quoted

I've noticed on recent kernels that /sys/block/md?/md/sync_completed
seems to rarely get updated.  What is the expected update interval?
For me, it seems to only update about once every 6% or so during the
resync.  Of course, /proc/mdstat has the actual current progress.

The expected update time is every 6% - actually 1/16 which is 6.25%.

sync_completed includes a guarantee that all blocks before this point really
have been processed.  The number in /proc/mdstat is less precise.  The much
of the array has been resynced, but due to the possibility of out-of-order
completion of writes they may not be a contiguous series of blocks.

Providing the guarantee (which is needed for externally-managed metadata)
requires briefly stalling the resync, so I didn't want to do it more often.
I could possibly make it time-bases instead of size-based though.

Is this a problem for you?

Thanks for the info.  No, it's not much of a problem, really.  Just
seemed strange that an array of 2TB disks could resync for an hour
with no update to sync_completed.  I thought I remembered older
kernels updating a lot more frequently, but I could be wrong about
that.  So I take it that point is where the resync would resume if the
system was rebooted?

-Justin
--
To unsubscribe from this list: send the line "unsubscribe linux-raid" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Rather than a time basis would it be possible to have a sysfs
paramater which could be tuned via write?

Candidates for this would be something like:

sync_flushes_per_action (fractional unit, every 1/N of the device)

OR

sync_flush_stripes
--
To unsubscribe from this list: send the line "unsubscribe linux-raid" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html