Does your "Surface Scanner" generate a time record, as does Terminal, when it's finished its work?

I've considered having it keep samples and generate a basic graph when it's done to see if there are any (downward) spikes encountered during the scan. I'm also just basically curious to see how scan speeds vary across the surface of a disk - I assume there is a change as scanning farther from the center should yield faster data transfer rate.

For now it just has a hardcoded time limit that if the particular pass doesn't complete in time it stops and errors out.

I have a much more sophisticated script that runs here on several machines that have multiple attached drives, that is set to actually monitor speeds and alert me when they drop to 40% of expected or less. I've been getting emails lately though and I'm not sure why...

2010-01-25 02:20:31 WD2: disk1 "(RAID_slice)" Scan speed 19 below acceptable (norm 67)
2010-01-25 02:20:31 WD2: FAIL: dd if=/dev/rdisk1 of=/dev/null count=142 iseek=371472 bs=1048576 > /dev/null

It's always that same drive too. And the two of them are scanning over a dozen total drives. Makes me suspicious of that one. I think what's happening though is it's hitting at the same time as a cronned rsync from the boot drive, and I think that's the "preferred slice" for the mirror to read from, and rsync building its send list is what's causing things to slow down so much.


I work for the Department of Redundancy Department