From owner-freebsd-questions@FreeBSD.ORG Mon Feb 9 08:02:31 2004 Return-Path: Delivered-To: freebsd-questions@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 0BDD416A4D1 for ; Mon, 9 Feb 2004 08:02:31 -0800 (PST) Received: from clunix.cl.msu.edu (clunix.cl.msu.edu [35.9.2.10]) by mx1.FreeBSD.org (Postfix) with ESMTP id 855DC43D1D for ; Mon, 9 Feb 2004 08:02:30 -0800 (PST) (envelope-from jerrymc@clunix.cl.msu.edu) Received: (from jerrymc@localhost) by clunix.cl.msu.edu (8.11.7p1+Sun/8.11.7) id i19G2L201217; Mon, 9 Feb 2004 11:02:22 -0500 (EST) From: Jerry McAllister Message-Id: <200402091602.i19G2L201217@clunix.cl.msu.edu> To: nospam@users.sourceforge.net (Rob) Date: Mon, 9 Feb 2004 11:02:21 -0500 (EST) In-Reply-To: <4026FBA6.8030001@users.sourceforge.net> from "Rob" at Feb 09, 2004 12:16:54 PM X-Mailer: ELM [version 2.5 PL2] MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit cc: freebsd-questions@freebsd.org Subject: Re: How to safely merge two slices on harddisk? X-BeenThere: freebsd-questions@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: User questions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 09 Feb 2004 16:02:31 -0000 > > Hi, > > I have a hard disk, on which I would like to merge two slices > into one single slice. The disk slices are as follows: First, in the df output I see below, there is only one slice showing. That would be slice 1 of the /dev/ad1 disk eg. /dev/ad1s1. Second, it would be more useful in this case to post the output from disklabel because that would show the sector numbers of the two partitions (f and g) that you are talking about merging. Do: disklabel -r ad1s1 NOTE: df shows size estimates after all formatting and system reserves are taken out of the calculation, so it does not show the actual number of blocks that were used in creating the label for the disk. It also does not show unmounted partitions such as a possible swap partition. Here is a sample from one of my disks, (minus stock disk info stuff at the top). Note, where is says '8 partitions' it means you can defince up to 8 partitions, not that 8 partitions have been defined. Also NOTE: The size and offset values are given in 512 Byte blocks. 8 partitions: # size offset fstype [fsize bsize bps/cpg] a: 1048576 0 4.2BSD 1024 8192 22 # (Cyl. 0 - 65*) c: 35551782 0 unused 0 0 # (Cyl. 0 - 2212*) f: 1048576 1048576 4.2BSD 1024 8192 22 # (Cyl. 65*- 130*) g: 6291456 2097152 4.2BSD 2048 16384 89 # (Cyl. 130*- 522*) h: 27163174 8388608 4.2BSD 2048 16384 89 # (Cyl. 522*- 2212*) > /dev/ad1s1a 98M 43M 47M 48% /home/userB > /dev/ad1s1d 64G 45G 14G 77% /home/userA > /dev/ad1s1e 3.0G 2.5G 282M 90% /home/userC > /dev/ad1s1f 3.0G 1.0G 1.7G 37% /usr/ports > /dev/ad1s1g 3.0G 268M 2.5G 10% /mnt > /dev/ad1s1h 295M 295M -23.5M 109% /diskless_swap > > I want to merge /ad1s1f and /ad1s1g into one 6Gb slice. My inclination would be to make a good backup of the partitions that you want to preserve - regardless of what nice tricks you want to use and whether they should be safe. Then, when you have good backups done, the best and easiest thing to do would be to re-partition the whole /dev/ad1s1 slice and then reload from backups. But, once you have the backups, you might be able to just use disklabel to rewrite the label so the sectors in partitions f and g are combined in to a single partition f. The key thing to look for in the disklabel -r ad1s1 output is if the f: and g: partitions are truly adjacent and can be a contiguous single partition. This is probably, but it is possible that they are not. Nothing requires using partition labels in alphabetical order. So, add up the size fields of all the partitions before the ones in question. Presuming the above order and typical usage, that would be a: & d:. If those sizes equal the offset of the f: partition then that part is OK. Then add in the size of the f: partition to the previous total and if that sum equals the offset value of the g: partition reported by disklabel, then you can be sure they are adjacent and contiguous. So, if you are so inclined, you can take a shot at it. But, if the size sums and offsets indicate that these two are not really adjacent, then you are stuck with complately re-labeling the ad1s1 slice. One improbable thing could come up. It is possible that there is some wasted space that was left out between the f: and g: partitions. If this is so, your size sums and offset values should tell you that. If this occurs, you can just roll that in to the combined f: and g: just by adjusting the size of the new f: partition. To try concatenating the two adjacent partitions do: disklabel -e -r ad1s1 (You could try it once first with -n (eg disklabel -e -r -n ad1s1) just to check and see what it would write) disklabel -d -r ad1s1 will put the label info in to a file of the exact format to feed back to disklabel. Then you can just edit it. When you get out of the file with a write/save it will write the label back to the disk. It will use any editor you have designated, but the default is vi. Example: You should see something like (based on wild guesses from your df above - I did not compensate for how much was taken out by newfs making superblocks, system reserves, unmounted partitions, etc, so these are not the real numbers): 8 partitions: # size offset fstype [fsize bsize bps/cpg] a: 200704 0 4.2BSD 1024 8192 22 # (Cyl. 0 - 65*) c: 153896960 0 unused 0 0 # (Cyl. 0 - 2212*) d: 134217728 200704 4.2BSD 2048 16384 89 # (Cyl. 0-2212*) e: 6291456 134418432 4.2BSD 1024 8192 22 # (Cyl. 0-2212*) f: 6291456 140709888 4.2BSD 1024 8192 22 # (Cyl. 65*- 130*) g: 6291456 147001344 4.2BSD 1024 8192 22 # (Cyl. 130*- 522*) h: 604160 153292800 4.2BSD 1024 8192 22 # (Cyl. 522*- 2212*) Basically you just delete the line labeled g: and combine the size in to the line for f: All the other lines would remain the same. Given the above numbers, the new f: line would look like: f: 12582912 140709888 4.2BSD 2048 16384 22 # (Cyl. 65*- 130*) NOTE: since I have left out adjustments for formatting and possible waste at the end, you will see different actual numbers in the disklabel output and you will have to calculate the actual numbers from what you actually see in the "disklabel -r ad1s1" as described above. In addition, there may be a b: partition that does not show up in the df output. The h: partition should not be affected either if the offsets and sizes for all the other partitions are kept the same. You should not have to worry about the things in the line past the fstype (4.2BSD) designation. You most likely want to take the defaults - whatever disklabel puts in there for you. I believe you can even leage it blank. Since you want the other partitions to be unaffected, you should not change it the settings for them. The stuff beyond the # is a comment. After you finish the disklabel, you need to newfs the new f: partition. If you used the defaults for fsize, etc then use the newfs devaults. Just do: newfs /dev/ad1s1f Do not do a newfs for any of the other partitions if you are trying to get away with just combining the f: and g: partitions without redoing the whole disk. But, if you do redo the whole disk and reload from backup, then all partitions (except those designated unused or swap) will have to have newfs run on them. Of course, you will also have to edit your /etc/fstab file to get rid of the mount for the old /dev/ad1s1g since it will no longer exist. You can just comment out the line for now. > > The merging should NOT destroy anything in the slices before > (ad1s1a, d, and e), but destroying the data in the one afer > (ad1s1h) is no problem. I think, but do not know for sure (important caveat), that if you make the a, d and e partitions (and possibly b: swap partition) have the exact same offset and size and that you do NOT run newfs on any of a, d or e, then they should remain untouched. But, make sure you have the backups. Good luck, ////jerry > > Is there a way to do this? What is the safest one? > (without having to backup the whole disk). > > Thanks, > Rob. > > > _______________________________________________ > freebsd-questions@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-questions > To unsubscribe, send any mail to "freebsd-questions-unsubscribe@freebsd.org" >