Re: degraded permanent mount option

On 2018-01-30 14:50, Tomasz Pala wrote: On Tue, Jan 30, 2018 at 08:46:32 -0500, Austin S. Hemmelgarn wrote: I personally think the degraded mount option is a mistake as this assumes that a lightly degraded system is not able to work which is false. If the system can mount to some working state

Re: degraded permanent mount option

On Tue, Jan 30, 2018 at 08:46:32 -0500, Austin S. Hemmelgarn wrote: >> I personally think the degraded mount option is a mistake as this >> assumes that a lightly degraded system is not able to work which is false. >> If the system can mount to some working state then it should mount >>

Re: degraded permanent mount option

Just one final word, as all was already said: On Tue, Jan 30, 2018 at 11:30:31 -0500, Austin S. Hemmelgarn wrote: >> In other words, is it: >> - the systemd that threats btrfs WORSE than distributed filesystems, OR >> - btrfs that requires from systemd to be threaded BETTER than other fss? > Or

Re: degraded permanent mount option

On Tue, Jan 30, 2018 at 11:30:31 -0500, Austin S. Hemmelgarn wrote: >> - crypto below software RAID means double-encryption (wasted CPU), > It also means you leak no information about your storage stack. If JBOD > you're sufficiently worried about data protection that you're using >

Re: degraded permanent mount option

On 2018-01-30 10:09, Tomasz Pala wrote: On Mon, Jan 29, 2018 at 08:42:32 -0500, Austin S. Hemmelgarn wrote: Yes. They are stupid enough to fail miserably with any more complicated setups, like stacking volume managers, crypto layer, network attached storage etc. I think you mean any setup

Re: degraded permanent mount option

On Tue, Jan 30, 2018 at 16:09:50 +0100, Tomasz Pala wrote: >> BCP for over a >> decade has been to put multipathing at the bottom, then crypto, then >> software RAID, than LVM, and then whatever filesystem you're using. > > Really? Let's enumerate some caveats of this: > > - crypto below

Re: degraded permanent mount option

On Tue, Jan 30, 2018 at 10:05:34 -0500, Austin S. Hemmelgarn wrote: >> Instead, they should move their legs continuously and if the train is > not >> on the station yet, just climb back and retry. > No, that's really not a good analogy given the fact that that check for > the presence of a

Re: degraded permanent mount option

On Mon, Jan 29, 2018 at 21:44:23 -0700, Chris Murphy wrote: > Btrfs is orthogonal to systemd's willingness to wait forever while > making no progress. It doesn't matter what it is, it shouldn't wait > forever. It times out after 90 seconds (by default) and then it fails the mount entirely. > It

Re: degraded permanent mount option

On Mon, Jan 29, 2018 at 14:00:53 -0500, Austin S. Hemmelgarn wrote: > We already do so in the accepted standard manner. If the mount fails > because of a missing device, you get a very specific message in the > kernel log about it, as is the case for most other common errors (for > uncommon

Re: degraded permanent mount option

On Mon, Jan 29, 2018 at 08:42:32 -0500, Austin S. Hemmelgarn wrote: >> Yes. They are stupid enough to fail miserably with any more complicated >> setups, like stacking volume managers, crypto layer, network attached >> storage etc. > I think you mean any setup that isn't sensibly layered. No, I

Re: degraded permanent mount option

On 2018-01-30 08:46, Tomasz Pala wrote: On Mon, Jan 29, 2018 at 08:05:42 -0500, Austin S. Hemmelgarn wrote: Seriously, _THERE IS A RACE CONDITION IN SYSTEMD'S CURRENT HANDLING OF THIS_. It's functionally no different than prefacing an attempt to send a signal to a process by checking if the

Re: degraded permanent mount option

On Mon, Jan 29, 2018 at 08:05:42 -0500, Austin S. Hemmelgarn wrote: > Seriously, _THERE IS A RACE CONDITION IN SYSTEMD'S CURRENT HANDLING OF > THIS_. It's functionally no different than prefacing an attempt to send > a signal to a process by checking if the process exists, or trying to > see

Re: degraded permanent mount option

On 2018-01-29 16:54, waxhead wrote: Austin S. Hemmelgarn wrote: On 2018-01-29 12:58, Andrei Borzenkov wrote: 29.01.2018 14:24, Adam Borowski пишет: ... So any event (the user's request) has already happened.  A rc system, of which systemd is one, knows whether we reached the "want root

Re: degraded permanent mount option

On Mon, Jan 29, 2018 at 1:54 AM, Tomasz Pala wrote: > On Sun, Jan 28, 2018 at 17:00:46 -0700, Chris Murphy wrote: > >> systemd can't possibly need to know more information than a person >> does in the exact same situation in order to do the right thing. No >> human would wait 10

Re: degraded permanent mount option

Austin S. Hemmelgarn wrote: On 2018-01-29 12:58, Andrei Borzenkov wrote: 29.01.2018 14:24, Adam Borowski пишет: ... So any event (the user's request) has already happened.  A rc system, of which systemd is one, knows whether we reached the "want root filesystem" or "want secondary

Re: degraded permanent mount option

On 2018-01-29 12:58, Andrei Borzenkov wrote: 29.01.2018 14:24, Adam Borowski пишет: ... So any event (the user's request) has already happened. A rc system, of which systemd is one, knows whether we reached the "want root filesystem" or "want secondary filesystems" stage. Once you're there,

Re: degraded permanent mount option

29.01.2018 14:24, Adam Borowski пишет: ... > > So any event (the user's request) has already happened. A rc system, of > which systemd is one, knows whether we reached the "want root filesystem" or > "want secondary filesystems" stage. Once you're there, you can issue the > mount() call and let

Re: degraded permanent mount option

On 2018-01-27 17:42, Tomasz Pala wrote: On Sat, Jan 27, 2018 at 14:26:41 +0100, Adam Borowski wrote: It's quite obvious who's the culprit: every single remaining rc system manages to mount degraded btrfs without problems. They just don't try to outsmart the kernel. Yes. They are stupid

Re: degraded permanent mount option

On 2018-01-29 06:24, Adam Borowski wrote: On Mon, Jan 29, 2018 at 09:54:04AM +0100, Tomasz Pala wrote: it is a btrfs drawback that doesn't provice anything else except for this IOCTL with it's logic How can it provide you with something it doesn't yet have? If you want the information, call

Re: degraded permanent mount option

On Mon, Jan 29, 2018 at 09:54:04AM +0100, Tomasz Pala wrote: > On Sun, Jan 28, 2018 at 17:00:46 -0700, Chris Murphy wrote: > > > systemd can't possibly need to know more information than a person > > does in the exact same situation in order to do the right thing. No > > human would wait 10

Re: degraded permanent mount option

On Sun, Jan 28, 2018 at 17:00:46 -0700, Chris Murphy wrote: > systemd can't possibly need to know more information than a person > does in the exact same situation in order to do the right thing. No > human would wait 10 minutes, let alone literally the heat death of the > planet for "all devices

Re: degraded permanent mount option

On Sun, Jan 28, 2018 at 3:39 PM, Tomasz Pala wrote: > On Sun, Jan 28, 2018 at 13:02:08 -0700, Chris Murphy wrote: > >>> Tell me please, if you mount -o degraded btrfs - what would >>> BTRFS_IOC_DEVICES_READY return? >> >> case BTRFS_IOC_DEVICES_READY: >> ret =

Re: degraded permanent mount option

On Sun, Jan 28, 2018 at 13:28:55 -0700, Chris Murphy wrote: >> Are you sure you really understand the problem? No mount happens because >> systemd waits for indication that it can mount and it never gets this >> indication. > > "not ready" is rather vague terminology but yes that's how systemd >

Re: degraded permanent mount option

On Sun, Jan 28, 2018 at 13:02:08 -0700, Chris Murphy wrote: >> Tell me please, if you mount -o degraded btrfs - what would >> BTRFS_IOC_DEVICES_READY return? > > case BTRFS_IOC_DEVICES_READY: > ret = btrfs_scan_one_device(vol->name, FMODE_READ, > _fs_type, _devices); >

Re: degraded permanent mount option

On Sun, Jan 28, 2018 at 1:06 AM, Andrei Borzenkov wrote: > 27.01.2018 18:22, Duncan пишет: >> Adam Borowski posted on Sat, 27 Jan 2018 14:26:41 +0100 as excerpted: >> >>> On Sat, Jan 27, 2018 at 12:06:19PM +0100, Tomasz Pala wrote: On Sat, Jan 27, 2018 at 13:26:13 +0300,

Re: degraded permanent mount option

On Sat, Jan 27, 2018 at 5:39 PM, Tomasz Pala wrote: > On Sat, Jan 27, 2018 at 15:22:38 +, Duncan wrote: > >>> manages to mount degraded btrfs without problems. They just don't try >>> to outsmart the kernel. >> >> No kidding. >> >> All systemd has to do is leave the mount

Re: degraded permanent mount option

28.01.2018 18:57, Duncan пишет: > Andrei Borzenkov posted on Sun, 28 Jan 2018 11:06:06 +0300 as excerpted: > >> 27.01.2018 18:22, Duncan пишет: >>> Adam Borowski posted on Sat, 27 Jan 2018 14:26:41 +0100 as excerpted: >>> On Sat, Jan 27, 2018 at 12:06:19PM +0100, Tomasz Pala wrote: > On

Re: degraded permanent mount option

Andrei Borzenkov posted on Sun, 28 Jan 2018 11:06:06 +0300 as excerpted: > 27.01.2018 18:22, Duncan пишет: >> Adam Borowski posted on Sat, 27 Jan 2018 14:26:41 +0100 as excerpted: >> >>> On Sat, Jan 27, 2018 at 12:06:19PM +0100, Tomasz Pala wrote: On Sat, Jan 27, 2018 at 13:26:13 +0300,

Re: degraded permanent mount option

On Sun, Jan 28, 2018 at 01:00:16 +0100, Tomasz Pala wrote: > It can't mount degraded, because the "missing" device might go online a > few seconds ago. s/ago/after/ >> The central problem is the lack of a timer and time out. > > You got mdadm-last-resort@.timer/service above, if btrfs doesn't

Re: degraded permanent mount option

On Sun, Jan 28, 2018 at 11:06:06 +0300, Andrei Borzenkov wrote: >> All systemd has to do is leave the mount alone that the kernel has >> already done, > > Are you sure you really understand the problem? No mount happens because > systemd waits for indication that it can mount and it never gets

Re: degraded permanent mount option

27.01.2018 18:22, Duncan пишет: > Adam Borowski posted on Sat, 27 Jan 2018 14:26:41 +0100 as excerpted: > >> On Sat, Jan 27, 2018 at 12:06:19PM +0100, Tomasz Pala wrote: >>> On Sat, Jan 27, 2018 at 13:26:13 +0300, Andrei Borzenkov wrote: >>> > I just tested to boot with a single drive (raid1

Re: degraded permanent mount option

On Sat, Jan 27, 2018 at 15:22:38 +, Duncan wrote: >> manages to mount degraded btrfs without problems. They just don't try >> to outsmart the kernel. > > No kidding. > > All systemd has to do is leave the mount alone that the kernel has > already done, instead of insisting it knows what's

Re: degraded permanent mount option

On Sat, Jan 27, 2018 at 14:12:01 -0700, Chris Murphy wrote: > doesn't count devices itself. The Btrfs systemd udev rule defers to > Btrfs kernel code by using BTRFS_IOC_DEVICES_READY. And it's totally > binary. Either they are all ready, in which case it exits 0, and if > they aren't all ready it

Re: degraded permanent mount option

On Sat, Jan 27, 2018 at 13:57:29 -0700, Chris Murphy wrote: > The Btrfs systemd udev rule is a sledghammer because it has no > timeout. It neither times out and tries to mount anyway, nor does it > time out and just drop to a dracut prompt. There are a number of > things in systemd startups that

Re: degraded permanent mount option

On Sat, Jan 27, 2018 at 14:26:41 +0100, Adam Borowski wrote: > It's quite obvious who's the culprit: every single remaining rc system > manages to mount degraded btrfs without problems. They just don't try to > outsmart the kernel. Yes. They are stupid enough to fail miserably with any more

Re: degraded permanent mount option

On Sat, Jan 27, 2018 at 6:26 AM, Adam Borowski wrote: > You're assuming that btrfs somehow knows this itself. Unlike the bogus > assumption systemd does that by counting devices you can know whether a > degraded or non-degraded mount is possible, it is in general not

Re: degraded permanent mount option

On Sat, Jan 27, 2018 at 4:06 AM, Tomasz Pala wrote: > As for the regular by-UUID mounts: these links are created by udev WHEN > underlying devices appear. Does btrfs volume appear? No. If I boot with rd.break=pre-mount I can absolutely mount a Btrfs multiple volume that has a

Re: degraded permanent mount option

On Sat, Jan 27, 2018 at 03:36:48PM +0100, Goffredo Baroncelli wrote: > I think that the real problem relies that the mounting a btrfs filesystem > cannot be a responsibility of systemd (or whichever rc-system). > Unfortunately in the past it was thought that it would be sufficient to > assemble a

Re: degraded permanent mount option

Adam Borowski posted on Sat, 27 Jan 2018 14:26:41 +0100 as excerpted: > On Sat, Jan 27, 2018 at 12:06:19PM +0100, Tomasz Pala wrote: >> On Sat, Jan 27, 2018 at 13:26:13 +0300, Andrei Borzenkov wrote: >> >> >> I just tested to boot with a single drive (raid1 degraded), even >> >> with degraded

Re: degraded permanent mount option

On 01/27/2018 02:26 PM, Adam Borowski wrote: > On Sat, Jan 27, 2018 at 12:06:19PM +0100, Tomasz Pala wrote: >> On Sat, Jan 27, 2018 at 13:26:13 +0300, Andrei Borzenkov wrote: >> I just tested to boot with a single drive (raid1 degraded), even with degraded option in fstab and grub,

Re: degraded permanent mount option

On Sat, Jan 27, 2018 at 12:06:19PM +0100, Tomasz Pala wrote: > On Sat, Jan 27, 2018 at 13:26:13 +0300, Andrei Borzenkov wrote: > > >> 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

Re: degraded permanent mount option

On Sat, Jan 27, 2018 at 13:26:13 +0300, Andrei Borzenkov wrote: >> 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

Re: degraded permanent mount option

27.01.2018 13:08, Christophe Yayon пишет: > 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 ? No. It is finger

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

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 --

Re: degraded permanent mount option

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

Re: degraded permanent mount option

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 >

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 wrote: > >> On Fri, Jan 26, 2018 at 7:02 AM, Christophe Yayon

Re: degraded permanent mount option

On Fri, Jan 26, 2018 at 7:02 AM, Christophe Yayon 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

Re: degraded permanent mount option

On 2018-01-26 09:47, Christophe Yayon wrote: 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

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

Re: degraded permanent mount option

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

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,