From owner-freebsd-questions@freebsd.org Sun Sep 11 04:10:59 2016 Return-Path: Delivered-To: freebsd-questions@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id BBC90BD4126 for ; Sun, 11 Sep 2016 04:10:59 +0000 (UTC) (envelope-from perryh@pluto.rain.com) Received: from agora.rdrop.com (agora.rdrop.com [IPv6:2607:f678:1010::34]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 9A20ED7E for ; Sun, 11 Sep 2016 04:10:59 +0000 (UTC) (envelope-from perryh@pluto.rain.com) Received: from agora.rdrop.com (66@localhost [127.0.0.1]) by agora.rdrop.com (8.13.1/8.12.7) with ESMTP id u8B4Ao5R007353 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Sat, 10 Sep 2016 21:10:51 -0700 (PDT) (envelope-from perryh@pluto.rain.com) Received: (from uucp@localhost) by agora.rdrop.com (8.13.1/8.14.2/Submit) with UUCP id u8B4AnI7007352; Sat, 10 Sep 2016 21:10:49 -0700 (PDT) (envelope-from perryh@pluto.rain.com) Received: from fbsd81 by pluto.rain.com (4.1/SMI-4.1-pluto-M2060407) id AA10834; Sat, 10 Sep 16 20:52:05 PDT 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> References: <20160907000551.F91459@sola.nimnet.asn.au> <57cfab90.qRHpzKSiF/A9Stt1%perryh@pluto.rain.com> <20160910022609.E91459@sola.nimnet.asn.au> In-Reply-To: User-Agent: nail 11.25 7/29/05 Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-BeenThere: freebsd-questions@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: User questions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 11 Sep 2016 04:10:59 -0000 Warren Block 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.