[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index][Old Index]
Re: GPT questions - gpt reliability, wedge naming, and filesystem scaling.
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:
> | 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
> | 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!)
Main Index |
Thread Index |