On 2016-09-12 16:25, Chris Murphy wrote:
On Mon, Sep 12, 2016 at 5:24 AM, Austin S. Hemmelgarn
<[email protected]> wrote:
After device discovery, specify UUID=<volume UUID> instead of a device node.
Oh yeah good point, -U --uuid is also doable. I'm not sure what the
benefit is of using sysfs to delete a device's node after umounting.
If the umount isn't successful or the accounting for all mount points
isn't right, there is no warning for device delete, it's gone and it's
like physically yanking the device out of the port. Seems dangerous
for udisksd to use that?
Unbinding the device node from the driver forces the driver to flush all
commands and then stop talking to the device. In essence, this is
insurance that everything that got written to the device is actually on
the device. They're also trying to emulate the Windows behavior of
making the disk disappear when you tell the system to prep it for
physical disconnection.
I personally feel it's more important that we fix the whole UUID issue
first. If we fix that, it is likely to at least make things better in this
particular case as well.
Fair enough.
The problem with trying to get this fixed upstream
in userspace is that udisks is essentially deprecated because of the work on
storaged (which will almost certainly depend on systemd), so you're almost
certainly get nothing fixed until someone decides to fork it and maintain it
themselves like happened for ConsoleKit.
As far as what udisks is doing wrong, based on what you've said and minimal
experimentation on my systems, the issue is that it's not identifying the
array as one filesystem. They mount by device node to try and avoid the
UUID issues (because they affect every filesystem to some degree), but
because of that they see a bunch of filesystems.
By trying to avoid the UUID issues, they end up with another problem.
In this case though, it's really only a problem for BTRFS, and it
technically is a result of our design, not theirs, as what we've done
with integrating the volume management into the filesystem isn't
something that's ever really been used on removable media before.
I guess right now the only sure fire options they have:
a. Don't automount any Btrfs. (This is what I've recommended.)
b. pass --uuid as well as device= for each device in the array as
discovered by BTRFS_IOC_FS_INFO and BTRFS_IOC_DEV_INFO: while also not
mounting by device node alone for Btrfs.
It's important to differentiate between auto-mounting (udisks default),
on-demand mounting (what autofs and BSD's amd actually do), and manual
mounting as a regular user (the other operational mode for udisks). In
this case, both operational modes for udisks are broken with BTRFS, but
the autofs/amd method works as long as you configure them right. On my
system for example, I have an autofs directory set up to do on-demand
mounting by device node, and it works perfectly fine with multi-disk
BTRFS filesystems, because the kernel handles the bind mounting of the
already mounted FS correctly.
--
To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in
the body of a message to [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html
