OCE and GPT. No Dice!

[Andriy Gapon]

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