Gerard Lally <lists+netbsd.users%netmail.ie@localhost> writes:
> 1) Is it safe to use GPT on NetBSD? The warnings on the gpt man page
> leave me less than 100% confident.
On NetBSD 6, I would say yes. Even on 5, I think so. I am not really
clear on booting from GPT, but for other than the boot/root fs it should
be fine. I have multiple systems with gpt disks and no issues.
> 2) As I understand it the NetBSD FFS filesystem is capable of growing
> to 8 zettabytes, but MBR partitioning combined with traditional
> disklabels meant we were restricted to 2 (or 4) TB partitions in
> practice. Am I right in saying that GPT and wedges remove this
> restriction, and we can now create partitions and filesystems greater
> than 4TB?
I think disklabels are limited to 2TB; I'm not sure if it's the whole
disk or per partition. (Maybe that's 4TB.) That is correct - GPT does
not have a 2TB limit.
> 3) Using "NAME=dk0" in /etc/fstab didn't work for me; I had to specify
> /dev/dk0, /dev/dk1, etc.
>
> This is not a big deal but it leaves me wondering how NAME=xxx in fstab
> is supposed to work. Does it work with GPT labels instead?
My impression is that NAME matched the gpt label, so you could mount a
disk with label foo on /volumes/foo repeatedly.
> 4) To get the sector offsets and sizes right I first created a
> traditional MBR + disklabel setup, sizing partitions in MB and taking
> note of the sector offsets and sector sizes this produced. I started at
> 2048. After destroying the MBR + disklabel setup I then used this
> information to create GPT partitions. I assume this is a safe way to do
> it? I am not really familiar with partition alignment, and even less so
> since the new disks came out.
In the modern world, disks don't really have consistent geometries. So
the big alignment issue is to make sure that you line up on physical
blocks, which are often 4K (on disks 2T and greater, or maybe 1T or
greater). And, there is some threat of larger physical sizes later.
So, two recommendations are:
start the first partition at some multiple of 64 (because it's a
multiple of any sane near-term size).
start the first partition at 1 MB (2048 * 512 sectors), which is an
even rounder number, and is still a negligible space waste. (This
really surprised me when I did the math; I remember using 2.5 MB
disks.)
Whatever you do - don't start things at sector 34, which is the start of
available space. Here's "gpt show" from a 1T disk I have in use. Note
that I didn't worry about the exact size being round.
start size index contents
0 1 PMBR
1 1 Pri GPT header
2 32 Pri GPT table
34 30
64 1953525071 1 GPT part - NetBSD FFSv1/FFSv2
1953525135 32 Sec GPT table
1953525167 1 Sec GPT header
So I really don't see why you are making disklabels and then
transferring numbers. Just make all the start and size values a
multiple of 2048 sectors, for some size that's round in binary, or close
to what you want. Or live on the edge at 64 like I did (I'm kidding; I
don't think there's anything wrong with 64).
If you find the man pages saying things that are wrong, feel free to
send a patch fixing it.
Attachment:
pgpmTdmL3d6KY.pgp
Description: PGP signature