On Mar 2, 2008, at 8:38, Michael Guntsche wrote:
Changing this sysfs entry to 0, gives me the expected result if I do a stop -> assemble with my 1.0 array. It starts reysncing and everything is ok. According to the replies in this bug, setting start_ro to 1 should NOT stop the automatic resync after a write to it, but this seems to have changed now. So, is this a change in behaviour or is it a bug. If it is the former, I probably need to talk with the debian guys about it, if it is a bug I wait for a fix and comment the entry in the mean time.
Answering myself here after reading through the manapges, this seems to be a regression. Furthermore this may yield to some nasty data corruption, well at least I think it will.
* --stop the array while resyncing. * set start_ro to 1* Start the array, automatic reconstruction does not start even after the data is been written to the ARRAY
* stop the array again * set start_ro to 0 * Start the array againThe array picks up the resync process where it stopped the first time even if there has already been data written to it, while it was started with start_ro = 1. Won't this yield corrupted data, since data BEFORE that offset might actually have changed in the mean time?
Kind regards, Michael
Attachment:
smime.p7s
Description: S/MIME cryptographic signature
