Date: Sun, 11 Sep 2016 06:53:47 -0600 (MDT) From: Warren Block <wblock@wonkity.com> To: Perry Hutchison <perryh@pluto.rain.com> Cc: smithi@nimnet.asn.au, freebsd-questions@freebsd.org Subject: Re: "gpart add" falsely claiming "No space left on device" Message-ID: <alpine.BSF.2.20.1609110647070.97061@wonkity.com> In-Reply-To: <57d4d4ee.HRXXT5d/ZCIb3KuI%perryh@pluto.rain.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> <57d4d4ee.HRXXT5d/ZCIb3KuI%perryh@pluto.rain.com>
next in thread | previous in thread | raw e-mail | index | archive | help
On Sat, 10 Sep 2016, Perry Hutchison wrote: > 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. Ah, "b" for blocks, not bytes. I guarantee I have never used that on FreeBSD, and never experienced a problem. On disks, I routinely use bs=64K, and 1M for flash can help transfer rates. >>>> 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? It was not clear what you were trying to do. "-f x" added to that. At this point, it's still confusing how you did a recover if the old version of gpart being used did not support that. >>>> 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. The details of the PMBR do not matter much. It is supposed to be a static structure, an MBR with a single partition, type 0xEE, sized to fill the entire disk or 2TB, whichever is smaller.
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?alpine.BSF.2.20.1609110647070.97061>