Date: Sun, 19 Jul 1998 16:14:43 -0400 (EDT) From: Spidey <beaupran@JSP.UMontreal.CA> To: Julian Elischer <julian@whistle.com> Cc: Greg Lehey <grog@lemis.com>, Question=answer <freebsd-questions@FreeBSD.ORG> Subject: Re: Howto: UNUSED data on HD, Melting 2 partitions into 1 Message-ID: <Pine.BSF.3.96.980719150251.29114A-200000@outpost.nada.org> In-Reply-To: <Pine.BSF.3.95.980718111821.17992A-100000@current1.whistle.com>
next in thread | previous in thread | raw e-mail | index | archive | help
This message is in MIME format. The first part should be readable text, while the remaining parts are likely unreadable without MIME-aware tools. Send mail to mime@docserver.cac.washington.edu for more info. --0-185721927-900879283=:29114 Content-Type: TEXT/PLAIN; charset=US-ASCII I include here my disklabel /dev/wd0c output. Enjoy! On Sat, 18 Jul 1998, Julian Elischer wrote: > Sorry for taking so long to get back to you.. No problem! > Some of this should go into the FAQ I think.. Or a tutorial, like "How to maintain FreeBSD's health" or "Getting yourself out of deep s**t" ;) > Greg is both right and wrong.. > It's dangerous and trick, but it can be done.. > > There are some rather extreme shortcuts that can be made.. Or is it throat-cuts? > I have done far worse stuff than this.. > I once shifted the root partition while I was running on it :-) > but it's been a couple of years since it tried this so beware.. > > > firstly terminology.. > I will ALWAYS refer to the partitions defined by block0 (the MBR) as > slices. > I will always refer to the partitions defined in a BSD disklabel as > partitions.. OK i get it. :) > Slices are defined by a table in the MBR. the program 'fdisk' prints out > the contents of this table. (or lets you edit it). There are rows in the > table. Each row is capable of defining a portion of disk. This portion > becomes the slice of that number.. e.g. the first entry in the table > becomes slice 1, the 2nd becomes slice 2 etc. ok. > The position of each slice on the disk is totally independent of the order > in which they appear in the table. So the last entry in the table may > point to the first section of disk and the first may point to a portion of > disk beyond that pointed to by the last. How do I know what-is-what then? > If an entry in the table points > to nothing (i.e. is all zeroes) it is shown as <UNUSED>. any portion of > the disk can be pointed to by 0, 1 ,2 ,3 or 4 entries in the table. it is > usually considered an error to have a block included in 2 or more entries, > but it can be done.. In that case, there is an overlap in the data? > If the 'type' of a slice is '386BSD' then the system will further look > inside that slice to see if there is a 'disklabel' (on block 1 (the second > block) of that slice). If there is, it will read that disklabel and > extract the "partition table" from it. This is similar in concept to the > table I mentioned before. There are 8 rows to the table, each of which > defines a partition. You may leave a row empty in which case it wil not > appear in the disklabel when printed. the first entry in the table defines > partition 'a', the second defines partition 'b', etc. Then there can be only 8 partitions? Does that mean there can be only 8 filesystems? (/ /usr /var swap ...) > One quirk of the present disklabels is that the 'on disk' format of the > disklabels defines those partitions with block numbers relative to the > BEGINNING OF THE DISK, rather than relative to the beginning of the slice > in which the disklabel resides. (in the future this may change) This is > a historical bogosity, which is hidden from you when you look at the > disklabel, by a huge programming kludge.. Another thing to remember is > that by definition the 3rd row of the table (partition 'c') is magic, and > you should always make it equal to the whole slice on which you have the > disklabel. In some cases if this is not so, the system might even correct > it before showing it to you. I try to discourage people from using the 'c' > partiton, because the 'magic' may change some day in which case they would > be screwed.. This is why it is hell to add space at the beginning. (am I right?) > Once again, any block in the slice can be pointed to by 0 , 1, 2 .... 8 > tables. The numbers 1, or 2 being legal. A patch of disk bay be pointed to > by 0 if it is at the end of the slice and beyond the 'c' part. This should > only happen in odd cases. (like there is a bad block out there you want to > avoid). Lost me on this one. This mean that this "patch" (whatever that means) points to 0 table? (which is none?!?) > If a block is not being used in any real partition, it should > still be within the range pointed to by the 'c' part.. This is the '1' > case. The normal case is if it is pointed to by a single 'normal' part, > and of course is also within the range of the 'c' part. This is the '2' > case. Ok, so any normal partition points to its respective abdef... and to c. > Now having said that.. lets look at your questions.. ouf. > On Sat, 18 Jul 1998, Spidey wrote: > > > > First, I must ask another question prior to the others. Could somebody > > explain these outputs of fdisk and df? > > >>>>>>>>>>>>>>prompt>df > > Filesystem 1K-blocks Used Avail Capacity Mounted on > > /dev/wd0s2a 31775 16238 12995 56% / > > /dev/wd0s3 1023856 942944 80912 92% /dos > > /dev/wd0s2f 1132103 989859 51676 95% /usr > > /dev/wd0s2e 29727 24393 2956 89% /var > > procfs 4 4 0 100% /proc > > >>>>>>>>>>>>>>>prompt>fdisk > > ******* Working on device /dev/rwd0 ******* > > parameters extracted from > > in-core disklabel are: > > cylinders=839 heads=128 sectors/track=63 (8064 blks/cyl) > > > > parameters to be used for BIOS calculations are: > > cylinders=839 heads=128 sectors/track=63 (8064 blks/cyl) > > > > Media sector size is 512 > > Warning: BIOS sector numbering starts with sector 1 > > Information from DOS bootblock is: > > The data for partition 1 is: > > <UNUSED> > > The data for partition 2 is: > > sysid 165,(FreeBSD/NetBSD/386BSD) > > start 3072384, size 3690312 (1801 Meg), flag 80 > > beg: cyl 381/ sector 1/ head 0; > > end: cyl 838/ sector 24/ head 80 > > The data for partition 3 is: > > sysid 6,(Primary 'big' DOS (> 32MB)) > > start 8064, size 2048256 (1000 Meg), flag 0 > > beg: cyl 1/ sector 1/ head 0; > > end: cyl 254/ sector 63/ head 127 > > The data for partition 4 is: > > <UNUSED> > > >>>>>>>>>>>>>>>>>>>>>>>>> > > > > Few mysterieies: > > 1) It is said clearly that my FBSD partition is 1801Mb in size. How come > > that the sum of my df numbers is only 1193609Kb (?=1.2Gb)???? I miss > > about 700Mb here!!!! > > you didn't show the disklabel output.. You have defined a BSD slice but we > can't se what you defined the internal structure of that space to be > like.. Let's take a look: 8 partitions: # size offset fstype [fsize bsize bps/cpg] a: 65536 0 4.2BSD 0 0 0 # (Cyl. 0 - 8*) b: 151248 65536 swap # (Cyl. 8*- 26*) c: 3690312 0 unused 0 0 # (Cyl. 0 - 457*) e: 61440 216784 4.2BSD 0 0 0 # (Cyl. 26*- 34*) f: 2334512 278224 4.2BSD 0 0 0 # (Cyl. 34*- 323*) What are the units of "size"? I presume that they are 512 bytes blocks, or I would have 3.6 Gb or HD just for FBSD!!! I have a 3.2 Gb Quantum Fireball HD, BTW. And what is "Cyl." I would presume that its an abbrev for cylinder. . . humm. Cylinder? So here I see that I got my c partition that represents all the space fbsd's taking, if I'm not lost... It's size is +- 1.8 Gb. I understand that: size(a) = 32,768 Kb // this is root size(b) = 75,624 Kb // this is swap size(c) = 1,845,156 Kb // this is the whole slice size(d) = ??? Kb // this is what??? size(e) = 30,720 Kb // this is /var size(f) = 1,167,256 Kb // this is /usr >From what I understand, the d partition is empty, and that's why it's being omitted. So that's my leak of space! I did it! ;) Now I must change the end block of the /usr partition to be 3690312, which is the end of c. If I would have to make an entry in disk label for d, would it look like that:? d: 1077576 2612736 [???} 0 0 # (Cyl. 323*- 457*) BTW, I'm sorry if I'm boring you to death, I'm trying to prove myself that I understand... I consider that part done, and I'm waiting for your approval to proceed. (It looks too simple to be true...:) Next section (we should really consider splitting this mail...) > > 2) Why isn't fdisk giving the size of <UNUSED> partitions? > > fdisk only shows the contents of the table.. > the unused regions of the disk are unused exactly because they are not in > the table.. > You can only discover the unused portions by inspection.. > they are: > sectors 1->8063 (4 MB) Microsoft wastage. > sectors 2056320 -> 3072384 (~500MB) That's the freespace I need to fit with fbsd. > sectors 6762696 -> ??? (possibly 0 MB, as I don't know the number > of sectors in your drive.) Well, taking that it's a 3.2Gb drive, since 1 Gb = 2^10Mb = 2^10 * 2^10 Kb = 1,048,576 Kb = 2,097,152 * 512 bytes, I got 6,710,886 sectors. ??? < 6762696 ????? The last <UNUSED> gotta be very small!?! > There are also sections of the BSD slice that are not pointed to by any > real disklabel entry (at least none that you have mounted.) As you > haven't show the output of disklabel I can't give you exact help, but you > shoud do 'disklabel -e -r /dev/rwd0s2' and add a table entry on the end > that points to the 500MB that you haven't used in that slice. Make sure > you also update the 'number of partitions' entry as well or the new entry > in the table will not be used.. (maybe this is hte mistake you already > made?) As I understood, that's the d: partition... Shouldn't I just fit it after /usr? Could I fit it after /var? (my logs are squeezed in 30Mb...) > > 2.2) Therefore, how can I identify What are these <UNUSED> partitions? I > > know one is 500Mb of free space, but the other???? > > No you are confused.. these are just empty entries in the table. I got it. > > Now back to my reply... Well back to another section of this glorious odyssey!!! > > On Sat, 18 Jul 1998, Greg Lehey wrote: > > > > > On Friday, 17 July 1998 at 8:00:44 -0400, Spidey wrote: > > > > Hi! > > > > > > 1 GB DOS > > > > 500 MB Free > > > > 1750 MB FBSD > > > > > > > > Now I wish to fit in the 500 MB that is before the FBSD. Is it a different > > > > procedure? > > > > > > >From what? > > > > yes it is.. > > first: > do fdisk and disklabel and PRINT THEM OUT > you'll need them to recover if we screw up.. > > TO add space to the FRONT of a FreeBSD slice we need to make use of the > fact that the Partition table entries in a disklabel are **based from > block0 of the DISK**. (remember I mentioned this before?) yes. > This means that no matter where the disklabel is in the disk, it still > refers to the same portions of disk. This is actually bad in all cases > except this single case.. > > what you should do is get the 'fixit' floppy and the boot floppy > from the 'floppies' directory in the distribution. ...downloading... local: floppies/fixit.flp remote: floppies/fixit.flp 200 PORT command successful. 150 Opening BINARY mode data connection for 'floppies/fixit.flp' (1474560 bytes). > Boot from them > (boot from the boot floppy and select the 'fixit' option > and then follow directions.) > > You could also do this from single-user mode but if you get it wrong you > need to be able to fix it :-) > > in either case the procedure is the same > > ########## WARNING.. GROSS HACK!! ############################## > fdisk -u /dev/rwd0 > > edit the LAST table entry (presently <UNUSED>) > give it the following values: > > start: 2056320 > size: 1016064 > ending: 3072383 > type 165 > > this will define a new BSD partition that points to the unused space > below the BSD partition. ok. > but it is LATER in the table so it won't be the default BSD part.. > it will show up after a reboot as /dev/rwd0s4 got that too. > -reboot- in the same way you just did.. > copy the bootblocks and disklabel from the existing BSD partition to the > new one. > dd if=/dev/rwd0s2 of=/dev/rwd0s4 count=16 > this copies the first 8k. you now have a disklabel in that slice. > and becasue the blocks are refered to in ABSOLUTE TERMS the table entries > for the partitions still point to the starts of the partitions in the > other slice. this looks indeed very dangerous... > reboot: (may not be needed but......) > > disklabel -r /dev/rwd0s4 > we should get some valid info but it will probably complain mightily. > > If code has been added to munge the disklabel when we read it from the > other partition (since I tried this last), all the offsets would be wrong > and the 'a' part would start at 0 instead of 500MB in. CHECK IF THIS IS > SO. If so we need to fix the offsets. let me know and we'll ammend the > instructions.. hummmmmmmmm.... uh, this new slice is *before* my original fbsd slice. And that's where the 500Mb comes from? I think I understand... > TRY use the disklabel -e command below and fix the fields mentionned > below, if it won't let you, do the next boot and continue.. this is: disklabel -e /dev/rwd0s4? or: disklabel -e /dev/rwd0s2??? > Up until this point you should still have a running system....... eeek. > Now come the part when we pull the carpet out from under our own feet.. > do fdisk -u /dev/rwd0 > and expand the last part to size 4706376 > and set the type, size and start of the old BSD part to 0 OK... I'm figuring it out... We're transfering the disklabel of wd0s2 to wd0s4... > reboot again. (if it doesn't boot into single user mode, use the fixit > disk/boot disk combo.) = please please please please please please please please please ! > disklabel -er /dev/rwd0s4 > fix the size of the 'c' partition to be... 3690312 sectors + 500Mb? > fix the 'sectors per unit' entry. to be... ? What is that? The size of the slice (?= unit?) > reboot > > THEORETICALLY you should now have a single bsd slice, with the existing > partitions in it with a bunch of free space before them > > use dikslabel -e -r /dev/rwd0s4 > to add a new partition to use the new 500MB space Couldn't I fit it after another partition? > use newfs to put filesystems on both new partitions (teh noew one at teh > front and the new one at the end. Now I'm lost! in my mind I have only 1 new partition, and it's freespace. > add entries in /etc/fstab to use them. again... > IF this fails you can recover by: > booting the fixit way, > doing > fdisk -u /dev/rwd0 > and typing in all the entries that were there before.. ok... > let me know how it goes! Thanks a lot! I will first wait for your reply to come... Spidey --0-185721927-900879283=:29114 Content-Type: TEXT/PLAIN; charset=US-ASCII; name="disklabel.out" Content-Transfer-Encoding: BASE64 Content-ID: <Pine.BSF.3.96.980719161443.29114B@outpost.nada.org> Content-Description: Disklabel /dev/wd0c output IyAvZGV2L3dkMGM6DQp0eXBlOiBFU0RJDQpkaXNrOiB3ZDBzMg0KbGFiZWw6 IA0KZmxhZ3M6DQpieXRlcy9zZWN0b3I6IDUxMg0Kc2VjdG9ycy90cmFjazog NjMNCnRyYWNrcy9jeWxpbmRlcjogMTI4DQpzZWN0b3JzL2N5bGluZGVyOiA4 MDY0DQpjeWxpbmRlcnM6IDQ1Nw0Kc2VjdG9ycy91bml0OiAzNjkwMzEyDQpy cG06IDM2MDANCmludGVybGVhdmU6IDENCnRyYWNrc2tldzogMA0KY3lsaW5k ZXJza2V3OiAwDQpoZWFkc3dpdGNoOiAwCQkjIG1pbGxpc2Vjb25kcw0KdHJh Y2stdG8tdHJhY2sgc2VlazogMAkjIG1pbGxpc2Vjb25kcw0KZHJpdmVkYXRh OiAwIA0KDQo4IHBhcnRpdGlvbnM6DQojICAgICAgICBzaXplICAgb2Zmc2V0 ICAgIGZzdHlwZSAgIFtmc2l6ZSBic2l6ZSBicHMvY3BnXQ0KICBhOiAgICA2 NTUzNiAgICAgICAgMCAgICA0LjJCU0QgICAgICAgIDAgICAgIDAgICAgIDAg CSMgKEN5bC4gICAgMCAtIDgqKQ0KICBiOiAgIDE1MTI0OCAgICA2NTUzNiAg ICAgIHN3YXAgICAgICAgICAgICAgICAgICAgIAkjIChDeWwuICAgIDgqLSAy NiopDQogIGM6ICAzNjkwMzEyICAgICAgICAwICAgIHVudXNlZCAgICAgICAg MCAgICAgMCAgICAgICAJIyAoQ3lsLiAgICAwIC0gNDU3KikNCiAgZTogICAg NjE0NDAgICAyMTY3ODQgICAgNC4yQlNEICAgICAgICAwICAgICAwICAgICAw IAkjIChDeWwuICAgMjYqLSAzNCopDQogIGY6ICAyMzM0NTEyICAgMjc4MjI0 ICAgIDQuMkJTRCAgICAgICAgMCAgICAgMCAgICAgMCAJIyAoQ3lsLiAgIDM0 Ki0gMzIzKikNCg== --0-185721927-900879283=:29114-- To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-questions" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?Pine.BSF.3.96.980719150251.29114A-200000>