Skip site navigation (1)Skip section navigation (2)
Date:      Sat, 10 Sep 2016 20:52:14 -0700
From:      perryh@pluto.rain.com (Perry Hutchison)
To:        wblock@wonkity.com, smithi@nimnet.asn.au
Cc:        freebsd-questions@freebsd.org
Subject:   Re: "gpart add" falsely claiming "No space left on device"
Message-ID:  <57d4d4ee.HRXXT5d/ZCIb3KuI%perryh@pluto.rain.com>
In-Reply-To: <alpine.BSF.2.20.1609091441170.50899@wonkity.com>
References:  <mailman.109.1473163202.26682.freebsd-questions@freebsd.org> <20160907000551.F91459@sola.nimnet.asn.au> <57cfab90.qRHpzKSiF/A9Stt1%perryh@pluto.rain.com> <20160910022609.E91459@sola.nimnet.asn.au> <alpine.BSF.2.20.1609091441170.50899@wonkity.com>

next in thread | previous in thread | raw e-mail | index | archive | help
Warren Block <wblock@wonkity.com> wrote:
> On Sat, 10 Sep 2016, Ian Smith wrote:
> > On Tue, 6 Sep 2016 22:54:24 -0700, Perry Hutchison wrote:
> > > (Old-timers will remember why some of us
> > > don't like to exceed bs=126b with dd :)
> > I only go back to '98 on FreeBSD; never heard of that ...
> I don't see any reason to use less than block sizes ...
> Actually, I don't see any reason to use less than 64K or even 1M buffer 
> size.  Smaller sizes add huge amounts of overhead with no benefit. 

This goes back farther than FreeBSD, to SunOS 4.1 or earlier.

The old-timers I mentioned remember DMA hardware that could not handle
a buffer spanning a 64KB physical boundary.  It's difficult for a
driver to comply with such a limitation if the blocksize is larger :)

bs=128b is exactly 64KB, and some of those drivers would throw an
error on that, so 126b became the largest considered advisable
absent knowledge that the particular hardware in use could handle
larger.

> > > BTW it did boot (I only tried single-user mode) and worked
> > > well enough to resize itself with "gpart recover".
> >
> > Um, do you mean you ran gpart recover on the stick you'd
> > booted off?

Yep.  No other choice.  8.1 gpart does not understand "recover" --
although 8.1 geom does complain about the missing backup GPT table
and say something like "recovery recommended".

> This works but is unnecessary.  Unless you want to store more stuff
> on the install stick ...

Precisely.  Why else would I be trying to create another partition
on it?

> > [big cut]
> >
> > > # fdisk /dev/da2
> > > ******* Working on device /dev/da2 *******
> > > parameters extracted from in-core disklabel are:
> > > cylinders=486 heads=255 sectors/track=63 (16065 blks/cyl)
> > > [..]
> > > Media sector size is 512
> > > Warning: BIOS sector numbering starts with sector 1
> > > Information from DOS bootblock is:
> > > The data for partition 1 is:
> > > sysid 238 (0xee),(EFI GPT)
> > >     start 1, size 7811071 (3813 Meg), flag 0
> > >         beg: cyl 0/ head 0/ sector 2;
> > >         end: cyl 1023/ head 255/ sector 63
> > >
> > > which I take to be the protective MBR of the GPT scheme.
>
> Of course, fdisk knows nothing but MBR.  Please stop using fdisk.

Is there another program that will display the details of the
protective MBR?  AFAIK "gpart show" shows only the GPT itself.



Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?57d4d4ee.HRXXT5d/ZCIb3KuI%perryh>