Problem adding new slices

Kevin Oberman oberman at es.net
Sun Aug 5 17:53:49 PDT 2007


> Date: Sun, 05 Aug 2007 17:30:34 -0700
> From: Jason Edward Kocol <mrkocol at cv.org>
> 
> Kevin Oberman wrote:
> > Sorry. I read that there was no /dev/ad0s3, so there was no reason to
> > ask for the bsdlabel output.
> > 
> > First, the slicing looks good. All of the numbers are reasonable and add
> > up correctly.
> > 
> > I now must suspect it's a GEOM issue. It looks like GEOM is not tasting
> > the drive properly, but this gets out of my realm of expertise. I would
> > suggest getting the dmesg from a verbose boot and posting it along with
> > your kernel config somewhere so that people can examine them. And let us
> > know when the sources were updated. 
> > 
> > I suspect I will not be the one to find anything, though. Everything
> > looks fine to me...except that it does not work. :-(
> 
> I don't know what I did differently this time, but I finally got it to 
> work.  Here are the steps I took.  May not be the best method but it got 
> the slice created and mountable.  I didn't like all the reboots but they 
> seemed to make a difference.
> 
> 1) Ran sysinstall.  Created slice ad0s3 in fdisk using the remaining 
> portion of the disk (just so I don't have to go through this again). 
> Wrote changes here.  Rebooted.
> 2) Checked /dev.  /dev/ad0s3 and /dev/ad0s3c finally exist, therefore 
> off to a better start.
> 3) Ran sysinstall again.  Created /d partition in label editor.  Wrote 
> changes.  Rebooted.
> 4) Checked /dev.  /dev/ad0s3d is now there.
> 
> It was at this point that I tried to mount the partition, which failed 
> with an incorrect super block error.  Then it occurred to me that I 
> never actually saw newfs run from sysinstall like it usually does during 
> a fresh install or adding a new disk.  So I did one more step:
> 
> 5) newfs /dev/ad0s3d.
> 
> The partition was able to be mounted.
> 
> Here are some caveats to this whole thing, for those that are interested:
> 
> - Needed to run 'sysctl kern.geom.debugflag=16' every time I needed to 
> write a change to the disk after a fresh boot, since it was a new 
> partition on the disk for the running system.
> - sysinstall reported that the geometry was incorrect for this disk, so 
> it used a "more likely geometry."  I don't remember the values it chose, 
> but when I tried to put in the ones that my BIOS reported it didn't like 
> those either.  So your suspicions of a GEOM issue may have been 
> well-founded initially.
> 
> I would post a verbose dmesg and kernel config as suggested, but since 
> everything works now I don't know how useful or necessary it would be to 
> anyone else who might encounter this problem.  The whole thing was 
> rather mysterious to me from the get-go, quite honestly.

If it's done, there is probably no reason to post anything else.

As far as newfs(8) is concerned, you need to use 'T' on any partition you
want to have newfs(8) run on. If you choose auto, it is set by
default. You probably want to always set up new partitions with newfs
and softupdates. Of course, if you know that the disk will be mostly
large files or lots of small files, you may want to adjust newfs
parameters for greater efficiency.

In the future, it seems like zfs will be a better option for this sort
of thing, but it won't be available until V7 is out and, even then, will
work far better on 64 bit systems.
-- 
R. Kevin Oberman, Network Engineer
Energy Sciences Network (ESnet)
Ernest O. Lawrence Berkeley National Laboratory (Berkeley Lab)
E-mail: oberman at es.net			Phone: +1 510 486-8634
Key fingerprint:059B 2DDF 031C 9BA3 14A4  EADA 927D EBB3 987B 3751
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 224 bytes
Desc: not available
Url : http://lists.freebsd.org/pipermail/freebsd-stable/attachments/20070806/8ad00ca2/attachment.pgp


More information about the freebsd-stable mailing list