On 2023/3/21 17:21, Martin Wilck wrote: > On Tue, 2023-03-21 at 16:55 +0800, Li Xiaokeng wrote: >> From: lixiaokeng <lixiaokeng@xxxxxxxxxx> >> >> When we add a new disk to a raid, it may return -EBUSY. >> >> The main process of --add: >> 1. dev_open >> 2. store_super1(st, di->fd) in write_init_super1 >> 3. fsync(di->fd) in write_init_super1 >> 4. close(di->fd) >> 5. ioctl(ADD_NEW_DISK) >> >> However, there will be some udev(change) event after step4. Then >> "/usr/sbin/mdadm --incremental ..." will be run, and the new disk >> will be add to md device. After that, ioctl will return -EBUSY. >> >> Here we add map_lock before write_init_super in "mdadm --add" >> to fix this race. >> >> Signed-off-by: Li Xiao Keng <lixiaokeng@xxxxxxxxxx> > > As noted in the previous thread about the topic, this will only help > if "mdadm -I" quits when it can't lock the device. Or am I overlooking > something? > I am sorry for missing previous email before sending patch. At first, I had similar doubts. But I test it, "Incremental" will be blocked if "Add" uses map_lock. Only when open and flock return error, map_lock() returns -1. It is hardly to happen. In commit "ad5bc697a", the return value of map_lock() is not checked. So I don't change the codes of the original map_lock(). If it's better to return error when map_lock fails, I will change my patch. Regards, Li Xiao Keng > Martin > > . >
