From owner-freebsd-geom@FreeBSD.ORG Mon Apr 26 13:32:08 2010 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 826C9106566B for ; Mon, 26 Apr 2010 13:32:08 +0000 (UTC) (envelope-from lister@kawashti.org) Received: from mra.kawashti.org (mra.kawashti.org [78.136.5.95]) by mx1.freebsd.org (Postfix) with ESMTP id 2087F8FC0A for ; Mon, 26 Apr 2010 13:32:07 +0000 (UTC) Received: from mx.kawashti.org (mx.kawashti.org [196.218.21.179]) (using SSLv3 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mra.kawashti.org (Postfix) with ESMTP id 683584902E4 for ; Mon, 26 Apr 2010 14:32:06 +0100 (BST) Received: from neo ([10.10.10.10]) by mx.kawashti.org (Kawashti Mail) with SMTP id RDS02182 for ; Mon, 26 Apr 2010 15:32:05 +0200 Message-ID: From: "Lister" To: "GEOM" Date: Mon, 26 Apr 2010 15:32:16 +0200 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="windows-1256"; reply-type=original Content-Transfer-Encoding: 8bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.3790.4548 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.3790.4325 Subject: Re: OCE and GPT. No Dice! 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, 26 Apr 2010 13:32:08 -0000 I didn't think 50384895 was in blocks because growfs itself takes -s for input and it's man page has nothing about errors in blocks, or at all! Again, according to dumpfs manpage, and I quote "If -m is specified, a newfs(8) command is printed that can be used to generate a new file system with equivalent settings." newfs takes -s not blocks. Given that, dumpfs has a bug, at least with -m option. Regarding explicit -s with growfs, I did try that (in sectors), and just forgot to mention it. growisofs: I'll look into it shortly; thank you. --- Hatem Kawashti ----- Original Message ----- From: "Andriy Gapon" To: "Lister" Cc: "GEOM" Sent: Monday, April 26, 2010 14:56 Subject: Re: OCE and GPT. No Dice! > on 26/04/2010 13:53 Lister said the following: >> No Dice! That's the result of my experiment which I promised to share >> with you. >> >> Short version: >> ============== >> growfs is just as limited as fdisk and bsdlabel, and apparently dumpfs. >> $ growfs /dev/da0p2 >> growfs: we are not growing (50384895->32089087) >> >> growfs believes the partition is to be shrunk from 50 (24GB) million >> sectors to 32, rather than for 6.4 billion (3,075GB) to 8.4 (4,006GB)! > > Wrong, see below. > >> Any ideas? Other tools? > > Fix growisofs :) > Something to try before that - use explicit -s option. > >> Are there any other FS which are known to be stable under FreeBSD and >> for which there are tools to live-convert a UFS to them? Too far >> fetched, ay? >> >> Long version: it might be interesting: >> =========================== >> To circumvert the 3dm2 not working under 8.0-REL, I disconnected the 2 >> drives comprising the RAID1 from which the system boots, got a 120GB ATA >> from junk, installed 7.1 on it and subsequently 3dm2. >> >> Although this wasn't necessary, I unmounted the 2 FS on /dev/da0 before >> OCE, and also made them noauto in /etc/fstab. >> >> I did the OCE. It took 47 hours to complete. Those were in 3 stages: >> Migration took 34-35:30, Initialization took 7:45-9:15 and Verification >> took 3:45 hours. >> >> Contrary to 3ware's documentation, I found that removing the unit and >> rescanning after OCE has completed were unnecessary. Some how, FreeBSD >> had already been notified of the changed disk size. Evidence: >> $ diskinfo -v /dev/da0 >> /dev/da0 >> 512 # sectorsize >> 4999945912320 # mediasize in bytes (4.5T) >> 9765519360 # mediasize in sectors >> 607875 # Cylinders according to firmware. >> 255 # Heads according to firmware. >> 63 # Sectors according to firmware. >> 9QJ2LCKPA2632A007413 # Disk ident. >> >> Next I used gpart to delete the 2 partitions and destroy the GPT. >> Subsequently I created p1 of the same size as the old one and p2 for all >> the remaining space. Here's the output after having done so: >> $ gpart show da0 >> => 34 9765519293 da0 GPT (4.5T) >> 34 1363148800 1 freebsd-ufs (650G) >> 1363148834 8402370493 2 freebsd-ufs (3.9T) >> >> BTW, I incidentally learned that gpart on 7.1 is different from 8.0. >> Unlike the latter, the former insists to have -b option. Also it insists >> to have -s option even if the partition was the last one. On 8.0, I >> would just use -i and no -b, and no -s for the last partition which >> defaults to using all the remaining space. So, I'll have to modify my >> script– which I wrote for and tested only on 8.0– to include partition >> math. One can't make any assumption about anything! >> >> Then I tried the growfs command as in "Short version." Given the >> unfavorable output, I thought may be I should still remove the unit from >> 3dm2 and rescan afterall. I did that and repeated the growfs, only to >> get the same result. I thought, let's just reboot. Did and retried >> growfs, again for the same. >> Then I thought, may be growfs had been imporved on 8.0-REL; afterall, I >> no longer need 7.1 now that OCE had been done. I booted from 8.0 and >> tried once more, but to no avail. >> >> Before I did the migration, I saved outputs of dumpfs -m, gpart show and >> tunefs -p for reference. >> $ gpart show da0 >> => 34 7812415421 da0 GPT (3.6T) >> 34 1363148800 1 freebsd-ufs (650G) >> 1363148834 6449266621 2 freebsd-ufs (3.0T) >> >> $ dumpfs -m /dev/da0p2 >> newfs -O 2 -U -a 2 -b 65536 -d 65536 -e 8192 -f 65536 -g 16384 -h 64 -m >> 8 -o time -s 50384895 /dev/da0p2 >> I didn't pay attention to this output, then. It turned out to be exactly >> the same after expansion. I couldn't work out where the figure 50384895 >> came from, though. It is not sectors % 2^32, for example. I've read that >> fdisk and bsdlabel have a limit of (2^32 -1) sectors. Neither could I >> find any logic that would make it the same before and after expansion. > > 50384895 is number of filesystem blocks in the filesystem. > filesystem block size is 64K in your case, see 'newfs ...' line above. > > What logic did you find to think that it should not be the same? > >> Note, however that dumpfs and growfs differ in the size after expansion. >> While dumpfs maintained the same number, growfs got a smaller number >> after expansion. > > Your filesystem has not changed, so why would dumpfs report anything different? > >> I hope someone would care to comment on that. > > -- > Andriy Gapon > _______________________________________________ > 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"