On Thu 03 Oct 2019 at 10:17:47 -0700, John Nemeth wrote:
> On Oct 3, 2:42pm, Rhialto wrote:
> } I was thinking the other day that it might be useful if gpt had a
> } subcommand to spit out a script to duplicate the partitioning of a disk,
> } but without the "unique" parts. The script would of
On Oct 3, 2:42pm, Rhialto wrote:
} On Wed 02 Oct 2019 at 19:40:01 -0700, John Nemeth wrote:
} > Cloning disks always presents issues. However, gpt(8) has
} > grown a "uuid" command to generate new UUIDs. This was primarily
} > done to help with the cloning problem. Cloning a disk and then
On Thu, Oct 03, 2019 at 09:51:40AM -0600, Warner Losh wrote:
> NetBSD is, of course, free to do what it likes. My semi-outsider's view
> suggests, though, that the FreeBSD experience is relevant and timely.
So this discussion wandered off topic a bit. Of course NetBSD already
supports gpt and
On Thu, Oct 3, 2019 at 9:19 AM Robert Elz wrote:
> Now it makes no sense at all.
>
FreeBSD made the explicit decision when disks were sneaking up on 2TB to
move to GPT labels. Why invent a new scheme that interoperates poorly with
other things? GPT, for better or worse, won. disklabel64 would
Date:Wed, 2 Oct 2019 21:47:38 -0400 (EDT)
From:Mouse
Message-ID: <201910030147.vaa03...@stone.rodents-montreal.org>
John Nemeth said pretty much exactly what I would have said, but
there are a few points on which I would like to expand...
| - Partitions are huge.
On Thu, Oct 03, 2019 at 02:42:10PM +0200, Rhialto wrote:
> I was thinking the other day that it might be useful if gpt had a
> subcommand to spit out a script to duplicate the partitioning of a disk,
> but without the "unique" parts. The script would of course be
> hand-editable for any changes
On Wed 02 Oct 2019 at 19:40:01 -0700, John Nemeth wrote:
> Cloning disks always presents issues. However, gpt(8) has
> grown a "uuid" command to generate new UUIDs. This was primarily
> done to help with the cloning problem. Cloning a disk and then
> putting two disks with the same UUIDs
While I agree NetBSD needs to support and work well with GPT in order
to interoperate with other systems, there is also prior art in
extending disklabel to 64bits - OpenBSD did this back in 2007 (though
there were a fair few follow up commits to cleanup the fallout :)
On Oct 2, 9:47pm, Mouse wrote:
}
} >> If _that_'s what you're concerned about, then just grow the relevant
} >> fields (and, presumably, change the magic number).
} > Any change to the label format or semantics would make it be a
} > completely different object, no longer compatible with
>> If _that_'s what you're concerned about, then just grow the relevant
>> fields (and, presumably, change the magic number).
> Any change to the label format or semantics would make it be a
> completely different object, no longer compatible with anything.
Of course.
> If we were going to
Date:Wed, 2 Oct 2019 10:48:26 -0400 (EDT)
From:Mouse
Message-ID: <201910021448.kaa25...@stone.rodents-montreal.org>
| If _that_'s what you're concerned about, then just grow the relevant
| fields (and, presumably, change the magic number).
Any change to the
> however, disklabel fails at >2TiB for 512 byte sector,
If _that_'s what you're concerned about, then just grow the relevant
fields (and, presumably, change the magic number).
Or fix sector sizes other than 512 bytes.
/~\ The ASCII Mouse
\ / Ribbon Campaign
X
Date:Mon, 30 Sep 2019 06:43:10 - (UTC)
From:mlel...@serpens.de (Michael van Elst)
Message-ID:
| It also says 'fictitious' when you then write that label and read it
| back (and that magic word is also used by the wedge naming code to
| be treated like an
m...@eterna.com.au (matthew green) writes:
>however, disklabel fails at >2TiB for 512 byte sector, so i'm
>now thinking that fixing this doesn't really solve the problem
>for the future properly -- disklabel doesn't return a true
>label here anyway... so it seems that we should be retiring
k...@munnari.oz.au (Robert Elz) writes:
>Yes, we will - but can't we make that something detectable? If the
>kernel invents a lael, it says "fictitious" in the label field.
It also says 'fictitious' when you then write that label and read it
back (and that magic word is also used by the wedge
On Mon, Sep 30, 2019 at 11:15:02AM +1000, matthew green wrote:
> however, disklabel fails at >2TiB for 512 byte sector, so i'm
> now thinking that fixing this doesn't really solve the problem
> for the future properly -- disklabel doesn't return a true
> label here anyway... so it seems that we
> Yes, we will - but can't we make that something detectable? If the
> kernel invents a lael, it says "fictitious" in the label field.
i had a similar idea, and i like your "converted" idea too.
i was looking at struct disklabel itself, and while i realised
we could probably abuse d_subtype to
Date:Sun, 29 Sep 2019 13:32:51 +0200
From:Martin Husemann
Message-ID: <20190929113251.ga12...@mail.duskware.de>
| If you just ask for the label
|
| disklabel $mydisk
|
| you will always get something.
Yes, we will - but can't we make that something
mar...@duskware.de (Martin Husemann) writes:
>So far all good. But there is a catch: some architectures have native
>ways to store their partitions and no real userland support for those schemes.
Some drivers may also have their own idea about what disklabels
are, in particular cd(4). I wouldn't
> So far all good. But there is a catch: some architectures have native
> ways to store their partitions and no real userland support for those
> schemes. [...]
> Userland, however, has no way (that I know of) to learn about such
> conversions. The above recipe with "disklabel -r" will fail on
20 matches
Mail list logo
