Am Freitag, 30. Mai 2008 03:54:30 schrieb Neil Brown: > On Tuesday May 27, jpiszcz@xxxxxxxxxxxxxxx wrote: > > >>> Exactly. reboot pretty much deosn't do any good, afterwars the raid > > >>> resyncs, > > >>> which takes full 7h here. > > >> > > >> There shouldn't be a resync. Presumably nothing is writing to the > > >> array, and moments after the last write, the array will have been > > >> flagged as 'clean' and will not require a resync after a reboot. > > > > ^^^^^^^^^^^^^^^^^^^^^^ > > > > His host crashed != reboot so that is the reason for the resync. > > If the host crashes will nothing is being written to the array, the > array would be marked clean, so a resync will still not be required. > You should only get a resync if the host crashing within 200msecs of > the last write completing. > > NeilBrown Well, I hoped to ensure this wouldn't happen by the way I reset the box: first force sync by alt-sysrq-s, wait a moment, remount in ro by alt-sysrq-u, wait again then reboot with alt-sysrq-b. Maybe the ro-remount failed due to the zombie hogging the fs, wild guess. -- -----BEGIN GEEK CODE BLOCK----- Version: 3.12 GCS d--(+)@ s-:+ a- C++++ UL++ P+>++ L+++>++++ E-- W++ N o? K- w--(---) !O M+ V- PS+ PE Y++ PGP t++(---)@ 5 X+(++) R+(++) tv--(+)@ b++(+++) DI+++ D- G++ e* h>++ r* y? ------END GEEK CODE BLOCK------ http://www.vorratsdatenspeicherung.de -- To unsubscribe from this list: send the line "unsubscribe linux-raid" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
