btrfs device ready purpose
I'm digging through piles of list emails and not really finding an answer to this. Maybe it's Friday and I'm just confused... [root@f26s ~]# btrfs device ready /dev/sda1 [root@f26s ~]# echo $? 0 [root@f26s ~]# btrfs device ready /dev/mapper/vg-1 [root@f26s ~]# echo $? 0 /dev/sda1 is a single device btrfs and it is present, 'btrfs fi show' finds it. /dev/mapper/vg-1 is one member of a two device Btrfs volume, the missing device is /dev/mapper/vg-2 and 'btrfs fi show' sees 1 but not 2 and says a device is missing. And yet the ready command completes and the exit code is the same, and I just don't understand the purpose of this command. The man page says "wait" but I don't see any waiting, so at the very least we probably need to come up with a more descriptive man page description. Thanks. -- Chris Murphy -- 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
Re: btrfs device ready purpose
07.07.2017 19:42, Chris Murphy пишет: > I'm digging through piles of list emails and not really finding an > answer to this. Maybe it's Friday and I'm just confused... > > > [root@f26s ~]# btrfs device ready /dev/sda1 > [root@f26s ~]# echo $? > 0 > [root@f26s ~]# btrfs device ready /dev/mapper/vg-1 > [root@f26s ~]# echo $? > 0 > > > /dev/sda1 is a single device btrfs and it is present, 'btrfs fi show' finds > it. > /dev/mapper/vg-1 is one member of a two device Btrfs volume, the > missing device is /dev/mapper/vg-2 and 'btrfs fi show' sees 1 but not > 2 and says a device is missing. > > And yet the ready command completes and the exit code is the same, and > I just don't understand the purpose of this command. The man page says > "wait" but I don't see any waiting, so at the very least we probably > need to come up with a more descriptive man page description. > Here on Ubuntu 16.04.2 man page says ready Check device to see if it has all of it’s devices in cache for mounting. Nothing about "wait". btrfs device ready is only useful during startup. The only check it does - whether kernel knows about all devices or not. It is really intended to be used from udev rule to delay attempt to mount filesystem until all devices have been seen. And it is only useful with systemd as it is the only program that actually pays attention to it. -- 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
Re: btrfs device ready purpose
On Fri, Jul 7, 2017 at 10:59 AM, Andrei Borzenkov wrote: > 07.07.2017 19:42, Chris Murphy пишет: >> I'm digging through piles of list emails and not really finding an >> answer to this. Maybe it's Friday and I'm just confused... >> >> >> [root@f26s ~]# btrfs device ready /dev/sda1 >> [root@f26s ~]# echo $? >> 0 >> [root@f26s ~]# btrfs device ready /dev/mapper/vg-1 >> [root@f26s ~]# echo $? >> 0 >> >> >> /dev/sda1 is a single device btrfs and it is present, 'btrfs fi show' finds >> it. >> /dev/mapper/vg-1 is one member of a two device Btrfs volume, the >> missing device is /dev/mapper/vg-2 and 'btrfs fi show' sees 1 but not >> 2 and says a device is missing. >> >> And yet the ready command completes and the exit code is the same, and >> I just don't understand the purpose of this command. The man page says >> "wait" but I don't see any waiting, so at the very least we probably >> need to come up with a more descriptive man page description. >> > > Here on Ubuntu 16.04.2 man page says > >ready >Check device to see if it has all of it’s devices in cache > for mounting. 4.11 man page says for 'btrfs device ready' Wait until all devices of a multiple-device filesystem are scanned and registered within the kernel module. Not sure when it was updated. > > Nothing about "wait". > > btrfs device ready is only useful during startup. The only check it does > - whether kernel knows about all devices or not. It is really intended > to be used from udev rule to delay attempt to mount filesystem until all > devices have been seen. And it is only useful with systemd as it is the > only program that actually pays attention to it. OK that make sense. I'm just not used to the convention where a user space tool does literally nothing for the user, and also has a man page entry as if it is for users. And I get that developers are users too, it just seems like an odd convention but whatever. -- Chris Murphy -- 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
Re: btrfs device ready purpose
On 2017-07-07 13:40, Chris Murphy wrote: On Fri, Jul 7, 2017 at 10:59 AM, Andrei Borzenkov wrote: 07.07.2017 19:42, Chris Murphy пишет: I'm digging through piles of list emails and not really finding an answer to this. Maybe it's Friday and I'm just confused... [root@f26s ~]# btrfs device ready /dev/sda1 [root@f26s ~]# echo $? 0 [root@f26s ~]# btrfs device ready /dev/mapper/vg-1 [root@f26s ~]# echo $? 0 /dev/sda1 is a single device btrfs and it is present, 'btrfs fi show' finds it. /dev/mapper/vg-1 is one member of a two device Btrfs volume, the missing device is /dev/mapper/vg-2 and 'btrfs fi show' sees 1 but not 2 and says a device is missing. And yet the ready command completes and the exit code is the same, and I just don't understand the purpose of this command. The man page says "wait" but I don't see any waiting, so at the very least we probably need to come up with a more descriptive man page description. Here on Ubuntu 16.04.2 man page says ready Check device to see if it has all of it’s devices in cache for mounting. 4.11 man page says for 'btrfs device ready' Wait until all devices of a multiple-device filesystem are scanned and registered within the kernel module. Not sure when it was updated. Nothing about "wait". btrfs device ready is only useful during startup. The only check it does - whether kernel knows about all devices or not. It is really intended to be used from udev rule to delay attempt to mount filesystem until all devices have been seen. And it is only useful with systemd as it is the only program that actually pays attention to it. OK that make sense. I'm just not used to the convention where a user space tool does literally nothing for the user, and also has a man page entry as if it is for users. And I get that developers are users too, it just seems like an odd convention but whatever. TBH, it's not even entirely useful during startup. Even if all the devices are supposedly there, the filesystem may still not mount because of any number of other issues, the inherent TOCTOU race not withstanding, and even if all the devices aren't there, the filesystem may still mount depending on what options you pass. -- 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
Re: btrfs device ready purpose
On Fri, Jul 07, 2017 at 11:40:04AM -0600, Chris Murphy wrote: > On Fri, Jul 7, 2017 at 10:59 AM, Andrei Borzenkov wrote: > > 07.07.2017 19:42, Chris Murphy пишет: > >> I'm digging through piles of list emails and not really finding an > >> answer to this. Maybe it's Friday and I'm just confused... > >> > >> > >> [root@f26s ~]# btrfs device ready /dev/sda1 > >> [root@f26s ~]# echo $? > >> 0 > >> [root@f26s ~]# btrfs device ready /dev/mapper/vg-1 > >> [root@f26s ~]# echo $? > >> 0 > >> > >> > >> /dev/sda1 is a single device btrfs and it is present, 'btrfs fi show' > >> finds it. > >> /dev/mapper/vg-1 is one member of a two device Btrfs volume, the > >> missing device is /dev/mapper/vg-2 and 'btrfs fi show' sees 1 but not > >> 2 and says a device is missing. > >> > >> And yet the ready command completes and the exit code is the same, and > >> I just don't understand the purpose of this command. The man page says > >> "wait" but I don't see any waiting, so at the very least we probably > >> need to come up with a more descriptive man page description. > >> > > > > Here on Ubuntu 16.04.2 man page says > > > >ready > >Check device to see if it has all of it’s devices in cache > > for mounting. > > 4.11 man page says for 'btrfs device ready' > Wait until all devices of a multiple-device filesystem are scanned and > registered within the kernel module. > > Not sure when it was updated. > > > > > > Nothing about "wait". > > > > btrfs device ready is only useful during startup. The only check it does > > - whether kernel knows about all devices or not. It is really intended > > to be used from udev rule to delay attempt to mount filesystem until all > > devices have been seen. And it is only useful with systemd as it is the > > only program that actually pays attention to it. > > OK that make sense. I'm just not used to the convention where a user > space tool does literally nothing for the user, and also has a man > page entry as if it is for users. And I get that developers are users > too, it just seems like an odd convention but whatever. The command is just a simple wrapper around the DEVICES_READY ioctl, but now that systemd has it's own wrapper tool, there are probably no users of that subcommand in 'btrfs' tool itself. We can enhance the documentation to state the expected purpose and that normal users can ignore it. -- 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
Re: btrfs device ready purpose
On Mon, Jul 17, 2017 at 9:54 AM, David Sterba wrote: > On Fri, Jul 07, 2017 at 11:40:04AM -0600, Chris Murphy wrote: >> On Fri, Jul 7, 2017 at 10:59 AM, Andrei Borzenkov >> wrote: >> > 07.07.2017 19:42, Chris Murphy пишет: >> >> I'm digging through piles of list emails and not really finding an >> >> answer to this. Maybe it's Friday and I'm just confused... >> >> >> >> >> >> [root@f26s ~]# btrfs device ready /dev/sda1 >> >> [root@f26s ~]# echo $? >> >> 0 >> >> [root@f26s ~]# btrfs device ready /dev/mapper/vg-1 >> >> [root@f26s ~]# echo $? >> >> 0 >> >> >> >> >> >> /dev/sda1 is a single device btrfs and it is present, 'btrfs fi show' >> >> finds it. >> >> /dev/mapper/vg-1 is one member of a two device Btrfs volume, the >> >> missing device is /dev/mapper/vg-2 and 'btrfs fi show' sees 1 but not >> >> 2 and says a device is missing. >> >> >> >> And yet the ready command completes and the exit code is the same, and >> >> I just don't understand the purpose of this command. The man page says >> >> "wait" but I don't see any waiting, so at the very least we probably >> >> need to come up with a more descriptive man page description. >> >> >> > >> > Here on Ubuntu 16.04.2 man page says >> > >> >ready >> >Check device to see if it has all of it’s devices in cache >> > for mounting. >> >> 4.11 man page says for 'btrfs device ready' >> Wait until all devices of a multiple-device filesystem are scanned and >> registered within the kernel module. >> >> Not sure when it was updated. >> >> >> > >> > Nothing about "wait". >> > >> > btrfs device ready is only useful during startup. The only check it does >> > - whether kernel knows about all devices or not. It is really intended >> > to be used from udev rule to delay attempt to mount filesystem until all >> > devices have been seen. And it is only useful with systemd as it is the >> > only program that actually pays attention to it. >> >> OK that make sense. I'm just not used to the convention where a user >> space tool does literally nothing for the user, and also has a man >> page entry as if it is for users. And I get that developers are users >> too, it just seems like an odd convention but whatever. > > The command is just a simple wrapper around the DEVICES_READY ioctl, but > now that systemd has it's own wrapper tool, there are probably no users > of that subcommand in 'btrfs' tool itself. We can enhance the > documentation to state the expected purpose and that normal users can > ignore it. What is the expected purpose? It flat out does not seem to work at all. It doesn't wait when devices are missing, as the man description says. And echo ? returns a 0 instead of 1. I'd expect the exit code is 0 to mean "yes all devices are ready", and exit code 1 "some devices not ready". But right now, I get the same result no matter what. So it seems to me it needs to be fixed in user space or it just needs to be removed. Where this stems from, is this 'help wanted' issue https://github.com/storaged-project/libblockdev/issues/244 The gist is that libblockdev needs to know whether a device can be mounted successfully without -o degraded, and that's basically what BTRFS_IOC_DEVICES_READY does. But at least in startup, the udev usage of this ioctl causes a hang. Literally systemd just sits there and will not try to mount such a volume, and it waits indefinitely, which is itself suboptimal. I think it'd be better to return a code. 0: is complete, degraded not required 1: is incomplete, degraded should mount it 2: is incomplete, degraded won't mount it Something like that. -- Chris Murphy -- 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
Re: btrfs device ready purpose
21.07.2017 17:36, Chris Murphy пишет: >> >> The command is just a simple wrapper around the DEVICES_READY ioctl, but >> now that systemd has it's own wrapper tool, there are probably no users >> of that subcommand in 'btrfs' tool itself. We can enhance the >> documentation to state the expected purpose and that normal users can >> ignore it. > > What is the expected purpose? It flat out does not seem to work at > all. It doesn't wait when devices are missing, as the man description > says. That's man page that is misleading. The intent was to let caller of "btrfs device ready" to know when it has to wait. > And echo ? returns a 0 instead of 1. I'd expect the exit code is > 0 to mean "yes all devices are ready", and exit code 1 "some devices > not ready". But right now, I get the same result no matter what. > That's not what I observe. linux-gtrk:~ # btrfs device ready /dev/sdb linux-gtrk:~ # echo $? 1 linux-gtrk:~ # btrfs-debug-tree /dev/sdb btrfs-progs v4.5.3+20160729 warning, device 2 is missing ... But if you call "btrfs device ready" AFTER kernel has already seen (or decided about) all devices, then it returns 0. Basically, this is not "filesystem ready" but "does kernel know about all devices for this filesystem". > So it seems to me it needs to be fixed in user space or it just needs > to be removed. > > Where this stems from, is this 'help wanted' issue > https://github.com/storaged-project/libblockdev/issues/244 > > The gist is that libblockdev needs to know whether a device can be > mounted successfully without -o degraded, and that's basically what > BTRFS_IOC_DEVICES_READY does. But at least in startup, the udev usage > of this ioctl causes a hang. Literally systemd just sits there and > will not try to mount such a volume, and it waits indefinitely, which > is itself suboptimal. Please do not confuse independent things. "btrfs device ready" simply tells caller whether all devices have been seen by kernel. This is poor man's solution for "can I mount it". What caller does with this information is outside of scope of btrfs. > I think it'd be better to return a code. > 0: is complete, degraded not required > 1: is incomplete, degraded should mount it > 2: is incomplete, degraded won't mount it > There is no way systemd can make use of this information using current static unit dependencies. Really, this topic came up more than once (including by you as well). systemd does not have adequate ways to represent multi-device objects (this goes beyond btrfs, Linux MD is good example). Sometimes it is possible to workaround it (Linux MD again). But at the end, systemd needs to offer framework where btrfs et al can plug in by providing status. Until this happens, discussion on this list is pointless. -- 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
Re: btrfs device ready purpose
On Fri, Jul 21, 2017 at 11:55 PM, Andrei Borzenkov wrote: > 21.07.2017 17:36, Chris Murphy пишет: >>> >>> The command is just a simple wrapper around the DEVICES_READY ioctl, but >>> now that systemd has it's own wrapper tool, there are probably no users >>> of that subcommand in 'btrfs' tool itself. We can enhance the >>> documentation to state the expected purpose and that normal users can >>> ignore it. >> >> What is the expected purpose? It flat out does not seem to work at >> all. It doesn't wait when devices are missing, as the man description >> says. > > That's man page that is misleading. The intent was to let caller of > "btrfs device ready" to know when it has to wait. > >> And echo ? returns a 0 instead of 1. I'd expect the exit code is >> 0 to mean "yes all devices are ready", and exit code 1 "some devices >> not ready". But right now, I get the same result no matter what. >> > > That's not what I observe. > > linux-gtrk:~ # btrfs device ready /dev/sdb > linux-gtrk:~ # echo $? > 1 > linux-gtrk:~ # btrfs-debug-tree /dev/sdb > btrfs-progs v4.5.3+20160729 > warning, device 2 is missing > ... > > But if you call "btrfs device ready" AFTER kernel has already seen (or > decided about) all devices, then it returns 0. Basically, this is not > "filesystem ready" but "does kernel know about all devices for this > filesystem". OK! Super! This is the critical bit of behavior. My test is flawed. The multiple device volume was visible to the kernel, and then I merely deactivated the LV. The kernel had seen it, and isn't "missing" it at least in terms of 'btrfs device ready' whereas 'btrfs fi show' does report it as missing but is also using different ioctls. Even if I use 'btrfs device scan' a subsequent 'btrfs device ready' exits 0. But if I set skip activation 'lvchange -ky' and reboot, 'btrfs device ready' on the non-missing device does result in an exit code of 1. > Please do not confuse independent things. "btrfs device ready" simply > tells caller whether all devices have been seen by kernel. This is poor > man's solution for "can I mount it". What caller does with this > information is outside of scope of btrfs. Got it. Thanks. > >> I think it'd be better to return a code. >> 0: is complete, degraded not required >> 1: is incomplete, degraded should mount it >> 2: is incomplete, degraded won't mount it >> > > There is no way systemd can make use of this information using current > static unit dependencies. Really, this topic came up more than once > (including by you as well). systemd does not have adequate ways to > represent multi-device objects (this goes beyond btrfs, Linux MD is good > example). Sometimes it is possible to workaround it (Linux MD again). > But at the end, systemd needs to offer framework where btrfs et al can > plug in by providing status. Until this happens, discussion on this list > is pointless. Understood. -- Chris Murphy -- 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
Re: btrfs device ready purpose
I just did an additional test that's pretty icky behavior. 2x HDD device Btrfs volume. Add both devices and `btrfs devices ready` exits with 0 as expected. Physically remove both USB devices. Reconnect one device. `btrfs device ready` still exits 0. That's definitely not good. (If I leave that one device connected and reboot, `btrfs device ready` exits 1). Chris Murphy -- 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
Re: btrfs device ready purpose
On Sat, Jul 22, 2017 at 12:06:17PM -0600, Chris Murphy wrote: > I just did an additional test that's pretty icky behavior. > > 2x HDD device Btrfs volume. Add both devices and `btrfs devices ready` > exits with 0 as expected. Physically remove both USB devices. > Reconnect one device. `btrfs device ready` still exits 0. That's > definitely not good. (If I leave that one device connected and reboot, > `btrfs device ready` exits 1). In a slightly less-specific way, this has been a problem pretty much since the inception of the FS. It's not possible to do the reverse of the "scan" operation on a device -- that is, invalidate/ remove the device's record in the kernel. So, as you've discovered here, if you have a device which is removed (overwritten, unplugged), the kernel still thinks it's a part of the FS. It's something I recall being talked about a bit, some years ago. I don't recall now why it was going to be useful, though. I think you have a good use-case for such a new ioctl (or extension to the SCAN_DEV ioctl) now, though. Hugo. -- Hugo Mills | UNIX: Italian pen maker hugo@... carfax.org.uk | http://carfax.org.uk/ | PGP: E2AB1DE4 | signature.asc Description: Digital signature
Re: btrfs device ready purpose
On Sat, Jul 22, 2017 at 06:15:58PM +, Hugo Mills wrote: > On Sat, Jul 22, 2017 at 12:06:17PM -0600, Chris Murphy wrote: > > I just did an additional test that's pretty icky behavior. > > > > 2x HDD device Btrfs volume. Add both devices and `btrfs devices ready` > > exits with 0 as expected. Physically remove both USB devices. > > Reconnect one device. `btrfs device ready` still exits 0. That's > > definitely not good. (If I leave that one device connected and reboot, > > `btrfs device ready` exits 1). > >In a slightly less-specific way, this has been a problem pretty > much since the inception of the FS. It's not possible to do the > reverse of the "scan" operation on a device -- that is, invalidate/ > remove the device's record in the kernel. So, as you've discovered > here, if you have a device which is removed (overwritten, unplugged), > the kernel still thinks it's a part of the FS. Alas, this needs to be fixed. The reproducers I posted last week give data corruption in case a device that was once a part of the FS is reconnected. It doesn't matter what it contains now -- be it another part of the FS or something totally unrelated, as far as the device node (/dev/loop0, /dev/sda1, etc) is reused, degraded mounts get confused. It wasn't urgent before as degraded mounts were broken before Qu's chunk check patch (that's not even merged yet) -- but once running degraded is not an emergency, there'll be folks doing so for an extended time. >It's something I recall being talked about a bit, some years ago. I > don't recall now why it was going to be useful, though. I think you > have a good use-case for such a new ioctl (or extension to the > SCAN_DEV ioctl) now, though. Such an ioctl would be inherently racey. Even current udev code is -- mounting right after losetup often fails, sometimes you even need to sleep longer than 1 second. With the above in mind, I see no way other than invalidating and re-checking all known devices at mount time. Meow! -- ⢀⣴⠾⠻⢶⣦⠀ ⣾⠁⢠⠒⠀⣿⡁ A dumb species has no way to open a tuna can. ⢿⡄⠘⠷⠚⠋⠀ A smart species invents a can opener. ⠈⠳⣄ A master species delegates. -- 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
Re: btrfs device ready purpose
On Sat, Jul 22, 2017 at 1:58 PM, Adam Borowski wrote: > On Sat, Jul 22, 2017 at 06:15:58PM +, Hugo Mills wrote: >> On Sat, Jul 22, 2017 at 12:06:17PM -0600, Chris Murphy wrote: >> > I just did an additional test that's pretty icky behavior. >> > >> > 2x HDD device Btrfs volume. Add both devices and `btrfs devices ready` >> > exits with 0 as expected. Physically remove both USB devices. >> > Reconnect one device. `btrfs device ready` still exits 0. That's >> > definitely not good. (If I leave that one device connected and reboot, >> > `btrfs device ready` exits 1). >> >>In a slightly less-specific way, this has been a problem pretty >> much since the inception of the FS. It's not possible to do the >> reverse of the "scan" operation on a device -- that is, invalidate/ >> remove the device's record in the kernel. So, as you've discovered >> here, if you have a device which is removed (overwritten, unplugged), >> the kernel still thinks it's a part of the FS. > > Alas, this needs to be fixed. The reproducers I posted last week give data > corruption in case a device that was once a part of the FS is reconnected. > It doesn't matter what it contains now -- be it another part of the FS or > something totally unrelated, as far as the device node (/dev/loop0, > /dev/sda1, etc) is reused, degraded mounts get confused. > > It wasn't urgent before as degraded mounts were broken before Qu's chunk > check patch (that's not even merged yet) -- but once running degraded is > not an emergency, there'll be folks doing so for an extended time. > >>It's something I recall being talked about a bit, some years ago. I >> don't recall now why it was going to be useful, though. I think you >> have a good use-case for such a new ioctl (or extension to the >> SCAN_DEV ioctl) now, though. > > Such an ioctl would be inherently racey. Even current udev code is -- > mounting right after losetup often fails, sometimes you even need to sleep > longer than 1 second. With the above in mind, I see no way other than > invalidating and re-checking all known devices at mount time. If we go back even further in time, what I'm trying to avoid is the problem with DE's where the user connects a two device Btrfs, and then they want to eject it. The DE is already confused because behind the scenes it has actually mounted each device to two different mount points, which Btrfs allows (it's one file system, on two mount points). That's confusing, but not a big problem. The big problem happens when the user wants to stop using that file system. So they eject one of the two appearing devices (which should of course only be one with Btrfs) and behind the scenes udisksd umounts just one of the mountpoints and then appears to delete that device node, which in effect makes the still mounted file system degraded, and results in corruption. Btrfs fixes this up on the next mount of both devices. But it's just asking for trouble. Output of this behavior here: https://bugs.freedesktop.org/show_bug.cgi?id=87277#c3 So then I started to look at whether it's possible to easily determine in advance if a Btrfs file system is single or multiple device, and let udisksd have a policy where it will just ignore multiple device Btrfs entirely - just don't support it until the guts of all this infrastructure gets better. 'strace btrfs filesystem show' curiously shows BTRFS_IOC_FS_INFO is only called for single device Btrfs. There is seemingly a much more esoteric, btrfs-progs only method for getting information for multiple device Btrfs volumes. And therefore I'm not certain if BTRFS_IOC_FS_INFO supports multiple device Btrfs, and would return num_devices so that it's possible to know whether to ignore devices for a multiple device Btrfs volume. *sigh* Chris Murphy -- Chris Murphy -- 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
Re: btrfs device ready purpose
Chris Murphy posted on Sat, 22 Jul 2017 14:35:25 -0600 as excerpted: > If we go back even further in time, what I'm trying to avoid is the > problem with DE's where the user connects a two device Btrfs, and then > they want to eject it. The DE is already confused because behind the > scenes it has actually mounted each device to two different mount > points, which Btrfs allows (it's one file system, on two mount points). > That's confusing, but not a big problem. The big problem happens when > the user wants to stop using that file system. So they eject one of the > two appearing devices (which should of course only be one with Btrfs) > and behind the scenes udisksd umounts just one of the mountpoints and > then appears to delete that device node, which in effect makes the still > mounted file system degraded, and results in corruption. > > Btrfs fixes this up on the next mount of both devices. But it's just > asking for trouble. > > Output of this behavior here: > https://bugs.freedesktop.org/show_bug.cgi?id=87277#c3 Ugh. Yet another reason for me to be glad I've neutered that behavior on my installation of my DE of choice.[1] But the main problem would appear to be the still lacking in the after all still not yet fully stable and under heavy development btrfs, concept of device tracking and disappearance/reappearance handling. Without that, all sorts of would-be expected multi-device behavior is missing. As it happens, the device tracking concept/feature was necessary for the now long back-burnered hot-spare feature, so got pulled into that patch set, along with the per-chunk device availability check that allows proper degraded writable-mount raid1, etc. Of course the latter got dusted off and now appears close to merge (yay!, double-yay since all my btrfs are raid1 or dup, here, and it could come in quite handy if an ssd starts acting up!), but the rest of that patch set, AFAIK, remains back-burnered with no preliminary target merge kernel set. Perhaps the next bit of it we need to dust off and get ready to merge is the real dynamic device detection stuff. Of course that'll make the hot- spares patch set smaller and easier to merge in the end, but it should also make fixing a whole family of issues related to the fact that btrfs really doesn't detect device disappearance either go away directly, or make the patches much more trivial than they would be otherwise, since we simply don't have the functionality we need for it, yet. --- [1] My DE: A "lite" version of kde/plasma, without the semantic-desktop stuff and without the device detection, etc. It still build/link/run depends on solid for what would be device detection/activation, but that in turn run-time depends on udisks. But fortunately, udisks is only a run-time dep, with the executable actually a script after all so it's not going to be linked in, so as a gentooer I have a few alternatives including the one I've taken, providing a "null-package" udisks package that installs nothing and depends on nothing, so devices don't get auto- mounted, which makes me happy, but I also don't have to worry about all the stuff udisks would otherwise pull in in its turn. Not like they'd be automountable anyway given that I don't have policykit, etc, installed, but this way I don't have to worry about the additional deps, either. I get a few complaints in the log when plasma starts up, but other than that, it behaves as I want -- no mounts unless I specifically ask for them either as root (usually via sudo), or with the appropriate fstab options. To let it behave otherwise and do automatic mounts without that sort of strict control is practically /begging/ for unexpected/undefined behavior, some of which, no surprise given the problems MS has had with this whole idea that we should have learned from, turns out to be data- loss and/or security risky, as it is here. -- Duncan - List replies preferred. No HTML msgs. "Every nonfree program has a lord, a master -- and if you use the program, he is your master." Richard Stallman -- 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