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 hot
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, 830
On Sat, Nov 29, 2014 at 1:20 AM, Robert White 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 appears
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 va
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 int
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 8
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 g
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 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
2014-11-29 2:25 GMT+01:00 Robert White :
>
> 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-snapsho
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
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 sa
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-de
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_ diffe
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 partit
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
> co
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
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 res
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 unique
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 th
On Tue, Nov 25, 2014 at 8:22 PM, Duncan <1i5t5.dun...@cox.net> 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
> snapsho
On Tue, Nov 25, 2014 at 7:11 PM, Zygo Blaxell 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 one of the devices?
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' check
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 corruptio
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 devi
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 o
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
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 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 rep
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 s
On 11/22/2014 11:52 AM, Chris Murphy wrote:
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.
Yes.
You also run into this problem if you use multipath hardware but haven't
configured multipath
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 throug
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 an
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.
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 snapshot
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
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
>> diff
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
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
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 consider
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 all,
Zygo Blaxell posted on Thu, 20 Nov 2014 23:28:14 -0500 as excerpted:
> 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
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
>
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) G
-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
> storag
On Wed, Nov 19, 2014 at 8:20 AM, 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 bas
-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 bi
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 probl
On Nov 18, 2014, at 1:17 PM, Phillip Susi 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 snapshot under
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 ph
2014-11-18 16:42 GMT+01:00 Phillip Susi :
>
> -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.
-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 snapshot under btrfs. Just
don't do it.
-BEGIN PGP SIGNATURE-
Version:
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 fin
On Nov 18, 2014, at 8:42 AM, Phillip Susi 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
>> intended r
-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 w
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
> resp
On Nov 16, 2014, at 11:59 PM, Brendan Hide 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...
>>> https://bugs.launchpad.net/ubuntu/+source/g
On Nov 17, 2014, at 12:45 PM, MegaBrutal wrote:
> 2014-11-17 20:04 GMT+01:00 Goffredo Baroncelli :
>>
>> 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 snapsho
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
--
2014-11-17 20:04 GMT+01:00 Goffredo Baroncelli :
>
> 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 doesn't even get
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 w
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.
2014-11-17 7:59 GMT+01:00 Brendan Hide :
>
> 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
> the bug is in btrf
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
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 IDentifier".[
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 b
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 http://vger.kernel.org/majordomo
67 matches
Mail list logo
