Date: Wed, 17 May 2006 16:39:58 -0600 (MDT) From: Warner Losh <imp@bsdimp.com> To: pjd@FreeBSD.org Cc: rosti.bsd@gmail.com, grafan@gmail.com, freebsd-current@FreeBSD.org, marius.nuennerich@gmx.net, andrew@fubar.geek.nz Subject: Re: BSDInstaller snapshot Message-ID: <20060517.163958.104104832.imp@bsdimp.com> In-Reply-To: <20060517085720.GA98040@garage.freebsd.pl> References: <20060517065702.GC96341@garage.freebsd.pl> <20060517104531.ee66f23e.rosti.bsd@gmail.com> <20060517085720.GA98040@garage.freebsd.pl>
next in thread | previous in thread | raw e-mail | index | archive | help
> +> > +> I think BSDInstaller should change to not create first slice at offset 0. > +> ^^^^^ > +> Yet another "bsd slice" / "bsd partition" confusion? :-) > +> > +> > > +> > Grrr!!! DEFINITELY! Please, first partition at offset 16. > +> > +> Interesting. Sysinstall makes the first "a" partition on a slice at > +> offset 0 and FreeBSD works properly. What is this metadata on those > +> first 16 sectors of a slice and when this metadata is really used? > > What?! You only think it works properly. It doesn't. > UFS works on such partition, because UFS has a hack to skip first 16 > sectors. Swap works on such partition, because swap code has a hack to > skip first 16 sectors. UFS was designed to work properly here. The label was supposed to be in the first 16 sectors of the disk, so any file system in traditional unix that dealt with disks also had to cope with this 16 sector offset. However, time has marched on since 1970's and 80's when this was a reasonable thing to do. Moving it to sector 16 is just as magic as sector 0. How do we know that the boot code is going to be 8k? why not 16k or 32k or 1024k? There were fields added to the bsdlabel recently for this (d_bbsize) and the area skipped to reflect this based on the boot code size for that platform. > Try to encrypt partition which starts at offset 16 with geli(8) or > gbde(8). Try to concatenate or stripe two partitions that start at > offset 16. > The former will destroy your metadata (at least it did so, not sure if > you won't get EPERM now). The latter will return EPERM when you try to > access data in the middle of your concat device or at the begining of > you stripped device. > Many evil things can happen, belive me. Using offset 0 and making > metadata visible from usable partition is BAD. Period. It would be better to say that having the partitions overlap the metadata for the partiutions is bad. We avoid this already for slices. Maybe we should also avoid this for bsd label partitions and the boot code they describe. It would be a layering violation for the geom entities to reach into the label to find out if they need to skip space. The disk label is only 148 + 16 * 8 bytes long (276 of the first 512 bytes, which was the reason for boot1 vs boot2, since boot1 could only use 236 bytes of code to get boot2 into memory). So we should be careful with the new installer that it respects what we put on disk rather than hard coding 16. Finally, there likely needs to be a 'raid override' for the default values. Better to waste an entire stripe than to start a partition in the middle of a stripe. I'm not sure how best to accomplish this, but I'm sure that others in the community who routinely tweak this for optimal performance can comment. Warner
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20060517.163958.104104832.imp>