Re: [PATCH RFC] btrfs: Add ctime/mtime update for btrfs device add/remove.

[Qu Wenruo <quwenruo@cn.fujitsu.com>]

-------- Original Message --------
Subject: Re: [PATCH RFC] btrfs: Add ctime/mtime update for btrfs device 
add/remove.
From: David Sterba <dsterba@suse.cz>
To: Qu Wenruo <quwenruo@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)