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

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

At date and time Fri, 20 Jun 2014 12:10:18 +0700, Robert Elz wrote:

>     Date:        Fri, 20 Jun 2014 01:20:03 +0100
>     From:        Gerard Lally <lists+netbsd.users%netmail.ie@localhost>
>     Message-ID:  <20140620012000.2C49.280FC639%netmail.ie@localhost>
>  | 
>   | 1) Is it safe to use GPT on NetBSD?
> 
> Yes, though it is a little tricky to get boot from gpt to work properly
> (you might have fluked onto the technique for that, unless it has been
> recently fixed, you need to first make a bootable MBR, then convert to
> to GPT, and not try to simply do the GPT boot process on a virgin disk).
> (No need for the MBR partitions and GPT ones to be related at all, it is
> the MBR init, which becomes PMBR init, that is important here).

Luckily enough I came upon the instructions below, and booting worked
for me without issue:

http://wiki.netbsd.org/users/jakllsch/gptboot/

>   | 3) Using "NAME=dk0" in /etc/fstab didn't work for me; I had to specify
>   | /dev/dk0, /dev/dk1, etc.
>   | dk names also do not persist across reboots. For example, if I create a
>   | wedge as follows the dk_swap name reverts to dk1 after rebooting.
> 
> That stuff really doesn't work in NetBSD 6, you need a -current
> kernel (or something from the past 6-9 months on the current stream)
> to get this functioning the way it should.  It would be nice for all
> the wedge labeling, and auto-discovery, to get pulled up...

Yes, that seems to be the consensus here. It's no big deal, although it
will be useful to have in 7.

>   | dkctl wd0 addwedge dk_swap 64 2097152 swap
>   | 
>   | 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?
> 
> Yes, the GPT label is the name value.  But the label in addwedge is the
> same thing, but I think only applied n ram, not written back to the filesys
> (not sure about that, but it certainly gave me some weirdness when I
> started).
> 
>   | 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.
> 
> Sounds OK.
> 
>   | 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?
> 
> Safe, if a little over cautious.
> 
>   | I am not really familiar with partition alignment, and even less so
>   | since the new disks came out.
> 
> As Greg said, just avoid splitting things so that one write requires
> a read/modify/write on the drive (so your writes should be whole drive
> sectors).  For some big drives that's 2K or 4K, so everything (even
> perhaps filesys fragment size) should be multiples of that.
> 
> Most important is to forget that the magic number "63" (or anything like
> it) ever existed...
> 
> I'll append a script I use to make GPT partitions and do most of the
> rest of the work (it uses NAME=... entries in data it adds to fstab if
> fstab already contains any of those, otherwise not - so if they're to
> work, you need to add one NAME= entry manually.)

A useful script to have. Many thanks. (Aside: are you the same Robert
Elz who was involved from the outset in FFS? Just by coincidence I was
reading an article from the 80s the other day which mentioned the name
in connection with FFS. Very interesting to have all these venerable
hackers around if so!)

-- 
Gerard Lally