From owner-freebsd-geom@FreeBSD.ORG Mon Jun 20 18:00:09 2011 Return-Path: Delivered-To: freebsd-geom@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id D9B3A106566C for ; Mon, 20 Jun 2011 18:00:09 +0000 (UTC) (envelope-from kris@pcbsd.org) Received: from mail.iXsystems.com (newknight.ixsystems.com [206.40.55.70]) by mx1.freebsd.org (Postfix) with ESMTP id A18828FC18 for ; Mon, 20 Jun 2011 18:00:09 +0000 (UTC) Received: from mail.ixsystems.com (localhost [127.0.0.1]) by mail.iXsystems.com (Postfix) with ESMTP id 07C6EA66428 for ; Mon, 20 Jun 2011 10:40:35 -0700 (PDT) Received: from mail.iXsystems.com ([127.0.0.1]) by mail.ixsystems.com (mail.ixsystems.com [127.0.0.1]) (amavisd-maia, port 10024) with ESMTP id 75699-07 for ; Mon, 20 Jun 2011 10:40:34 -0700 (PDT) Received: from [192.168.0.186] (75-130-56-30.static.kgpt.tn.charter.com [75.130.56.30]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (No client certificate requested) by mail.iXsystems.com (Postfix) with ESMTPSA id 97F02A66403 for ; Mon, 20 Jun 2011 10:40:34 -0700 (PDT) Message-ID: <4DFF8611.4090705@pcbsd.org> Date: Mon, 20 Jun 2011 13:40:33 -0400 From: Kris Moore User-Agent: Mozilla/5.0 (X11; U; FreeBSD amd64; en-US; rv:1.9.2.17) Gecko/20110430 Thunderbird/3.1.10 MIME-Version: 1.0 To: freebsd-geom@FreeBSD.ORG Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: Subject: gpart sizes way off X-BeenThere: freebsd-geom@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: GEOM-specific discussions and implementations List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 20 Jun 2011 18:00:10 -0000 Not sure if this has been reported, apologies if I'm late to noticing this. I'm not sure if something has changed in the past few weeks on CURRENT to cause this, or if we are just noticing it for the first time, but when doing installs and using "gpart add" for creating partitions on a 2nd MBR slice, the sizes we are giving it are WAY off what actually is allocated. For example: # gpart add -s 2048M -t freebsd-ufs -i 1 /dev/ada0s2 ada0s2a added # gpart add -s 1534M -t freebsd-swap -i 2 /dev/ada0s2 ada0s2b added # gpart add -s 2048M -t freebsd-ufs -i 4 /dev/ada0s2 ada0s2d added # gpart add -s 97165M -t freebsd-ufs -i 5 /dev/ada0s2 gpart: autofill: No space left on device There *should* be enough space for the last partition, but take a look what actually happened on disk: # gpart show ada0s2 => 0 210534400 ada0s2 BSD (100G) 0 5933056 1 freebsd-ufs (2.8G) 5933056 4880384 2 freebsd-swap (2.3G) 10813440 5933056 4 freebsd-ufs (2.8G) 16746496 193787904 - free - (92G) I'm unsure why 2048M is getting bumped up to 2.8G, same with 1534M -> 2.3G, but of course that explains why the last partition is failing. Here's the output of "gpart show ada0" for kicks: => 63 419430337 ada0 MBR (200G) 63 1985 - free - (992k) 2048 102400000 1 linux-data (48G) 102402048 210534400 2 freebsd (100G) 312936448 106493952 3 linux-data (50G) -- Kris Moore PC-BSD Software iXsystems