From owner-freebsd-geom@FreeBSD.ORG Tue Jun 19 13:17:51 2012 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 AD141106564A for ; Tue, 19 Jun 2012 13:17:51 +0000 (UTC) (envelope-from lee@dilkie.com) Received: from data.snhdns.com (data.snhdns.com [208.76.82.136]) by mx1.freebsd.org (Postfix) with ESMTP id 6C6328FC1A for ; Tue, 19 Jun 2012 13:17:51 +0000 (UTC) Received: from [142.46.160.218] (port=51350 helo=[206.51.1.11]) by data.snhdns.com with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.77) (envelope-from ) id 1SgxJG-0002Y1-OF; Tue, 19 Jun 2012 08:13:27 -0400 Message-ID: <4FE06CF2.7040108@dilkie.com> Date: Tue, 19 Jun 2012 08:13:38 -0400 From: Lee Dilkie User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:12.0) Gecko/20120428 Thunderbird/12.0.1 MIME-Version: 1.0 To: Rudi Kramer References: In-Reply-To: X-Enigmail-Version: 1.4.2 Content-Type: multipart/mixed; boundary="------------050507040200090306020106" X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - data.snhdns.com X-AntiAbuse: Original Domain - freebsd.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - dilkie.com X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Cc: freebsd-geom@freebsd.org Subject: Re: Gconcat + growfs: we are not growing 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: Tue, 19 Jun 2012 13:17:51 -0000 This is a multi-part message in MIME format. --------------050507040200090306020106 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Hi Rudi, Seems like you are hitting the same growfs bug that gets all of us that try to do this simple task. growfs needs a patch to use 64 bit math inside... I created such a beast a while back, based on some earlier work and fixed it up a bit myself. I'm a bit surprised that this hasn't been fixed in a newer freebsd release but such is life I guess. I'm running 7.4-STABLE FreeBSD and the version of growfs.c that my patch is based on is: __FBSDID("$FreeBSD: src/sbin/growfs/growfs.c,v 1.25.2.5 2011/03/05 04:33:42 brucec Exp $"); I've attached my patch/diff to fix things up.... you may have to modify it based ont he version of growfs.c that you have. It may also fail... it's worked for me through several "growings" of my gconcat array but YMMV as usual -lee On 6/19/2012 5:48 AM, Rudi Kramer wrote: > Hello, > > I am running a FreeBSD 8.2-RELEASE-p6 GENERIC (amd64) home media server I > wanted to find a way to add multiple disks to a single volume without using > raid because I am not too fussy about the data but I dont want one disk > failing to cause me to loose all my data. > > I found gconcat and it seemed to be the exact application I was looking for. > > I first created a volume with a single drive (1.5 TB) so that I could > migrate all my data across. (I was using zfs but as stated I dont need/want > raid). > > # gconcat label -v data /dev/ad4 > # newfs /dev/concat/data > # mount /dev/concat/data /mnt > > Everything seemed fine and I was able to migrate my data across with no > problems. > > I then tried to add two more drives (1 TB each) using the following > commands: > > # umount /dev/concat/data > # gconcat label data /dev/ad4 /dev/ad5 /dev/ad6 > > Once again everything looked fine and when I execute gconcat list I can see > the drives are added and the space allocation is correct. > > # gconcat list > Geom name: data > State: UP > Status: Total=3, Online=3 > Type: AUTOMATIC > ID: 1745188505 > Providers: > 1. Name: concat/data > Mediasize: 3500711680512 (3.2T) > Sectorsize: 512 > Mode: r0w0e0 > Consumers: > 1. Name: ad4 > Mediasize: 1500301910016 (1.4T) > Sectorsize: 512 > Mode: r0w0e0 > Start: 0 > End: 1500301909504 > 2. Name: ad5 > Mediasize: 1000204886016 (932G) > Sectorsize: 512 > Mode: r0w0e0 > Start: 1500301909504 > End: 2500506795008 > 3. Name: ad6 > Mediasize: 1000204886016 (932G) > Sectorsize: 512 > Mode: r0w0e0 > Start: 2500506795008 > End: 3500711680512 > > The problem comes when I try to grow the file system using growfs I get the > following error: > > growfs: we are not growing (732569291->635590051) > > I have tried using google to found out what could be causing the issue and > I found some information about creating a disk label but bsdlabel doesn't > work on large drives and I'm not sure this is even the correct answer and > so I decided to mail the list and see if anyone had some advice for me. > > Regards > Rudi > _______________________________________________ > freebsd-geom@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-geom > To unsubscribe, send any mail to "freebsd-geom-unsubscribe@freebsd.org" --------------050507040200090306020106 Content-Type: text/plain; charset=windows-1252; name="growfs.diff.64bit_fix" Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename="growfs.diff.64bit_fix" 159c159 < static void get_dev_size(int, int *); --- > static void get_dev_size(int, u_int64_t *); 1919c1919 < get_dev_size(int fd, int *size) --- > get_dev_size(int fd, u_int64_t *size) 1964c1964 < unsigned int size=0; --- > u_int64_t size=0; 1972c1972 < u_int32_t p_size; --- > u_int64_t p_size; 1986c1986 < size=(size_t)atol(optarg); --- > size=(size_t)atoll(optarg); 2081c2081 < p_size = pp->p_size; --- > p_size = (u_int64_t)pp->p_size; /* number sectors in partition table is 32 bits but we use 64 bit temp */ 2083c2083 < get_dev_size(fsi, &p_size); --- > get_dev_size(fsi, &p_size); 2120c2120 < sblock.fs_size = dbtofsb(&osblock, p_size); --- > sblock.fs_size = dbtofsb(&osblock, p_size); /* fs_size is 64 bits, p_size is too */ 2123c2123 < errx(1, "there is not enough space (%d < %d)", --- > errx(1, "there is not enough space (%jd < %jd)", 2126c2126 < sblock.fs_size = dbtofsb(&osblock, size); --- > sblock.fs_size = dbtofsb(&osblock, size); /* size is 64 bit now */ 2211c2211 < sblock.fs_size = sblock.fs_ncg * sblock.fs_fpg; --- > sblock.fs_size = (int64_t)sblock.fs_ncg * (int64_t)sblock.fs_fpg; 2222c2222,2223 < errx(1, "not enough new space"); --- > errx(1, "not enough new space (II) (%jd->%jd)", > (intmax_t)osblock.fs_size, (intmax_t)sblock.fs_size); --------------050507040200090306020106--