Date: Thu, 22 Apr 2010 23:36:43 +0300 From: Andriy Gapon <avg@icyb.net.ua> To: Lister <lister@kawashti.org> Cc: GEOM <freebsd-geom@freebsd.org> Subject: Re: OCE and GPT Message-ID: <4BD0B35B.2040006@icyb.net.ua> In-Reply-To: <9C9F1EE6F5A24B3695327442FBF565C6@neo> References: <B814515407B5445092FD63116EA3DA6B@neo> <4BCEEA79.7080309@icyb.net.ua><FB409BC0C2654FD78971EDD1A6E17E06@neo> <4BD01DBE.7030905@icyb.net.ua> <9C9F1EE6F5A24B3695327442FBF565C6@neo>
next in thread | previous in thread | raw e-mail | index | archive | help
on 22/04/2010 18:21 Lister said the following: > Hello all, > > I'd like to make a few clarifications first: > 1. All my systems are AMD64 and either 7.1-REL or 8.0-REL. > 2. The GPT on the 5TB RAID5 I want to expand is on 7.1. The latter has > both gpt and gpart. I didn't know about gpart when I built its RAID. > Partition 3 is the last, 3.6TB, 87% full, and is the one desperately > needing expansion. OK. I can't really comment on gpart vs gpt in 7. gpart is what's in head and 8 now and it's evolving. > 3. The GPT on 4TB RAID is on 8.0. I just built it a few days ago for a > project (not my own). Its entire 9 partitions are still empty (just > newfs'd) and for that reason I can use it temporarily for the experiment. > > Certainly, I'll share the results of the expansion experiment with you. > It'll just be a day or so before I get there, as it evidently calls for > a good deal of prep. Fortunately, I wrote a verbose Bash script to > automate the process of creating a GPT, so I don't have to read > everything when I need do it again a few months down the line. It > handles everything from deletion, destruction, creation, newfs, tunefs, > /etc/fstab updates, mounting and 'df' summary display. To customize, > only a few variables need be changed. If anyone thinks this might come > in handy someday, please let me know to post it. You can host on web somewhere and post a link. This way interested parties could discover it and get the latest version of what you decide to share. > Now regarding the hexdump commands, I used them on the 8.0 system for a > reference visual comparision. First here's the output of gpart on that > system: > / :633: gpart show da0 > => 34 7812415421 da0 GPT (3.6T) > 34 41943040 1 freebsd-ufs (20G) > 41943074 188743680 2 freebsd-ufs (90G) > 230686754 62914560 3 freebsd-ufs (30G) > 293601314 4294967296 4 freebsd-ufs (2.0T) > 4588568610 838860800 5 freebsd-ufs (400G) > 5427429410 1111490560 6 freebsd-ufs (530G) > 6538919970 209715200 7 freebsd-ufs (100G) > 6748635170 629145600 8 freebsd-ufs (300G) > 7377780770 434634685 9 freebsd-ufs (207G) > > Here are the commands. Note that I used Bash notations here for easy > immediate recognition. I tested everyone of them before submitting this > message. They do exactly the same as the ones I originally used which > included absolute lengths (in decimal) and offsets (in decimal, > hexadecimal and 'b' for block variations). I've thoroughly tested all > combinations and proved them to achieve same result (which is nothingness.) > > # First 34 sectors of /dev/da0 > hd -n $((512*34)) /dev/da0 [hd output snipped] > ……… edited for brevity > # 34 sectors after the last partition > hd -n $((512*34)) -s $((7377780770+434634685)) /dev/da0 > -> frozen > # First 1 sector after the last partition > hd -n 512 -s $((7377780770+434634685)) /dev/da0 > -> frozen > # Last 1 sector of last partition > hd -n 512 -s $((7377780770+434634685-1)) /dev/da0 > -> frozen > # First 1 sector of last partition > hd -n 512 -s 7377780770 /dev/da0 > -> frozen Could you please try to use dd piped to hd? What you report makes me think that hd doesn't seek disk to a specified offset, but reads and discards data until it reaches the offset. I may be wrong, of course, but it is worth trying dd which is known to do the right thing. > This is interesting: Since 7.1-REL has both gpt and gpart, I did both on > my 5TB array. Here's the output: > / :1134: gpt show da0 > start size index contents > 0 1 PMBR > 1 1 Pri GPT header > 2 32 Pri GPT table > 34 1677721600 1 GPT part - FreeBSD UFS/UFS2 > 1677721634 419430400 2 GPT part - FreeBSD UFS/UFS2 > 2097152034 7668367293 3 GPT part - FreeBSD UFS/UFS2 > 9765519327 32 Sec GPT table > 9765519359 1 Sec GPT header > > / :1135: gpart show da0 > => 34 9765519293 da0 GPT (4.5T) > 34 1677721600 1 freebsd-ufs (800G) > 1677721634 419430400 2 freebsd-ufs (200G) > 2097152034 7668367293 3 freebsd-ufs (3.6T) > > Obviously the output of gpt is more detailed and does reference the 2ry > GPT. It lead me to incidentally learn that the 2ry is one sector > shorter than 1ry on account of absent PMBR. That's kind of obvious (for those who are into reading specification) - PMBR is for software that knows only about MBR and doesn't know about GPT. And MBR, of course, is in the first sector and there is nothing special about the last sector in MBR scheme. > This also leads me suggest to the implementers of gpart to use the > verbosity of gpt. Would you concur? Not sure. I think that gpt is too verbose here, there is not much value in reporting internal GPT structure. Perhaps some educational value, but we already have Wikipedia :-) -- Andriy Gapon
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?4BD0B35B.2040006>