OCE and GPT. No Dice!

Mon Apr 26 13:32:08 UTC 2010

I didn't think 50384895 was in blocks because growfs itself takes -s <sectors> 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 <sectors> 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" <avg at icyb.net.ua>
To: "Lister" <lister at kawashti.org>
Cc: "GEOM" <freebsd-geom at freebsd.org>
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 at freebsd.org mailing list
> http://lists.freebsd.org/mailman/listinfo/freebsd-geom
> To unsubscribe, send any mail to "freebsd-geom-unsubscribe at freebsd.org"