On Wed, Jan 06 2016, Shaohua Li wrote: > On Wed, Jan 06, 2016 at 12:12:05PM +1100, NeilBrown wrote: >> On Wed, Jan 06 2016, Shaohua Li wrote: >> >> > When we hotadd journal for array which isn't created with journal, the >> > array might be running write requests. Such writes aren't protected by >> > journal yet, so we can't skip disk flush. There is no easy way to know >> > when all such writes are finished, but the time should be enough after >> > reclaim runs once. >> >> There is an easy way to know when such writes are finished. >> Call mddev_suspend(mddev). This is used for the more intrusive >> reconfiguration such as initiating a reshape. >> I think it would be perfectly appropriate to >> call mddev_suspend() >> attach the journal >> call mddev_resume() > > hot add/remove disk is called in raid5d, we can't wait IO there. > mddev_suspend() will wait IO. So we can't call mddev_suspend() Fair point. I wonder if it should be though. Activating a spare is a very different thing to activating a journal. Activating a spare is just one small step on the way from being degraded to being optimal. Activating a spare is a distinct change in how the array behaves, not unlike adding a bitmap. So I think that adding a journal should happen a lot like adding a bitmap. When you write "journal" to the 'state' file, or call ADD_NEW_DISK with MD_DISK_JOURNAL set, ->hot_add_disk() should be called directly, a bit like add_bound_rdev() does when adding a device to a 'linear' array. Having remove_and_add_spares() add a journal certainly doesn't seem like a good idea. Thanks, NeilBrown
Attachment:
signature.asc
Description: PGP signature
