OCE and GPT. No Dice!

[Lister]

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)!

Any ideas? Other tools?
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.
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.
I hope someone would care to comment on that.
---
Hatem Kawashti