-------- Original Message --------
Subject: Re: [PATCH RFC] btrfs: Add ctime/mtime update for btrfs device
add/remove.
From: David Sterba <dste...@suse.cz>
To: Qu Wenruo <quwen...@cn.fujitsu.com>
Date: 2014年05月29日 20:43
On Wed, Apr 16, 2014 at 05:02:32PM +0800, Qu Wenruo wrote:
@@ -1704,10 +1720,14 @@ int btrfs_rm_device(struct btrfs_root *root, char
*device_path)
ret = 0;
- /* Notify udev that device has changed */
- if (bdev)
+ if (bdev) {
+ /* Notify udev that device has changed */
btrfs_kobject_uevent(bdev, KOBJ_CHANGE);
+ /* Update ctime/mtime for device path for libblkid */
+ update_dev_time(device_path);
The change on the device comes after the uevent notification, is it
possible that the event is delivered and processed before the device
times are updated? I would say so.
If I understand the udev thing right, uevent notification is sent to
udevd and udevd process the notification.
For btrfs_rm_device(), it will send KOBJ_CHANGE uevent to udevd, and
udevd will *update* the ctime/mtime in /dev.
But the problems is, there is a time lag between uevent sending and
udevd updating the ctime/mtime,
which makes the ctime/mtime updating later than next 'btrfs dev scan'
commands.
Since the ctime/mtime is not changed, libblkid used by 'btrfs dev scan'
will still consider the removed disk as btrfs,
causing the bug I reported.
IMO the best method to deal the bug is to wait udevd processing the
uevent, but unfortunately, we can't even guarantee
that there is a udevd processing the uevent(like some embedded system
without udevd).
So I use update_dev_time() as a workaround, which provide a completely
synchronize method to update device file ctime/mtime.
And even the uevent is processed before the update_dev_time(), it makes
no harm except a new ctime/mtime.
Thanks,
Qu
+ }
+
error_brelse:
brelse(bh);
if (bdev)
--
To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
