Re: [PATCH] md: avoid modifying spares while the array is not suspended
"yu kuai" <[email protected]>
| Newsgroups | gmane.linux.raid,gmane.linux.kernel |
|---|---|
| Message-ID | <[email protected]> |
Hi, 在 2026/7/7 18:35, Abd-Alrhman Masalkhi 写道: > Hi Kuai, > > On Tue, Jul 07, 2026 at 09:12 +0800, yu kuai wrote: >> Hi, >> >> 在 2026/7/6 3:58, Abd-Alrhman Masalkhi 写道: >>>> The problem looks real, however, I think this will cause a change that user will be awared, >>>> if there are really spares that can be removed from conf, but array is not suspended here, >>>> user will still expect rdev will be removed from conf automatically. >>>> >>>> In md_start_sync, if suspend is false, can we check again after mddev_lock? If suspend is >>>> supposed to be true, we can release the lock and retry with suspend = true. >>>> >>> Yes, I see, and your approach is much better. But what do you think >>> about taking the lock first and then checking only once? >> I don't get what you mean. If we take the lock and then check that array should >> suspend, we still have to release the lock before we suspend the array. >> > Sorry, I was not clear. I meant, do we need to check twice, once before > taking the lock and once after? It seems that the check before taking the > lock is redundant. since the result would need to be checked again after > taking the lock anyway. > > Could we drop the check before taking the lock and only check whether > suspension is needed once while holding it? If suspension is needed, we > would release the lock, suspend the array, and then reacquire the lock. Thanks for the explanation, I understand now. Howerver, I still prefer to check first before holding the lock. Because the checking is much lower overhead than acquire reconfig_mutex, and the race window that rdev become spare is small, so it's unlikely we'll acquire reconfig_mtuex twice. > >> -- >> Thanks, >> Kuai -- Thanks, Kuai