-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 12/9/2014 10:10 PM, Anand Jain wrote:
In the test case provided earlier who is triggering the scan ?
grub-probe ?
The scan is initiated by udev. grub-probe only comes into it because
it is looking to /proc/mounts to find out what device is
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 12/8/2014 5:25 PM, Konstantin wrote:
Phillip Susi schrieb am 08.12.2014 um 15:59:
The bios does not know or care about partitions. All you need is
a
That's only true for older BIOSs. With current EFI boards they not
only care but some also
On 08/12/2014 22:59, Phillip Susi wrote:
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 12/7/2014 7:32 PM, Konstantin wrote:
I'm guessing you are using metadata format 0.9 or 1.0, which put
the metadata at the end of the drive and the filesystem still
starts in sector zero. 1.2 is now the
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 12/7/2014 7:32 PM, Konstantin wrote:
I'm guessing you are using metadata format 0.9 or 1.0, which put
the metadata at the end of the drive and the filesystem still
starts in sector zero. 1.2 is now the default and would not have
this problem
On 12/07/2014 04:32 PM, Konstantin wrote:
I know this and I'm using 0.9 on purpose. I need to boot from these
disks so I can't use 1.2 format as the BIOS wouldn't recognize the
partitions. Having an additional non-RAID disk for booting introduces a
single point of failure which contrary to the
Phillip Susi schrieb am 08.12.2014 um 15:59:
On 12/7/2014 7:32 PM, Konstantin wrote:
I'm guessing you are using metadata format 0.9 or 1.0, which put
the metadata at the end of the drive and the filesystem still
starts in sector zero. 1.2 is now the default and would not have
this
Robert White schrieb am 08.12.2014 um 18:20:
On 12/07/2014 04:32 PM, Konstantin wrote:
I know this and I'm using 0.9 on purpose. I need to boot from these
disks so I can't use 1.2 format as the BIOS wouldn't recognize the
partitions. Having an additional non-RAID disk for booting introduces a
On 12/08/2014 02:38 PM, Konstantin wrote:
For more important systems there are high availability
solutions which alleviate many of the problems you mention of but that's
not the point here when speaking about the major bug in BTRFS which can
make your system crash.
I think you missed the part
Anand Jain wrote on 02.12.2014 at 12:54:
On 02/12/2014 19:14, Goffredo Baroncelli wrote:
I further investigate this issue.
MegaBrutal, reported the following issue: doing a lvm snapshot of the
device of a
mounted btrfs fs, the new snapshot device name replaces the name of
the original
Phillip Susi wrote on 02.12.2014 at 20:19:
On 12/1/2014 4:45 PM, Konstantin wrote:
The bug appears also when using mdadm RAID1 - when one of the
drives is detached from the array then the OS discovers it and
after a while (not directly, it takes several minutes) it appears
under
2014-12-04 6:15 GMT+01:00 Duncan 1i5t5.dun...@cox.net:
Which is why I'm running an initramfs for the first time since I've
switched to btrfs raid1 mode root, as I quit with initrds back before
initramfs was an option. An initramfs appended to the kernel image beats
a separate initrd, but I'd
MegaBrutal posted on Thu, 04 Dec 2014 09:20:12 +0100 as excerpted:
Are you sure it isn't fixed? At least, it parses rootflags=subvol=@
well, which also has multiple = signs. And last time I've tried this,
and didn't cause any problems:
rootflags=device=/dev/mapper/vg-rootlv,subvol=@. Though
On 12/02/2014 08:11 PM, Phillip Susi wrote:
On 12/2/2014 7:23 AM, Austin S Hemmelgarn wrote:
Stupid thought, why don't we just add blacklisting based on device
path like LVM has for pvscan?
That isn't logic that belongs in the kernel, so that is going down the
path of yanking out the device
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512
On 12/03/2014 03:24 AM, Goffredo Baroncelli wrote:
I am thinking about that. Today the device discovery happens: a)
when a device appears, two udev rules run btrfs dev scan
device
/lib/udev/rules.d/70-btrfs.rules
Phillip Susi posted on Wed, 03 Dec 2014 22:09:29 -0500 as excerpted:
Are you sure the kernel only gains awareness of btrfs volumes when user
space runs btrfs device scan? If that is so then that means you can not
boot from a multi device btrfs root without using an initramfs. I
thought the
2014-12-02 8:50 GMT+01:00 Goffredo Baroncelli kreij...@inwind.it:
On 12/02/2014 01:15 AM, MegaBrutal wrote:
2014-12-02 0:24 GMT+01:00 Robert White rwh...@pobox.com:
On 12/01/2014 02:10 PM, MegaBrutal wrote:
Since having duplicate UUIDs on devices is not a problem for me since
I can tell them
I further investigate this issue.
MegaBrutal, reported the following issue: doing a lvm snapshot of the device of
a
mounted btrfs fs, the new snapshot device name replaces the name of the
original
device in the output of /proc/mounts. This confused tools like grub-probe which
report a wrong
On 02/12/2014 19:14, Goffredo Baroncelli wrote:
I further investigate this issue.
MegaBrutal, reported the following issue: doing a lvm snapshot of the device of
a
mounted btrfs fs, the new snapshot device name replaces the name of the original
device in the output of /proc/mounts. This
On 2014-12-02 06:54, Anand Jain wrote:
On 02/12/2014 19:14, Goffredo Baroncelli wrote:
I further investigate this issue.
MegaBrutal, reported the following issue: doing a lvm snapshot of the
device of a
mounted btrfs fs, the new snapshot device name replaces the name of
the original
device
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 12/2/2014 7:23 AM, Austin S Hemmelgarn wrote:
Stupid thought, why don't we just add blacklisting based on device
path like LVM has for pvscan?
That isn't logic that belongs in the kernel, so that is going down the
path of yanking out the device
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 12/2/2014 6:54 AM, Anand Jain wrote:
we have some fundamentally wrong stuff. My original patch tried to
fix it. But later discovered that some external entities like
systmed and boot process is using that bug as a feature and we had
to revert
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 12/1/2014 4:45 PM, Konstantin wrote:
The bug appears also when using mdadm RAID1 - when one of the
drives is detached from the array then the OS discovers it and
after a while (not directly, it takes several minutes) it appears
under
On 12/01/2014 04:56 AM, MegaBrutal wrote:
Since the other thread went off into theoretical debates about UUIDs
and their generic relation to BTRFS, their everyday use cases, and the
philosophical meaning behind uniqueness of copies and UUIDs; I'd like
to specifically ask you to only post here
MegaBrutal schrieb am 01.12.2014 um 13:56:
Hi all,
I've reported the bug I've previously posted about in BTRFS messes up
snapshot LV with origin in the Kernel Bug Tracker.
https://bugzilla.kernel.org/show_bug.cgi?id=89121
Hi MegaBrutal. If I understand your report correctly, I can give you
2014-12-01 18:27 GMT+01:00 Robert White rwh...@pobox.com:
On 12/01/2014 04:56 AM, MegaBrutal wrote:
Since the other thread went off into theoretical debates about UUIDs
and their generic relation to BTRFS, their everyday use cases, and the
philosophical meaning behind uniqueness of copies and
On 12/01/2014 02:10 PM, MegaBrutal wrote:
Since having duplicate UUIDs on devices is not a problem for me since
I can tell them apart by LVM names, the discussion is of little
relevance to my use case. Of course it's interesting and I like to
read it along, it is not about the actual problem at
2014-12-02 0:24 GMT+01:00 Robert White rwh...@pobox.com:
On 12/01/2014 02:10 PM, MegaBrutal wrote:
Since having duplicate UUIDs on devices is not a problem for me since
I can tell them apart by LVM names, the discussion is of little
relevance to my use case. Of course it's interesting and I
2014-12-01 22:45 GMT+01:00 Konstantin newsbox1...@web.de:
MegaBrutal schrieb am 01.12.2014 um 13:56:
Hi all,
I've reported the bug I've previously posted about in BTRFS messes up
snapshot LV with origin in the Kernel Bug Tracker.
https://bugzilla.kernel.org/show_bug.cgi?id=89121
Hi
On 12/02/2014 01:15 AM, MegaBrutal wrote:
2014-12-02 0:24 GMT+01:00 Robert White rwh...@pobox.com:
On 12/01/2014 02:10 PM, MegaBrutal wrote:
Since having duplicate UUIDs on devices is not a problem for me since
I can tell them apart by LVM names, the discussion is of little
relevance to my
29 matches
Mail list logo
