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 that
it would be one possi
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 some very basic state chan
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 as well), and even peo
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 don't always use
> every to
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
> ht
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 userspace with this info, and
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
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 to
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 without telling the kern
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
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 d
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 reporting the FS ready b
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 doesn't
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
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 all the devices, IIUC,
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 in degraded mode?
according to documentation,
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
>> rootflags=degraded, it should be possible to 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 path /dev/mapper/VG-3
>>>
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 possible. Maybe just deleting 6
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?
>>> according to documentation, "btrfs device ready" (wh
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 devices in cache for mount
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.
>>
>> https://lists.freedesktop.org/archives/systemd-devel/2016-July/037031.html
>>
>
> Befo
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:
> >>>
> >>> I started a systemd-devel@ thread sinc
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 05:51, Andrei Borzenkov wrote:
On Tue, Jul 5
Отправлено с 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:
On Tue, Jul 5, 2016 at 11:10 PM, C
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 that's where most udev stuff
gets talked about.
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
>>> gets talked about.
>>>
>>>
>>> https://lists.fr
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
Before discussing how to imple
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 systemd, we need to decide
wha
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 majord...@vge
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 device, e.g.
>> root=/dev/vda2, and then adding degr
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
> doesn't work either on CentOS
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 (or
33 matches
Mail list logo
