On Wed, 2023-03-15 at 22:57 +0800, Li Xiao Keng wrote: > > > On 2023/3/15 22:14, Martin Wilck wrote: > > On Wed, 2023-03-15 at 21:10 +0800, Li Xiao Keng wrote: > > > > > > > I test move close() after ioctl(). The reason of EBUSY is that > > > mdadm > > > open(sdf) with O_EXCL. So fd should be closed before ioctl. When > > > I > > > remove > > > O_EXCL, ioctl() will return success. > > > > This makes sense. I suppose mdadm must use O_EXCL if it modifies > > RAID > > meta data, otherwise data corruption is just too likely. It is also > > impossible to drop the O_EXCL flag with fcntl() without closing the > > fd. > > > > So, if mdadm must close the fd before calling ioctl(), the race can > > hardly be avoided. The close() will cause a uevent, and nothing > > prevents the udev rules from running before the ioctl() returns. > > > Now I find that close() cause a change udev. Is it necessary to > import > "mdadm --incremental --export" when change udev cause? Can we ignore > it? Normally this is what you want to happen if a change uevent for a MD member device is processed. The case you're looking at is the exception, as another instance of mdamn is handling the device right at this point in time. Martin
