Re: 64-btrfs.rules and degraded boot

On 2016-07-11 17:07, Chris Murphy wrote: On Fri, Jul 8, 2016 at 6:24 AM, Austin S. Hemmelgarn wrote: To clarify, I'm not trying to argue against adding support, I'm arguing against it being mandatory. By "D-Bus support" I did not mean to indicate mandating it, just

Re: 64-btrfs.rules and degraded boot

On Fri, Jul 8, 2016 at 6:24 AM, Austin S. Hemmelgarn wrote: > To clarify, I'm not trying to argue against adding support, I'm arguing > against it being mandatory. By "D-Bus support" I did not mean to indicate mandating it, just that it would be one possible way to get

Re: 64-btrfs.rules and degraded boot

On 2016-07-07 16:20, Chris Murphy wrote: On Thu, Jul 7, 2016 at 1:59 PM, Austin S. Hemmelgarn wrote: D-Bus support needs to be optional, period. Not everybody uses D-Bus (I have dozens of systems that get by just fine without it, and know hundreds of other people who do

Re: 64-btrfs.rules and degraded boot

On Thu, Jul 7, 2016 at 1:59 PM, Austin S. Hemmelgarn wrote: > D-Bus support needs to be optional, period. Not everybody uses D-Bus (I > have dozens of systems that get by just fine without it, and know hundreds > of other people who do as well), and even people who do

Re: 64-btrfs.rules and degraded boot

On 2016-07-07 20:58, Chris Murphy wrote: > I get all kinds of damn strange behaviors in GNOME > with Btrfs multiple device volumes: volume names appearing twice in > the UI, unmounting one causes umount errors with the other. > https://fedoraproject.org/wiki/Changes/Replace_UDisks2_by_Storaged >

Re: 64-btrfs.rules and degraded boot

On 2016-07-07 14:58, Chris Murphy wrote: On Thu, Jul 7, 2016 at 12:23 PM, Austin S. Hemmelgarn wrote: Here's how I would picture the ideal situation: * A device is processed by udev. It detects that it's part of a BTRFS array, updates blkid and whatever else in

Re: 64-btrfs.rules and degraded boot

On 2016-07-07 20:23, Austin S. Hemmelgarn wrote: [...] > FWIW, I've pretty much always been of the opinion that the device discovery > belongs in a mount helper. The auto-discovery from udev (and more > importantly, how the kernel handles being told about a device) is much of the > reason that

Re: 64-btrfs.rules and degraded boot

More Btrfs udev issues, they involve making btrfs multiple device volumes via 'btrfs dev add' which then causes problems at boot time. https://bugzilla.opensuse.org/show_bug.cgi?id=912170 https://bugzilla.suse.com/show_bug.cgi?id=984516 The last part is amusing in that the proposed fix is going

Re: 64-btrfs.rules and degraded boot

On Thu, Jul 7, 2016 at 12:23 PM, Austin S. Hemmelgarn wrote: > > Here's how I would picture the ideal situation: > * A device is processed by udev. It detects that it's part of a BTRFS > array, updates blkid and whatever else in userspace with this info, and then > stops

Re: 64-btrfs.rules and degraded boot

On 2016-07-07 12:52, Goffredo Baroncelli wrote: On 2016-07-06 14:48, Austin S. Hemmelgarn wrote: On 2016-07-06 08:39, Andrei Borzenkov wrote: [] To be entirely honest, if it were me, I'd want systemd to fsck off. If the kernel mount(2) call succeeds, then the filesystem was ready enough

Re: 64-btrfs.rules and degraded boot

On 2016-07-06 20:57, Chris Murphy wrote: [...] > > Seems like we need more granularity by btrfs ioctl for device ready, > e.g. some way to indicate: > > 0 all devices ready > 1 devices not ready (don't even try to mount) > 2 minimum devices ready (degraded mount possible) > > > Btrfs multiple

Re: 64-btrfs.rules and degraded boot

On 2016-07-06 22:00, Chris Murphy wrote: > On Wed, Jul 6, 2016 at 1:17 PM, Austin S. Hemmelgarn > wrote: > >> In bash or most other POSIX compliant shells, you can run this: >> echo $? >> to get the return code of the previous command. >> >> In your case though, it may be

Re: 64-btrfs.rules and degraded boot

On 2016-07-06 14:48, Austin S. Hemmelgarn wrote: > On 2016-07-06 08:39, Andrei Borzenkov wrote: [] > > To be entirely honest, if it were me, I'd want systemd to > fsck off. If the kernel mount(2) call succeeds, then the > filesystem was ready enough to mount, and if it

Re: 64-btrfs.rules and degraded boot

On 2016-07-05 20:53, Chris Murphy wrote: > I am kinda confused about this "btrfs ready $devnode" portion. Isn't > it "btrfs device ready $devnode" if this is based on user space tools? systemd, implemented this as internal command -- gpg @keyserver.linux.it: Goffredo Baroncelli Key fingerprint

Re: 64-btrfs.rules and degraded boot

On Wed, Jul 6, 2016 at 1:17 PM, Austin S. Hemmelgarn wrote: > In bash or most other POSIX compliant shells, you can run this: > echo $? > to get the return code of the previous command. > > In your case though, it may be reporting the FS ready because it had already > seen

Re: 64-btrfs.rules and degraded boot

On 2016-07-06 14:23, Chris Murphy wrote: On Wed, Jul 6, 2016 at 12:04 PM, Austin S. Hemmelgarn wrote: On 2016-07-06 13:19, Chris Murphy wrote: On Wed, Jul 6, 2016 at 3:51 AM, Andrei Borzenkov wrote: 3) can we query btrfs whether it is mountable

Re: 64-btrfs.rules and degraded boot

On Wed, Jul 6, 2016 at 12:24 PM, Andrei Borzenkov wrote: > On Wed, Jul 6, 2016 at 8:19 PM, Chris Murphy wrote: >> >> I'm mainly concerned with rootfs. And I'm mainly concerned with a very >> simple 2 disk raid1. With a simple user opt in using >>

Re: 64-btrfs.rules and degraded boot

On Wed, Jul 6, 2016 at 9:23 PM, Chris Murphy wrote: >>> [root@f24s ~]# btrfs fi show >>> warning, device 2 is missing >>> Label: none uuid: 96240fd9-ea76-47e7-8cf4-05d3570ccfd7 >>> Total devices 3 FS bytes used 2.26GiB >>> devid3 size 50.00GiB used 3.01GiB

Re: 64-btrfs.rules and degraded boot

On Wed, Jul 6, 2016 at 8:19 PM, Chris Murphy wrote: > > I'm mainly concerned with rootfs. And I'm mainly concerned with a very > simple 2 disk raid1. With a simple user opt in using > rootflags=degraded, it should be possible to boot the system. Right > now it's not

Re: 64-btrfs.rules and degraded boot

On Wed, Jul 6, 2016 at 12:04 PM, Austin S. Hemmelgarn wrote: > On 2016-07-06 13:19, Chris Murphy wrote: >> >> On Wed, Jul 6, 2016 at 3:51 AM, Andrei Borzenkov >> wrote: >>> >>> 3) can we query btrfs whether it is mountable in degraded mode? >>>

Re: 64-btrfs.rules and degraded boot

On 2016-07-06 13:19, Chris Murphy wrote: On Wed, Jul 6, 2016 at 3:51 AM, Andrei Borzenkov wrote: 3) can we query btrfs whether it is mountable in degraded mode? according to documentation, "btrfs device ready" (which udev builtin follows) checks "if it has ALL of it’s

Re: 64-btrfs.rules and degraded boot

On Wed, Jul 6, 2016 at 3:51 AM, Andrei Borzenkov wrote: > On Tue, Jul 5, 2016 at 11:10 PM, Chris Murphy wrote: >> I started a systemd-devel@ thread since that's where most udev stuff >> gets talked about. >> >>

Re: 64-btrfs.rules and degraded boot

On Wed, Jul 06, 2016 at 02:55:37PM +0300, Andrei Borzenkov wrote: > On Wed, Jul 6, 2016 at 2:45 PM, Austin S. Hemmelgarn > wrote: > > On 2016-07-06 05:51, Andrei Borzenkov wrote: > >> > >> On Tue, Jul 5, 2016 at 11:10 PM, Chris Murphy > >> wrote: >

Re: 64-btrfs.rules and degraded boot

On 2016-07-06 08:39, Andrei Borzenkov wrote: Отправлено с iPhone 6 июля 2016 г., в 15:14, Austin S. Hemmelgarn написал(а): On 2016-07-06 07:55, Andrei Borzenkov wrote: On Wed, Jul 6, 2016 at 2:45 PM, Austin S. Hemmelgarn wrote: On 2016-07-06

Re: 64-btrfs.rules and degraded boot

Отправлено с iPhone > 6 июля 2016 г., в 15:14, Austin S. Hemmelgarn > написал(а): > >> On 2016-07-06 07:55, Andrei Borzenkov wrote: >> On Wed, Jul 6, 2016 at 2:45 PM, Austin S. Hemmelgarn >> wrote: >>> On 2016-07-06 05:51, Andrei Borzenkov wrote:

Re: 64-btrfs.rules and degraded boot

On 2016-07-06 07:55, Andrei Borzenkov wrote: On Wed, Jul 6, 2016 at 2:45 PM, Austin S. Hemmelgarn wrote: On 2016-07-06 05:51, Andrei Borzenkov wrote: On Tue, Jul 5, 2016 at 11:10 PM, Chris Murphy wrote: I started a systemd-devel@ thread since

Re: 64-btrfs.rules and degraded boot

On Wed, Jul 6, 2016 at 2:45 PM, Austin S. Hemmelgarn wrote: > On 2016-07-06 05:51, Andrei Borzenkov wrote: >> >> On Tue, Jul 5, 2016 at 11:10 PM, Chris Murphy >> wrote: >>> >>> I started a systemd-devel@ thread since that's where most udev stuff >>>

Re: 64-btrfs.rules and degraded boot

On 2016-07-06 05:51, Andrei Borzenkov wrote: On Tue, Jul 5, 2016 at 11:10 PM, Chris Murphy wrote: I started a systemd-devel@ thread since that's where most udev stuff gets talked about. https://lists.freedesktop.org/archives/systemd-devel/2016-July/037031.html

Re: 64-btrfs.rules and degraded boot

On Tue, Jul 5, 2016 at 11:10 PM, Chris Murphy wrote: > I started a systemd-devel@ thread since that's where most udev stuff > gets talked about. > > https://lists.freedesktop.org/archives/systemd-devel/2016-July/037031.html > Before discussing how to implement it in

Re: 64-btrfs.rules and degraded boot

I started a systemd-devel@ thread since that's where most udev stuff gets talked about. https://lists.freedesktop.org/archives/systemd-devel/2016-July/037031.html -- Chris Murphy -- To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in the body of a message to

Re: 64-btrfs.rules and degraded boot

On Tue, Jul 5, 2016 at 1:27 PM, Kai Krakow wrote: > Am Tue, 5 Jul 2016 12:53:02 -0600 > schrieb Chris Murphy : > >> For some reason I thought it was possible to do degraded Btrfs boots >> by removing root=UUID= in favor of a remaining good block

Re: 64-btrfs.rules and degraded boot

Am Tue, 5 Jul 2016 12:53:02 -0600 schrieb Chris Murphy : > For some reason I thought it was possible to do degraded Btrfs boots > by removing root=UUID= in favor of a remaining good block device, e.g. > root=/dev/vda2, and then adding degraded to rootflags. But this >

64-btrfs.rules and degraded boot

For some reason I thought it was possible to do degraded Btrfs boots by removing root=UUID= in favor of a remaining good block device, e.g. root=/dev/vda2, and then adding degraded to rootflags. But this doesn't work either on CentOS 7.2 or Fedora Rawhide. What happens is systemd waits for vda2