Date: Tue, 19 Jun 2012 08:13:38 -0400 From: Lee Dilkie <lee@dilkie.com> To: Rudi Kramer <rudi.kramer@gmail.com> Cc: freebsd-geom@freebsd.org Subject: Re: Gconcat + growfs: we are not growing Message-ID: <4FE06CF2.7040108@dilkie.com> In-Reply-To: <CAJrXP6PwVd%2Bth8crz18K0hODUtUtRMLh_VJFpPZ=Btp3NBYMEg@mail.gmail.com> References: <CAJrXP6PwVd%2Bth8crz18K0hODUtUtRMLh_VJFpPZ=Btp3NBYMEg@mail.gmail.com>
next in thread | previous in thread | raw e-mail | index | archive | help
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--
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?4FE06CF2.7040108>