Date: Mon, 26 Apr 2010 15:32:16 +0200 From: "Lister" <lister@kawashti.org> To: "GEOM" <freebsd-geom@freebsd.org> Subject: Re: OCE and GPT. No Dice! Message-ID: <B1EDCD53E29D40C4818F67DC50F72BBA@neo>
next in thread | raw e-mail | index | archive | help
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@icyb.net.ua> To: "Lister" <lister@kawashti.org> Cc: "GEOM" <freebsd-geom@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@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-geom > To unsubscribe, send any mail to "freebsd-geom-unsubscribe@freebsd.org"
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?B1EDCD53E29D40C4818F67DC50F72BBA>