On Fri, Nov 28, 2014 at 11:55:07PM -0800, Robert White wrote:
On 11/28/2014 08:59 PM, Zygo Blaxell wrote:
On Fri, Nov 28, 2014 at 06:05:48PM +0100, Goffredo Baroncelli wrote:
On 11/27/2014 05:15 AM, Zygo Blaxell wrote:
This is a weakness of the current udev and asynchronous device hotplug
On 11/28/2014 11:35 PM, Goffredo Baroncelli wrote:
I agree with you; but I have to find a default so during the boot
a system can start even if snapshots are present.
No, you really _don't_ need to find such a default.
Better a system that doesn't boot than one that boots based on a guess.
On 11/28/2014 11:29 PM, Duncan wrote:
Since I can't/won't run pretty much anything proprietary, there's little
chance of it being taken as anything but Linux, here. (Tho I actually
use (c)gdisk for partitioning here and it appears to use a different GUID.
(0700 in its short form which AFAIK is
Robert White posted on Sat, 29 Nov 2014 00:20:11 -0800 as excerpted:
On 11/28/2014 11:29 PM, Duncan wrote:
(Tho I actually use (c)gdisk for partitioning here and it appears to
use a different GUID. (0700 in its short form which AFAIK is gdisk
specific, for MS basic data, while it uses 8300
On 11/29/2014 01:41 AM, Duncan wrote:
Robert White posted on Sat, 29 Nov 2014 00:20:11 -0800 as excerpted:
l Display a summary of partition types. GPT uses a GUID to
identify partition types for particular OSes and purposes. For
ease of data entry, gdisk compresses these
To those reading along who don't already know. My explanation below is
factually inadequate or wrong in various places...
The type codes as presented in the various EFI/GUID disk partitioning
tools as 0700, 8200, 8300, EF02, and so on are never written to disk as
such. They are short-hand
On Sat, Nov 29, 2014 at 1:20 AM, Robert White rwh...@pobox.com wrote:
On 11/28/2014 11:29 PM, Duncan wrote:
Since I can't/won't run pretty much anything proprietary, there's little
chance of it being taken as anything but Linux, here. (Tho I actually
use (c)gdisk for partitioning here and it
Robert White posted on Sat, 29 Nov 2014 08:50:57 -0800 as excerpted:
To those reading along who don't already know. My explanation below is
factually inadequate or wrong in various places...
The type codes as presented in the various EFI/GUID disk partitioning
tools as 0700, 8200, 8300,
On 11/27/2014 05:15 AM, Zygo Blaxell wrote:
On Wed, Nov 26, 2014 at 06:19:05PM +0100, Goffredo Baroncelli wrote:
On 11/25/2014 11:21 PM, Zygo Blaxell wrote:
However I still doesn't understood why you want btrfs-w/multiple disk
over LVM ?
I want to split a few disks into partitions, but I
On 11/28/2014 09:05 AM, Goffredo Baroncelli wrote:
For the disk autodetection, I still convinced that it is a sane default
to skip the lvm-snapshot
No... please don't...
Maybe offer an option to select between snapshots or no-snapshots but in
much the same way there is no _functional_
On Fri, Nov 28, 2014 at 06:05:48PM +0100, Goffredo Baroncelli wrote:
On 11/27/2014 05:15 AM, Zygo Blaxell wrote:
This is a weakness of the current udev and asynchronous device hotplug
concept: there is no notion of bus enumeration in progress, so we can be
trying to assemble multi-device
Chris Murphy posted on Fri, 28 Nov 2014 00:10:40 -0700 as excerpted:
On Thu, Nov 27, 2014 at 2:08 AM, Duncan 1i5t5.dun...@cox.net wrote:
So, umm... kinda late now, but read that copy as if it had a footnote
attached, saying Yes, I know it's not actual copy, it's two views of
the same thing
On 11/29/2014 02:25 AM, Robert White wrote:
On 11/28/2014 09:05 AM, Goffredo Baroncelli wrote:
For the disk autodetection, I still convinced that it is a sane
default to skip the lvm-snapshot
No... please don't...
Maybe offer an option to select between snapshots or no-snapshots but
in
2014-11-29 2:25 GMT+01:00 Robert White rwh...@pobox.com:
On 11/28/2014 09:05 AM, Goffredo Baroncelli wrote:
For the disk autodetection, I still convinced that it is a sane default
to skip the lvm-snapshot
No... please don't...
Maybe offer an option to select between snapshots or
On 11/28/2014 08:59 PM, Zygo Blaxell wrote:
On Fri, Nov 28, 2014 at 06:05:48PM +0100, Goffredo Baroncelli wrote:
On 11/27/2014 05:15 AM, Zygo Blaxell wrote:
This is a weakness of the current udev and asynchronous device hotplug
concept: there is no notion of bus enumeration in progress, so we
Robert White posted on Wed, 26 Nov 2014 14:08:14 -0800 as excerpted:
On 11/25/2014 07:22 PM, Duncan wrote:
From my perspective, however, btrfs is simply incompatible with lvm
snapshots, because the basic assumptions are incompatible. Btrfs
assumes UUIDs will be exactly what they say on the
On Thu, Nov 27, 2014 at 2:08 AM, Duncan 1i5t5.dun...@cox.net wrote:
So, umm... kinda late now, but read that copy as if it had a footnote
attached, saying Yes, I know it's not actual copy, it's two views of the
same thing using COW, but my point is, from the btrfs perspective it's a
copy, the
On 11/25/2014 11:21 PM, Zygo Blaxell wrote:
However I still doesn't understood why you want btrfs-w/multiple disk over
LVM ?
I want to split a few disks into partitions, but I want to create,
move, and resize the partitions from time to time. Only LVM can do
that without taking the
On 11/25/2014 07:22 PM, Duncan wrote:
From my perspective, however, btrfs is simply incompatible with lvm
snapshots, because the basic assumptions are incompatible. Btrfs assumes
UUIDs will be exactly what they say on the label, /unique/, while lvm's
snapshot feature directly breaks that
On Wed, Nov 26, 2014 at 06:19:05PM +0100, Goffredo Baroncelli wrote:
On 11/25/2014 11:21 PM, Zygo Blaxell wrote:
However I still doesn't understood why you want btrfs-w/multiple disk
over LVM ?
I want to split a few disks into partitions, but I want to create,
move, and resize the
On 11/23/2014 01:19 AM, Zygo Blaxell wrote:
[...]
md-raid works as long as you specify the devices, and because it's always
the lowest layer it can ignore LVs (snapshot or otherwise). It's also
not a particularly common use case, while making an LV snapshot of a
filesystem is a typical use
On Tue, Nov 25, 2014 at 05:34:15PM +0100, Goffredo Baroncelli wrote:
On 11/23/2014 01:19 AM, Zygo Blaxell wrote:
[...]
md-raid works as long as you specify the devices, and because it's always
the lowest layer it can ignore LVs (snapshot or otherwise). It's also
not a particularly common
On 11/25/2014 09:29 PM, Zygo Blaxell wrote:
On Tue, Nov 25, 2014 at 05:34:15PM +0100, Goffredo Baroncelli wrote:
On 11/23/2014 01:19 AM, Zygo Blaxell wrote:
[...]
md-raid works as long as you specify the devices, and because it's always
the lowest layer it can ignore LVs (snapshot or
On Tue, Nov 25, 2014 at 10:59:53PM +0100, Goffredo Baroncelli wrote:
On 11/25/2014 09:29 PM, Zygo Blaxell wrote:
On Tue, Nov 25, 2014 at 05:34:15PM +0100, Goffredo Baroncelli wrote:
On 11/23/2014 01:19 AM, Zygo Blaxell wrote:
[...]
md-raid works as long as you specify the devices, and
What happens when all btrfs LVs are unmounted, and you lvchange -an
the LVs (the pair) you do not want mounted; and then btrfs dev scan;
and then mount one of the devices? It should only find the matching LV
because the others are deactivated. I know this isn't ideal, but it's
better than
Goffredo Baroncelli posted on Tue, 25 Nov 2014 22:59:53 +0100 as
excerpted:
However I still doesn't understood why you want btrfs-w/multiple disk
over LVM ?
While I'm not an LVM person here, and he already replied with essentially
the same point, I think it's worth repeating...
Btrfs'
On Tue, Nov 25, 2014 at 7:11 PM, Zygo Blaxell zblax...@furryterror.org wrote:
On Tue, Nov 25, 2014 at 03:46:32PM -0700, Chris Murphy wrote:
What happens when all btrfs LVs are unmounted, and you lvchange -an
the LVs (the pair) you do not want mounted; and then btrfs dev scan;
and then mount
On 11/21/2014 05:28 AM, Zygo Blaxell wrote:
e.g. if an ext4 filesystem explodes, I can:
1. make a LVM snapshot of the broken filesystem
2. run e2fsck on the snapshot
3. mount and repair the snapshot, e.g. rsync any missing files
from backups, salvage anything
I don't know how to fix this but I've convinced myself there's at
least a small problem. And not just with LVM snapshots as in the
originating thread.
- Via seed device method of creating a Btrfs volume, the resulting
volume gets a new UUID. The volume UUID from the seed device doesn't
pass
On 11/22/2014 02:50 PM, Robert White wrote:
Take a couple snapshots of a subvolume, and then
send those subvolumes to another file system with send/receive, and then
do btrfs subvolume list -u -q on the two filesystems and tell me that
mess makes sense. Or try to recreate a subvolume from its
On Sat, Nov 22, 2014 at 06:34:38PM +0100, Goffredo Baroncelli wrote:
On 11/21/2014 05:28 AM, Zygo Blaxell wrote:
e.g. if an ext4 filesystem explodes, I can:
1. make a LVM snapshot of the broken filesystem
2. run e2fsck on the snapshot
3. mount and repair the
On 11/20/2014 10:22 PM, Duncan wrote:
But while other filesystems might allow un-UUIDs (heh, UUUIDs or U3IDs
=:^), because they're no longer unique, requiring them to be unique just
as the label says cannot be considered a bug. It's simply stricter
enforcement of the rules, which are, after
Robert White posted on Fri, 21 Nov 2014 03:35:05 -0800 as excerpted:
On 11/20/2014 10:22 PM, Duncan wrote:
But while other filesystems might allow un-UUIDs (heh, UUUIDs or U3IDs
=:^), because they're no longer unique, requiring them to be unique
just as the label says cannot be considered a
On Fri, Nov 21, 2014 at 06:22:57AM +, Duncan wrote:
After all, an LVM block-level snapshot takes the same space as a file
containing the same raw data, and if there's room for the data in an LVM
snapshot, given a different layout, there's room for exactly the same
amount of data as a
On Thu, Nov 20, 2014 at 11:22 PM, Duncan 1i5t5.dun...@cox.net wrote:
When I have such a filesystem level problem, I simply dd from the backing
device to some other location, generally to a file that's on a different
filesystem (preferrably non-btrfs, I use reiserfs as I've found it very
Chris Murphy posted on Fri, 21 Nov 2014 11:23:45 -0700 as excerpted:
On Thu, Nov 20, 2014 at 11:22 PM, Duncan 1i5t5.dun...@cox.net wrote:
When I have such a filesystem level problem, I simply dd from the
backing device to some other location, generally to a file that's on a
different
Zygo Blaxell posted on Fri, 21 Nov 2014 12:56:23 -0500 as excerpted:
It's not a bug as long as I can completely control which devices are
searched for UUIDs, and the system behaves sanely when multiple UUIDs
are found through automatic discovery; otherwise, it's not only a bug,
it's a DoS
Duncan posted on Fri, 21 Nov 2014 22:49:06 + as excerpted:
Chris Murphy posted...
That's not true for thin volume snapshots. They take up next to no
space upon creation, they don't need space reserved in advance.
Thus the mention of compression if necessary. Thin-volume snapshots are
Duncan posted on Fri, 21 Nov 2014 23:41:49 + as excerpted:
Duncan posted on Fri, 21 Nov 2014 22:49:06 + as excerpted:
Chris Murphy posted...
That's not true for thin volume snapshots. They take up next to no
space upon creation, they don't need space reserved in advance.
Thus
On Mon, Nov 17, 2014 at 08:04:05PM +0100, Goffredo Baroncelli wrote:
On 2014-11-17 07:59, Brendan Hide wrote:
That leaves two aspects of this issue which I view as two separate bugs:
a) Btrfs cannot gracefully handle separate filesystems that have the same
UUID. At all.
b) Grub
On Wed, Nov 19, 2014 at 10:20:17AM -0500, Phillip Susi wrote:
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 11/18/2014 9:54 PM, Chris Murphy wrote:
Why is it silly? Btrfs on a thin volume has practical use case
aside from just being thinly provisioned, its snapshots are block
device
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 11/18/2014 9:54 PM, Chris Murphy wrote:
Why is it silly? Btrfs on a thin volume has practical use case
aside from just being thinly provisioned, its snapshots are block
device based, not merely that of an fs tree.
Umm... because one of the big
On Wed, Nov 19, 2014 at 8:20 AM, Phillip Susi ps...@ubuntu.com wrote:
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 11/18/2014 9:54 PM, Chris Murphy wrote:
Why is it silly? Btrfs on a thin volume has practical use case
aside from just being thinly provisioned, its snapshots are block
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 11/19/2014 1:33 PM, Chris Murphy wrote:
Thin volumes are more efficient. And the user creating them doesn't
have to mess around with locating physical devices or possibly
partitioning them. Plus in enterprise environments with lots of
storage
Chris Murphy posted on Mon, 17 Nov 2014 23:21:57 -0700 as excerpted:
I think we’re well past the expiration date on grub.cfg, a line should
be drawn in the sand to deprecate routine use of os-prober +
grub-mkconfig,
and move to drop-in scripts by whatever the distro presumes will be
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 11/18/2014 1:16 AM, Chris Murphy wrote:
If fstab specifies rootfs as UUID, and there are two volumes with
the same UUID, it’s now ambiguous which one at boot time is the
intended rootfs. It’s no different than the days of /dev/sdXY where
X
On Nov 18, 2014, at 8:42 AM, Phillip Susi ps...@ubuntu.com wrote:
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 11/18/2014 1:16 AM, Chris Murphy wrote:
If fstab specifies rootfs as UUID, and there are two volumes with
the same UUID, it’s now ambiguous which one at boot time is the
On 2014-11-18 07:21, Chris Murphy wrote:
Ergo just because I’ve snapshot my root does not mean grub-mkconfig
should be creating boot entries for it.
I find this an useful feature: a snapshot of / is done to rollback
some changes, so why don't let grub to start (the kernel) from ?
Anyway I find
2014-11-18 16:42 GMT+01:00 Phillip Susi ps...@ubuntu.com:
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 11/18/2014 1:16 AM, Chris Murphy wrote:
If fstab specifies rootfs as UUID, and there are two volumes with
the same UUID, it’s now ambiguous which one at boot time is the
intended
On 11/18/2014 07:42 AM, Phillip Susi wrote:
On 11/18/2014 1:16 AM, Chris Murphy wrote:
(stuff about UUIDs and LVM snapshots).
(suggestion to use LVM paths instead).
This is also an XFS+LVM+LVM_Snapshot problem going back to at least
2009. It's inherent to the block-device-level snapshot
On Nov 18, 2014, at 1:17 PM, Phillip Susi ps...@ubuntu.com wrote:
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 11/18/2014 2:17 PM, Chris Murphy wrote:
What if you have a Btrfs raid1 volume using two LV’s and then
snapshot both LV’s?
That's even more silly than a single lvm
Robert White posted on Tue, 18 Nov 2014 17:29:12 -0800 as excerpted:
On 11/18/2014 07:42 AM, Phillip Susi wrote:
On 11/18/2014 1:16 AM, Chris Murphy wrote:
(stuff about UUIDs and LVM snapshots).
(suggestion to use LVM paths instead).
This is also an XFS+LVM+LVM_Snapshot problem going
2014-11-17 7:59 GMT+01:00 Brendan Hide bren...@swiftspirit.co.za:
Grub is already a little smart here - it avoids snapshots. But in this case
it is relying on the UUID and only finding it in the snapshot. So possibly
this is a bug in grub affecting the bug reporter specifically - but perhaps
On 2014/11/17 09:35, Daniel Dressler top-posted:
If a UUID is not unique enough how will adding a second UUID or
unique drive identifier help?
A UUID is *supposed* to be unique by design. Isolated, the design is
adequate.
But the bigger picture clearly shows the design is naive. And broken.
On 2014-11-17 07:59, Brendan Hide wrote:
That leaves two aspects of this issue which I view as two separate bugs:
a) Btrfs cannot gracefully handle separate filesystems that have the same
UUID. At all.
b) Grub appears to pick the wrong filesystem when presented with two
filesystems with
2014-11-17 20:04 GMT+01:00 Goffredo Baroncelli kreij...@inwind.it:
Regarding b)
I am bit confused: if I understood correctly, the root filesystem was
picked from a LVM-snapshot, so grub-probe *correctly* reported that
the root device is the snapshot.
This is not what happens. The system
On 2014-11-17 20:45, MegaBrutal wrote:
* I know I shouldn't make an LVM-snapshot of a mounted file system,
but this is not the point.
This should be supported for the filesystem which support the freezing
See
http://stackoverflow.com/questions/1940093/lvm-snapshot-of-mounted-filesystem
--
On Nov 17, 2014, at 12:45 PM, MegaBrutal megabru...@gmail.com wrote:
2014-11-17 20:04 GMT+01:00 Goffredo Baroncelli kreij...@inwind.it:
Regarding b)
I am bit confused: if I understood correctly, the root filesystem was
picked from a LVM-snapshot, so grub-probe *correctly* reported that
On Nov 16, 2014, at 11:59 PM, Brendan Hide bren...@swiftspirit.co.za wrote:
cc'd bug-g...@gnu.org for FYI
On 2014/11/17 03:42, Duncan wrote:
MegaBrutal posted on Sun, 16 Nov 2014 22:35:26 +0100 as excerpted:
Hello guys,
I think you'll like this...
Hello guys,
I think you'll like this...
https://bugs.launchpad.net/ubuntu/+source/grub2/+bug/1391429
MegaBrutal
--
To unsubscribe from this list: send the line unsubscribe linux-btrfs in
the body of a message to majord...@vger.kernel.org
More majordomo info at
MegaBrutal posted on Sun, 16 Nov 2014 22:35:26 +0100 as excerpted:
Hello guys,
I think you'll like this...
https://bugs.launchpad.net/ubuntu/+source/grub2/+bug/1391429
UUID is an initialism for Universally Unique IDentifier.[1]
If the UUID isn't unique, by definition, then, it can't be a
cc'd bug-g...@gnu.org for FYI
On 2014/11/17 03:42, Duncan wrote:
MegaBrutal posted on Sun, 16 Nov 2014 22:35:26 +0100 as excerpted:
Hello guys,
I think you'll like this...
https://bugs.launchpad.net/ubuntu/+source/grub2/+bug/1391429
UUID is an initialism for Universally Unique
If a UUID is not unique enough how will adding a second UUID or
unique drive identifier help?
A UUID only serves any purpose when it is unique. Thus duplicate UUIDs
are themselves a failure state.
The solution should be to make it harder to get into this failure
state. Not to make all programs
63 matches
Mail list logo
