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,

Darlehensangebot

Schönen Tag, Sie benötigen einen echten Kredit online Ihre Rechnungen zu sichern? Startet ein neues Unternehmen? Sie benötigen einen persönlichen Kredit oder Business-Darlehen? Wir bieten ein Darlehen von € 10.000 bis € 500,000.000.00 mit 2% Zinsen pro Jahr und auch mit einem erschwinglichen

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

[PATCH] btrfs: Handle btrfs_set_extent_delalloc failure in relocate_file_extent_cluster

Signed-off-by: Nikolay Borisov Reviewed-by: Josef Bacik --- Based on off-list feadback from Josef I'm also clearing the EXTENT_BOUNDARY flag so we don't leak it. Otherwise it's okay. He said to add his Reviewed-by as long as the extent clearing bit is

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

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

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: [PATCH 11/26] libbtrfsutil: add btrfs_util_create_snapshot()

On 01/27/2018 06:45 AM, Omar Sandoval wrote: > On Sat, Jan 27, 2018 at 01:00:58PM +0800, Qu Wenruo wrote: >> >> >> On 2018年01月27日 03:46, Omar Sandoval wrote: >>> On Fri, Jan 26, 2018 at 08:31:06PM +0100, Goffredo Baroncelli wrote: On 01/26/2018 07:40 PM, Omar Sandoval wrote: > From: Omar

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: bad key ordering - repairable?

2018-01-23 14:06 GMT+01:00 Claes Fransson : > 2018-01-22 22:22 GMT+01:00 Hugo Mills : >> On Mon, Jan 22, 2018 at 10:06:58PM +0100, Claes Fransson wrote: >>> Hi! >>> >>> I really like the features of BTRFS, especially deduplication, >>> snapshotting

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: [PATCH 11/26] libbtrfsutil: add btrfs_util_create_snapshot()

On 27.01.2018 07:45, Omar Sandoval wrote: > On Sat, Jan 27, 2018 at 01:00:58PM +0800, Qu Wenruo wrote: >> >> >> On 2018年01月27日 03:46, Omar Sandoval wrote: >>> On Fri, Jan 26, 2018 at 08:31:06PM +0100, Goffredo Baroncelli wrote: On 01/26/2018 07:40 PM, Omar Sandoval wrote: > From: Omar

Re: bad key ordering - repairable?

2018-01-27 18:32 GMT+01:00 Claes Fransson : > > Duncan Wed, 24 Jan 2018 15:18:25 -0800 > > Claes Fransson posted on Wed, 24 Jan 2018 20:44:33 +0100 as excerpted: > > > So, I have now some results from the PassMark Memtest86! I let the > > default automatic tests run for

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: [PATCH 11/26] libbtrfsutil: add btrfs_util_create_snapshot()

On Sat, Jan 27, 2018 at 06:31:11PM +0200, Nikolay Borisov wrote: > > > On 27.01.2018 07:45, Omar Sandoval wrote: > > On Sat, Jan 27, 2018 at 01:00:58PM +0800, Qu Wenruo wrote: > >> > >> > >> On 2018年01月27日 03:46, Omar Sandoval wrote: > >>> On Fri, Jan 26, 2018 at 08:31:06PM +0100, Goffredo

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