umount btrfs hang
0 [btrfs] Jan 30 08:57:58 daneel.nbux.org kernel: ? pick_next_task_fair+0x171/0x560 Jan 30 08:57:58 daneel.nbux.org kernel: ? __switch_to+0xa2/0x4e0 Jan 30 08:57:58 daneel.nbux.org kernel: btrfs_worker_helper+0x70/0x330 [btrfs] Jan 30 08:57:58 daneel.nbux.org kernel: process_one_work+0x1db/0x410 Jan 30 08:57:58 daneel.nbux.org kernel: worker_thread+0x2b/0x3d0 Jan 30 08:57:58 daneel.nbux.org kernel: ? process_one_work+0x410/0x410 Jan 30 08:57:58 daneel.nbux.org kernel: kthread+0x118/0x130 Jan 30 08:57:58 daneel.nbux.org kernel: ? kthread_create_on_node+0x70/0x70 Jan 30 08:57:58 daneel.nbux.org kernel: ? SyS_exit+0x13/0x20 Jan 30 08:57:58 daneel.nbux.org kernel: ret_from_fork+0x1f/0x30 ----- -- Christophe Yayon cyayon-l...@nbux.org -- 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: degraded permanent mount option
I just tested to boot with a single drive (raid1 degraded), even with degraded option in fstab and grub, unable to boot ! The boot process stop on initramfs. Is there a solution to boot with systemd and degraded array ? Thanks -- Christophe Yayon > On 27 Jan 2018, at 07:48, Christophe Yayon <cya...@nbux.org> wrote: > > I think you are right, i do not see any systemd message when degraded option > is missing and have to remount manually with degraded. > > It seems it is better to use mdadm for raid and btrfs over it as i > understand. Even in recent kernel ? > I hav me to do some bench and compare... > > Thanks > > -- > Christophe Yayon > >> On 27 Jan 2018, at 07:43, Andrei Borzenkov <arvidj...@gmail.com> wrote: >> >> 27.01.2018 09:40, Christophe Yayon пишет: >>> Hi, >>> >>> I am using archlinux with kernel 4.14, there is btrfs module in initrd. >>> In fstab root is mounted via UUID. As far as I know the UUID is the same >>> for all devices in raid array. >>> The system boot with no problem with degraded and only 1/2 root device. >> >> Then your initramfs does not use systemd. >> >>> -- >>> Christophe Yayon >>> cyayon-l...@nbux.org >>> >>> >>> >>>>> On Sat, Jan 27, 2018, at 06:50, Andrei Borzenkov wrote: >>>>> 26.01.2018 17:47, Christophe Yayon пишет: >>>>> Hi Austin, >>>>> >>>>> Thanks for your answer. It was my opinion too as the "degraded" >>>>> seems to be flagged as "Mostly OK" on btrfs wiki status page. I am >>>>> running Archlinux with recent kernel on all my servers (because of >>>>> use of btrfs as my main filesystem, i need a recent kernel).> > >>>>> Your idea to add a separate entry in grub.cfg with >>>>> rootflags=degraded is attractive, i will do this...> > >>>>> Just a last question, i thank that it was necessary to add >>>>> "degraded" option in grub.cfg AND fstab to allow boot in degraded >>>>> mode. I am not sure that only grub.cfg is sufficient...> > Yesterday, i >>>>> have done some test and boot a a system with only 1 of >>>>> 2 drive in my root raid1 array. No problem with systemd,> >>>> Are you using systemd in your initramfs (whatever >>>> implementation you are> using)? I just tested with dracut using systemd >>>> dracut module and it >>>> does not work - it hangs forever waiting for device. Of course, >>>> there is> no way to abort it and go into command line ... >>>> >>>> Oh, wait - what device names are you using? I'm using mount by >>>> UUID and> this is where the problem starts - /dev/disk/by-uuid/xxx will >>>> not appear> unless all devices have been seen once ... >>>> >>>> ... and it still does not work even if I change it to root=/dev/sda1 >>>> explicitly because sda1 will *not* be announced as "present" to >>>> systemd> until all devices have been seen once ... >>>> >>>> So no, it does not work with systemd *in initramfs*. Absolutely. >>> >>> >> > > -- > 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 -- 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: degraded permanent mount option
I think you are right, i do not see any systemd message when degraded option is missing and have to remount manually with degraded. It seems it is better to use mdadm for raid and btrfs over it as i understand. Even in recent kernel ? I hav me to do some bench and compare... Thanks -- Christophe Yayon > On 27 Jan 2018, at 07:43, Andrei Borzenkov <arvidj...@gmail.com> wrote: > > 27.01.2018 09:40, Christophe Yayon пишет: >> Hi, >> >> I am using archlinux with kernel 4.14, there is btrfs module in initrd. >> In fstab root is mounted via UUID. As far as I know the UUID is the same >> for all devices in raid array. >> The system boot with no problem with degraded and only 1/2 root device. > > Then your initramfs does not use systemd. > >> -- >> Christophe Yayon >> cyayon-l...@nbux.org >> >> >> >>> On Sat, Jan 27, 2018, at 06:50, Andrei Borzenkov wrote: >>> 26.01.2018 17:47, Christophe Yayon пишет: >>>> Hi Austin, >>>> >>>> Thanks for your answer. It was my opinion too as the "degraded" >>>> seems to be flagged as "Mostly OK" on btrfs wiki status page. I am >>>> running Archlinux with recent kernel on all my servers (because of >>>> use of btrfs as my main filesystem, i need a recent kernel).> > >>>> Your idea to add a separate entry in grub.cfg with >>>> rootflags=degraded is attractive, i will do this...> > >>>> Just a last question, i thank that it was necessary to add >>>> "degraded" option in grub.cfg AND fstab to allow boot in degraded >>>> mode. I am not sure that only grub.cfg is sufficient...> > Yesterday, i >>>> have done some test and boot a a system with only 1 of >>>> 2 drive in my root raid1 array. No problem with systemd,> >>> Are you using systemd in your initramfs (whatever >>> implementation you are> using)? I just tested with dracut using systemd >>> dracut module and it >>> does not work - it hangs forever waiting for device. Of course, >>> there is> no way to abort it and go into command line ... >>> >>> Oh, wait - what device names are you using? I'm using mount by >>> UUID and> this is where the problem starts - /dev/disk/by-uuid/xxx will >>> not appear> unless all devices have been seen once ... >>> >>> ... and it still does not work even if I change it to root=/dev/sda1 >>> explicitly because sda1 will *not* be announced as "present" to >>> systemd> until all devices have been seen once ... >>> >>> So no, it does not work with systemd *in initramfs*. Absolutely. >> >> > -- 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: degraded permanent mount option
Hi Chris, Thanks for this complete answer. I have to do some benchmark with mdadm raid and btrfs native raid... Thanks -- Christophe Yayon > On 26 Jan 2018, at 22:54, Chris Murphy <li...@colorremedies.com> wrote: > >> On Fri, Jan 26, 2018 at 7:02 AM, Christophe Yayon <cyayon-l...@nbux.org> >> wrote: >> >> Just a little question about "degraded" mount option. Is it a good idea to >> add this option (permanent) in fstab and grub rootflags for raid1/10 array ? >> Just to allow the system to boot again if a single hdd fail. > > No because it's going to open a window where a delayed member drive > will mean the volume is mounted degraded, which will happen silently. > And current behavior in such a case, any new writes go to single > chunks. Again it's silent. When the delayed drive appears, it's not > going to be added, the volume is still treated as degraded. And even > when you remount to bring them all together in a normal mount, Btrfs > will not automatically sync the drives, so you will still have some > single chunk writes on one drive not the other. So you have a window > of time where there can be data loss if a real failure occurs, and you > need degraded mounting. Further, right now Btrfs will only do one > degraded rw mount, and you *must* fix that degradedness before it is > umounted or else you will only ever be able to mount it again ro. > There are unmerged patches to work around this, so you'd need to > commit to building your own kernel. I can't see any way of reliably > using Btrfs in production for the described use case otherwise. You > can't depend on getting the delayed or replacement drive restored, and > the volume made healthy again, because ostensibly the whole point of > the setup is having good uptime and you won't have that assurance > unless you carry these patches. > > Also note that there are two kinds of degraded writes. a.) drive was > missing at mount time, and volume is mounted degraded, for raid1 > volumes you get single chunks written; to sync once the missing drive > appears you do a btrfs balance -dconvert=raid1,soft > -mconvert=raid1,soft which should be fairly fast; b.) if the drive > goes missing after a normal mount, Btrfs continues to write out raid1 > chunks; to sync once the missing drive appears you have to do a full > scrub or balance of the entire volume there's no shortcut. > > Anyway, for the described use case I think you're better off with > mdadm or LVM raid1 or raid10, and then format with Btrfs and DUP > metadata (default mkfs) in which case you get full error detection and > metadata error detection and correction, as well as the uptime you > want. > > -- > 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: degraded permanent mount option
Hi Austin, Thanks for your answer. It was my opinion too as the "degraded" seems to be flagged as "Mostly OK" on btrfs wiki status page. I am running Archlinux with recent kernel on all my servers (because of use of btrfs as my main filesystem, i need a recent kernel). Your idea to add a separate entry in grub.cfg with rootflags=degraded is attractive, i will do this... Just a last question, i thank that it was necessary to add "degraded" option in grub.cfg AND fstab to allow boot in degraded mode. I am not sure that only grub.cfg is sufficient... Yesterday, i have done some test and boot a a system with only 1 of 2 drive in my root raid1 array. No problem with systemd, but i added rootflags and fstab option. I didn't test with only rootflags. Thanks. -- Christophe Yayon cyayon-l...@nbux.org On Fri, Jan 26, 2018, at 15:18, Austin S. Hemmelgarn wrote: > On 2018-01-26 09:02, Christophe Yayon wrote: > > Hi all, > > > > I don't know if it the right place to ask. Sorry it's not... > No, it's just fine to ask here. Questions like this are part of why the > mailing list exists. > > > > Just a little question about "degraded" mount option. Is it a good idea to > > add this option (permanent) in fstab and grub rootflags for raid1/10 array > > ? Just to allow the system to boot again if a single hdd fail. > Some people will disagree with me on this, but I would personally > suggest not doing this. I'm of the opinion that running an array > degraded for any period of time beyond the bare minimum required to fix > it is a bad idea, given that: > * It's not a widely tested configuration, so you are statistically more > likely to run into previously unknown bugs. Even aside from that, there > are probably some edge cases that people have not yet found. > * There are some issues with older kernel versions trying to access the > array after it's been mounted writable and degraded when it's only two > devices in raid1 mode. This in turn is a good example of the above > point about not being widely tested, as it took quite a while for this > problem to come up on the mailing list. > * Running degraded is liable to be slower, because the filesystem has to > account for the fact that the missing device might reappear at any > moment. This is actually true of any replication system, not just BTRFS. > * For a 2 device raid1 volume, there is no functional advantage to > running degraded with one device compared to converting to just use a > single device (this is only true of BTRFS because of the fact that it's > trivial to convert things, while for MD and LVM it is extremely > complicated to do so online). > > Additionally, adding the `degraded` mount option won't actually let you > mount the root filesystem if you're using systemd as an init system, > because systemd refuses to mount BTRFS volumes which have devices missing. > > Assuming that the systemd thing isn't an issue for you, I would suggest > instead creating a separate GRUB entry with the option set in rootflags. > This will allow you to manually boot the system if the array is > degraded, but will make sure you notice during boot (in my case, I don't > even do that, but I'm also reasonably used to tweaking kernel parameters > from GRUB prior to booting the system that it would end up just wasting > space). > > > > Of course, i have some cron jobs to check my array health. > It's good to hear that you're taking the initiative to monitor things, > however this fact doesn't really change my assessment above. -- 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
degraded permanent mount option
Hi all, I don't know if it the right place to ask. Sorry it's not... Just a little question about "degraded" mount option. Is it a good idea to add this option (permanent) in fstab and grub rootflags for raid1/10 array ? Just to allow the system to boot again if a single hdd fail. Of course, i have some cron jobs to check my array health. Thanks. -- Christophe Yayon cyayon-l...@nbux.org -- 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
