Re: GPT questions - gpt reliability, wedge naming, and filesystem scaling.

[Gerard Lally <lists+netbsd.users%netmail.ie@localhost>]

At date and time Thu, 19 Jun 2014 21:51:12 -0400, Greg Troxel wrote:

> 
> 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.

That's great. It will be a while before I get >2TB disks for my data but
I'm glad the restrictions won't be there when I do.

> > 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).

Well I did it that way because I hadn't really looked into sizing
partitions by sector before, but when you mentioned it I went off and
learned how to do it, using basic maths. Very straightforward actually.
Thanks!

> If you find the man pages saying things  that are wrong, feel free to
> send a patch fixing it.

Yes I would like to start contributing back to NetBSD, but it will be
mostly documentation (English and Philosophy were my subjects).

-- 
Gerard Lally