From owner-freebsd-fs@FreeBSD.ORG Tue Oct 12 10:36:24 2010 Return-Path: Delivered-To: freebsd-fs@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id F26E01065670 for ; Tue, 12 Oct 2010 10:36:24 +0000 (UTC) (envelope-from tobfr108@gmail.com) Received: from mail-ew0-f54.google.com (mail-ew0-f54.google.com [209.85.215.54]) by mx1.freebsd.org (Postfix) with ESMTP id 44BEA8FC08 for ; Tue, 12 Oct 2010 10:36:23 +0000 (UTC) Received: by ewy21 with SMTP id 21so10750ewy.13 for ; Tue, 12 Oct 2010 03:36:23 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:subject:mime-version :content-type:from:in-reply-to:date:cc:content-transfer-encoding :message-id:references:to:x-mailer; bh=g1T1+QkzAUW1+lQZTa1s0HyiMyy640mW6lXOBPGzeko=; b=eDtO7AwATSrpu/26nwV1Khw8X/ijN3EAQ/Fz41UnayQSnJEIs4jPAiMInZTqWtnsE2 KzoJBdfrCOaH4Hv2Z3cEWFCzT4js3fEEkheTLMYBgAHqW1IdV2i2WMJR8VO5Ok5x3wcZ YN9whRD07ld4yzCWBEMf/R42lfo18b28h0p5Y= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=subject:mime-version:content-type:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to:x-mailer; b=TnPsjGZl4f0Lv6yNoPWMejyOnV9N9HSqzQhjo5EFpK7qKqHhkoNcp50rkrtih1CVq7 FoqYBatqJyU+/N2yVgxec49WYjOsyn2XN9HKG62O7RI1J4idGP1oLDcRvnCRuVwcmDHC ipUgTMwe6ptgYU0aQuSt8JiWvLDu8d5Uvk860= Received: by 10.14.119.7 with SMTP id m7mr4001296eeh.39.1286879783177; Tue, 12 Oct 2010 03:36:23 -0700 (PDT) Received: from [192.168.3.110] (gn62-116-241-3.business.gavlenet.com [62.116.241.3]) by mx.google.com with ESMTPS id v59sm12641561eeh.4.2010.10.12.03.36.21 (version=TLSv1/SSLv3 cipher=RC4-MD5); Tue, 12 Oct 2010 03:36:21 -0700 (PDT) Mime-Version: 1.0 (Apple Message framework v1081) Content-Type: text/plain; charset=us-ascii From: Tobias Fredriksson In-Reply-To: Date: Tue, 12 Oct 2010 12:36:20 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: References: <6AE65535-DCCE-46A5-BBB9-358FEB34C18C@gmail.com> To: Torbjorn Kristoffersen X-Mailer: Apple Mail (2.1081) Cc: freebsd-fs@freebsd.org Subject: Re: Growing large UFS over 16TB? X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 12 Oct 2010 10:36:25 -0000 Yes, Unfortunately I can't move the data from UFS to ZFS as I have no other = array available with enough space. System information if that helps FreeBSD stor1.vmlocal.lan 7.0-RELEASE amd64 8GB ram 3ware 9650SE-24M8 12 okt 2010 kl. 12.09 skrev Torbjorn Kristoffersen: > On Mon, Oct 11, 2010 at 10:18 PM, Tobias Fredriksson = wrote: >> Hi, >>=20 >> So I have this UFS, unfortunately it was just done newfs /dev/da1 = with no regards to installing GPT or anything like that. >>=20 >> It started out as a 6x2TB system raid, then we expanded with 2x2TB. >>=20 >> Growing this filesystem was not possible with the current tool = however with the patch from http://masq.tychl.net/growfs.patch it worked = fine. >>=20 >> Now that I'm trying to grow it from 12TB to closer to 20TB it fails = after about 15 minutes. >> It displays all the super-block backups all the way to "39061769312" = then it sits there reading from the volume for about 5-10 minutes. >>=20 >> The following error message is then output >> growfs: rdfs: attempting to read negative block number: Inappropriate = ioctl for device >>=20 >> I understand the reason for this, its trying to read a block and the = integer just wrapped around. Nice. >> The relevant lines from growfs.c are >>=20 >> static void >> rdfs(ufs2_daddr_t bno, size_t size, void *bf, int fsi) >> { >> [...] >> if (bno < 0) { >> err(32, "rdfs: attempting to read negative block = number"); >> } >> [...] >>=20 >> Just for fun I commented the if part out and recompiled. >> growfs: rdfs: read error: -4889807711788704476: Input/output error >>=20 >> The only place that ufs2_daddr_t is defined is in = /usr/include/ufs/ufs/dinode.h >> typedef int64_t ufs2_daddr_t; >>=20 >> So again for fun I changed this to u_int64_t. I also removed the = comments on that if part in growfs.c >>=20 >> This caused the same message as last to be repeated. But not the = negative number. >> growfs: rdfs: read error: -4889807711788704476: Input/output error >>=20 >> This leads me to believe that I'm at least doing something partially = right. >>=20 >> The next part that growfs.c is doing in rdfs is >> n =3D read(fsi, bf, size); >> if (n !=3D (ssize_t)size) { >> err(34, "rdfs: read error: %jd", (intmax_t)bno); >> } >>=20 >> So I changed >> "rdfs(ufs2_daddr_t bno, size_t size, void *bf, int fsi)" >> to >> "rdfs(ufs2_daddr_t bno, size_t size, void *bf, u_int64_t fsi)" >> However this changed nothing. Same output. >> Since its failing out at the if sentance then of course the problem = is in ssize_t not being big enough. >> As such I of course changed the values for this in = /usr/include/machine/_types.h and I also checked out _limit.h in the = same dir. >> _types.h >> typedef __int64_t __ssize_t; >> to >> typedef __uint64_t __ssize_t; >>=20 >> _limit.h >> #define __SSIZE_MAX __LONG_MAX /* max value for a ssize_t */ >> #define __SIZE_T_MAX __ULONG_MAX /* max value for a size_t */ >> to >> #define __SSIZE_MAX __ULLONG_MAX /* max value for a ssize_t = */ >> #define __SIZE_T_MAX __ULLONG_MAX /* max value for a size_t */ >>=20 >> However this failed to make any sort of change. I returned all of the = later values as nothing helped. >>=20 >> So I'm turning to the fs gurus. At the moment I have no way of moving = the data off and creating this properly. As such changing to another fs = is not an option right now neither. >>=20 >> So if anybody has any suggestions on what to do to temporarily fix = the issue until we can move the data of the raid and rebuild it = properly, please let me know. >>=20 >> [root@stor1 /usr/src/sbin/growfs]# ./growfs /dev/da1 >> We strongly recommend you to make a backup before growing the = Filesystem >>=20 >> Did you backup your data (Yes/No) ? Yes >> new file systemsize is: 9765570560 frags >> Warning: 136832 sector(s) cannot be allocated. >> growfs: 19073314.0MB (39062145408 sectors) block size 16384, fragment = size 2048 >> using 103818 cylinder groups of 183.72MB, 11758 blks, 23552 = inodes. >> [...] >> growfs: rdfs: read error: -4889807711788704476: Input/output error >>=20 >=20 > Unfortunately I can't answer your question, but have you considered = using ZFS?