[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 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
> 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.
> 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).
Main Index |
Thread Index |