Re: GEOM_PART: a quick update on logical partitions

From: Martin <nakal_at_web.de>
Date: Wed, 4 Feb 2009 08:27:18 +0100
Am Tue, 03 Feb 2009 16:30:14 -0800
schrieb Marcel Moolenaar <xcllnt_at_mac.com>:

> > Then, it is quite unusual to insert a new logical partition and copy
> > all entries in the list one place down.
> 
> What do you mean copy?

I try to figure out why you think that the device names will change,
when you simply use the offset in the partition list. When you want to
insert a new partition at the beginning and you already have one at
list offset 0 then you have to copy it one place down to 1. I thought
that you want to offer a special solution for this problem.

> Sure, but you can remove any logical partition in any
> order, which means that subsequent adds can also be
> in any order...

Ok, so when you have logical partition 0, 1 and 2.

/dev/ad0s1.0
/dev/ad0s1.1
/dev/ad0s1.2

you can remove partitions 0 and 1, and you get:

/dev/ad0s1.2

now you can insert 0 again and you get:

/dev/ad0s1.0
/dev/ad0s1.2

You can still use softlinks here. In the last situation you would get
ad0s5 and ad0s7. Do I forget about something?

> Yes, but those will be using the "fixed" names, not the
> softlinks.

I see. But you have to be aware that you create a special case here.
Someone who starts "geli journal ad0s5" won't get "ad0s5.journal".

And is it really a good idea to have the partition block number
for the suffix? Imagine you use gpart or partition magic to move all
partitions 1GB down, for example to enlarge the file system on the first
primary partition. You would need to figure out each logical partition
block number of the extended partition to fix the situation, if you use
geom_eli/geom_journal before mounting. You would have to edit it in
rc.conf for geli devices that appear on boot and fstab for for both,
journal and eli.

When you don't touch the logical layout itself, it shouldn't change the
device names, in my opinion.

-- 
Martin
Received on Wed Feb 04 2009 - 06:27:24 UTC

This archive was generated by hypermail 2.4.0 : Wed May 19 2021 - 11:39:41 UTC