How to safely merge two slices on harddisk?

[Jerry McAllister]

> 
> 
> Malcolm Kay wrote:
> > On Tue, 10 Feb 2004 04:19, Rob wrote:
> > 
> >>Malcolm,
> >>
> >>Thank you for your detailed answer to my question.
> >>
> >>Malcolm Kay wrote:
> >>
> >>>On Mon, 9 Feb 2004 13:46, Rob wrote:
> >>>    Do not change the offset of 'f'. If 'g' does not physically
> >>>    follow 'f' on the disk then this is not going to work -- give up
> >>>    now!!!
> >>
> >>How can I find that out? Is it the slice order in the disk label editor
> >>from /stand/sysinstall :
> > 
> > 
> > No! What you want is disklabel (see man page). On 5.x this seems to
> > have been replaced by bsdlabel -- but I have no experience with 5.x.
> 
> The disklabel output of the disk is:
> 
> -------------------------------------------------------------------------
> # disklabel /dev/ad1s1c:
> [...zip...]
> 8 partitions:
>           size   offset    fstype   [fsize bsize bps/cpg]
>    c:156296322        0    unused        0     0         # (Cyl.    0 - 9728*)
> 
>    a:   204800        0    4.2BSD        0     0     0   # (Cyl.    0 - 12*)
>    e:  6348800   204800    4.2BSD        0     0     0   # (Cyl.   12*- 407*)
>    f:  6348800  6553600    4.2BSD        0     0     0   # (Cyl.  407*- 803*)
>    g:  6348800 12902400    4.2BSD        0     0     0   # (Cyl.  803*- 1198*)
>    h:   614400 19251200    4.2BSD        0     0     0   # (Cyl. 1198*- 1236*)
>    b:   614400 19865600    4.2BSD     2048 16384    91   # (Cyl. 1236*- 1274*)
>    d:135816322 20480000    4.2BSD        0     0     0   # (Cyl. 1274*- 9728*)
> -------------------------------------------------------------------------
> 
> I have put the partitions in a new order, such that the Cyl. counts are
> continuously running up. Am I right, that g physically follows f here?
> If so, that would mean I can merge f and g into one new partition of 6 Gb,
> right?

Do NOT pay any attention to the supposed cylinder counts out on the right.   
They are only comments and probably do not even reflect actual cylinder 
values.   Although it just happens that those cylinder comments work out 
to appear in order, they are very unlikely to designate actual cylinders, 
but rather some form of virtual cylinder count (They may coincidentally 
look in order but are really meaningless - ignore the funny old man 
pulling strings behind the curtain)

The ONLY relevant ordering would be one based on the order of the partitions'
offsets - which, you have listed in ascending order. 

As I mentioned in a long description a day or so ago, the relevant
information is found in the size and offset fields.   They are the ONLY
thing that will tell you if the partitions are adjacent and contiguous.

In this case, since partition f: begins at 6553600 and is 6348800 blocks 
long and partition g: starts at 12902400 which is exactly the f: partition 
offset and size added up, it looks like those two partitions are
adjacent and contiguous.
> 
> I actually wonder if the label editor of /stand/sysinstall can do what
> I want. Since I now know that f and g are back-to-front partitions, I could
> remove them and create a single new one; when I write this to disk, I can
> let sysinstall also create a new filesystem on the newly merged partition.
> 
> I know this is potentially dangerous, but this way I have already
> deleted the swap partition, created a new ufs partition instead and
> created a file system on that; all in sysinstall.
> I believe it is safe, as long as I do not run 'newfs' on the existing
> partitions.

Probably safe, but backup everything anyway.  It is dangerous to bet 
on tinkering with rewriting the label even if the parts you want to save
are kept with the same values.   The label is still completely rewritten.   

In any case, do not use /stand/sysinstall for this.   You need more direct 
control and should use disklabel directly.   As mentioned in my previous 
posting use the command  
                         'disklabel -e -r asd1s1'  
and then edit the tmp file 
it puts up and then write[save] it back.  This is the most directly 
reliable way to do it.   Since the drive is not a boot drive you don't 
need any other switches of flags although you may want to try it onece
with the -n switch just to see what happens without actually writing
anything to the real label.

////jerry

> 
> Or am I missing something important here?
> 

The real value of backing up everything and redoing the whole disk
from scratch.
/jrm

> Thanks,
> Rob.
> 
> 
> 
> _______________________________________________
> freebsd-questions at freebsd.org mailing list
> http://lists.freebsd.org/mailman/listinfo/freebsd-questions
> To unsubscribe, send any mail to "freebsd-questions-unsubscribe at freebsd.org"
>