From owner-freebsd-current@FreeBSD.ORG Mon Feb 4 05:14:38 2013 Return-Path: Delivered-To: freebsd-current@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id 19D4842D; Mon, 4 Feb 2013 05:14:38 +0000 (UTC) (envelope-from wblock@wonkity.com) Received: from wonkity.com (wonkity.com [67.158.26.137]) by mx1.freebsd.org (Postfix) with ESMTP id B2772D84; Mon, 4 Feb 2013 05:14:37 +0000 (UTC) Received: from wonkity.com (localhost [127.0.0.1]) by wonkity.com (8.14.6/8.14.6) with ESMTP id r145ETTK009207; Sun, 3 Feb 2013 22:14:29 -0700 (MST) (envelope-from wblock@wonkity.com) Received: from localhost (wblock@localhost) by wonkity.com (8.14.6/8.14.6/Submit) with ESMTP id r145ERVZ009204; Sun, 3 Feb 2013 22:14:27 -0700 (MST) (envelope-from wblock@wonkity.com) Date: Sun, 3 Feb 2013 22:14:27 -0700 (MST) From: Warren Block To: Tim Kientzle Subject: Re: gpart resize vs. cache? In-Reply-To: Message-ID: References: <3D812191-2D6E-43B2-B9C1-F00FFA44C5F8@freebsd.org> <1359925713.93359.440.camel@revolution.hippie.lan> User-Agent: Alpine 2.00 (BSF 1167 2008-08-23) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.2.7 (wonkity.com [127.0.0.1]); Sun, 03 Feb 2013 22:14:29 -0700 (MST) Cc: Erich Dollansky , freebsd-current Current , Ian Lepore X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 04 Feb 2013 05:14:38 -0000 On Sun, 3 Feb 2013, Tim Kientzle wrote: > On Feb 3, 2013, at 1:08 PM, Ian Lepore wrote: > >> On Sun, 2013-02-03 at 12:06 -0800, Tim Kientzle wrote: >>> I'm tinkering with a disk image that automatically >>> fills whatever media you put it onto. But I'm having >>> trouble with gpart resize failing. >>> >>> Disk layout: >>> MBR with two slices mmcsd0s1 and mmcsd0s2 >>> bsdlabel with one partition mmcsd0s2a >>> >>> Before I can use growfs, I have two gpart resize operations: >>> >>> 1) gpart resize -i 2 mmcsd0 >>> >>> 2) gpart resize -i 1 mmcsd0s2 >>> >>> Step 1 resizes mmcsd0s2 and always succeeds. >>> >>> Step 2 resizes mmcsd0s2a and always fails >>> with "No space on device." >>> >>> BUT if I reboot between these steps, step #2 >>> always succeeds. >>> >>> I suspect that step #1 is updating the partition >>> information on disk but that step #2 is somehow >>> reading the old size of mmcsd0s2 and thus finding >>> that there is no available space to grow the partition. > > BTW, I've added some debug messages to gpart > and the second resize is failing because the new > computed size is a little smaller than the old size > (maybe because of a different alignment?). But > it's certainly not sizing to the new container size. MBR always forces alignment to imaginary CHS tracks, as if you used -a63 in gpart. But it's not gpart, it's the kernel being really strict about standards. As far as I've been able to tell, there is no way around that short of possibly dd-ing a preconstructed MBR partition table into place.