Discussion:
cgd > 2T
Patrick Welche
2014-06-27 22:28:07 UTC
Permalink
I set up a cgd with:

# gpt show cgd1
start size index contents
0 1 PMBR
1 1 Pri GPT header
2 32 Pri GPT table
34 30
64 5860553790 1 GPT part - NetBSD FFSv1/FFSv2
5860553854 32 Sec GPT table
5860553886 1 Sec GPT header

so, obviously it can't have a disklabel. The partition at offset 64 is
a valid ffs2 partition - should I expect the verification method "ffs"
to work, or not because it isn't disklabel based? (I only seem to have
success with "re-enter")

Cheers,

Patrick
Greg Troxel
2014-06-27 23:29:42 UTC
Permalink
Post by Patrick Welche
# gpt show cgd1
start size index contents
0 1 PMBR
1 1 Pri GPT header
2 32 Pri GPT table
34 30
64 5860553790 1 GPT part - NetBSD FFSv1/FFSv2
5860553854 32 Sec GPT table
5860553886 1 Sec GPT header
so, obviously it can't have a disklabel. The partition at offset 64 is
a valid ffs2 partition - should I expect the verification method "ffs"
to work, or not because it isn't disklabel based? (I only seem to have
success with "re-enter")
You have taken the cgd and made a GPT label. So you'd need to use the
"gpt" verification method, after you write it.

You should be able to just newfs the raw /dev/cgd0d (or c).
Patrick Welche
2014-07-04 14:57:47 UTC
Permalink
Post by Greg Troxel
You have taken the cgd and made a GPT label. So you'd need to use the
"gpt" verification method, after you write it.
Right! (and point about library functions taken)
Post by Greg Troxel
You should be able to just newfs the raw /dev/cgd0d (or c).
Hmmm:

# newfs -O2 -o space /dev/rcgd1d
newfs: /dev/rcgd1d partition type is not `4.2BSD'

(no label nor gpt...)

Cheers,

Patrick
Takahiro HAYASHI
2014-07-05 00:06:03 UTC
Permalink
hi,
Post by Patrick Welche
# newfs -O2 -o space /dev/rcgd1d
newfs: /dev/rcgd1d partition type is not `4.2BSD'
(no label nor gpt...)
newfs -F forces making a filesystem, e.g.

# newfs -O2 -F -s 5860553790 /dev/rcgd1d


Regards,
--
t-hash
Robert Elz
2014-06-28 08:36:28 UTC
Permalink
Date: Fri, 27 Jun 2014 19:29:42 -0400
From: Greg Troxel <***@ir.bbn.com>
Message-ID: <***@fnord.ir.bbn.com>

| So you'd need to use the "gpt" verification method, after you write it.

I considered doing that 6 months or so ago when I was setting up a new cgd
on a system that was (until then) disklabel free (GPT everywhere).

However, I was unable to locate any rational method of doing GPT validation,
other than writing the code from scratch (or stealing a copy from one of
the current users of it, and bending it to suit). That is, I was unable to
locate any library function for reading &/or verifying a GPT label.
There is such a function for disklabels (which cgd uses).

Could someone who works with GPTs please make a version of that in libutil
(or wherever) (and perhaps use it in other places as well) - once that is
done, making cgdconfig use it would be trivial.

Having many (probably slightly different) GPT reading functions spread
throughout the system isn't the right solution.

| You should be able to just newfs the raw /dev/cgd0d (or c).

In my case I actually wanted several filesystems inside the cgd (filesystems
are a useful abstraction in their own right, they have properties that
don't always need to be the same - just using one bit pot isn't always the
right solution). Fortunately, in my case, the desire for GPT was purely
ego driven, the CGD wasn't so big as to insist on that, so I just gave up
and installed a disklabel instead. It would be nice to convert it however...

kre
Chris Bannister
2014-06-28 10:16:11 UTC
Permalink
Post by Patrick Welche
# gpt show cgd1
start size index contents
0 1 PMBR
1 1 Pri GPT header
2 32 Pri GPT table
34 30
64 5860553790 1 GPT part - NetBSD FFSv1/FFSv2
5860553854 32 Sec GPT table
5860553886 1 Sec GPT header
so, obviously it can't have a disklabel.
Excuse me for interrupting ... but why "obviously"?
--
"If you're not careful, the newspapers will have you hating the people
who are being oppressed, and loving the people who are doing the
oppressing." --- Malcolm X
Jan Danielsson
2014-06-28 13:38:13 UTC
Permalink
On 28/06/14 12:16, Chris Bannister wrote:
[---]
Post by Chris Bannister
Post by Patrick Welche
so, obviously it can't have a disklabel.
Excuse me for interrupting ... but why "obviously"?
http://www.feyrer.de/NetBSD/bx/blosxom.cgi/index.front?-tags=wedges

Last sentence of
http://mail-index.netbsd.org/current-users/2006/09/04/0005.html:

``No > 2TB partitions when using the old on-disk formats though.''

I guess "obvious" is in the eye of the beholder, but the limitations
of disklabels have been reachable for regular users for a few years now.
--
Kind Regards,
Jan
Patrick Welche
2014-06-28 20:42:16 UTC
Permalink
Post by Chris Bannister
Post by Patrick Welche
# gpt show cgd1
start size index contents
0 1 PMBR
1 1 Pri GPT header
2 32 Pri GPT table
34 30
64 5860553790 1 GPT part - NetBSD FFSv1/FFSv2
5860553854 32 Sec GPT table
5860553886 1 Sec GPT header
so, obviously it can't have a disklabel.
Excuse me for interrupting ... but why "obviously"?
The number of blocks is 5860553790 which is bigger than what can be
stored in the disklabel's

struct disklabel {
...
struct partition { /* the partition table */
uint32_t p_size; /* number of sectors in partition */
...

unsigned 32 bit int (4294967295) for size in blocks => need to use gpt(8)
(or from Greg's hint - just use the raw cgd)

Cheers,

Patrick
Loading...