Subject: Re: VPS mailing list, BSD interest?
To: None <thorpej@nas.nasa.gov>
From: Terry Lambert <terry@lambert.org>
List: tech-kern
Date: 10/01/1996 14:31:09
>  > Actually, I don't think it is.  CCD should be relying on information stored
>  > in a private area of the disk to determine what stripe sets what partitions
>  > belong to, etc.  This is how all of the industrial strength filesystem VM
>  > systems work.  When you open the partition, you see it has a CCD block 
>  > on it, and then pass it on to CCD informing it of the dev that the block
>  > came from.  The upside to this is that you can re-arange your disks (even
>  > put them on different controllers) and the system still finds your array
>  > and makes it work.  Having my root FS on a RAID 5 device makes it
>  > more robust than having it on a single disk. This is more than enough
>  > justification for allowing you to do this.
> 
> Just where do you propose to keep this information?
> 
> (Hint: it's going to be machine-dependent.)
> 
> When you say "open the partition", which partition are you opening?
> 
> (Hint: if you're opening /dev/sd0a, then you have to put all kinds of
> crap to find the "ccd block" in the SCSI disk driver, and the IDE disk
> driver, and the Xylogics disk drivers, and...)
> 
> How does the way the ccd is configured not allow you to move your
> disks around (to different controllers, etc.)?
> 
> (Hint: it doesn't.)


,--------------------------------.
| device consumer (fs, whatever) |
+--------------------------------+
|  logical device stacking layer |
+--------------------------------+
|      real disk driver layer    |
`--------------------------------'

A device exported for consumption by a device consumer has the
exported attribute:

a)	number of blocks

It has the internal attributes of:

a)	start block
b)	block map
c)	virtual container device in stack order
d)	virtual container device in optimization order

('a' and 'b' are interpreted in terms of 'd' for the purpose of the
 in core device record)


For a typical logical device stacking layer we are treating contiguous
block ranges:

,-----------------------.
| DOS partition table   | <-- logical device layer private data
+-----------------------+
| DOS partition 1 start |
           ...            <-- exported logical device
|  DOS partition 1 end  |
+-----------------------+
| DOS partition 2 start |
           ...            <-- exported logical device
|  DOS partition 2 end  |
+-----------------------+
           ...
`-----------------------'

We can consider a DOS partition (partition 1) containing a BSD disklabel:

,-----------------------.
|     BSD disklabel     | <-- logical device layer private data
+-----------------------+
|     slice 'a' start   |
           ...            <-- exported logical device
|      slice 'a' end    |
+-----------------------+
|     slice 'b' start   |
           ...            <-- exported logical device
|      slice 'b' end    |
+-----------------------+
           ...
`-----------------------'

We can consider the same things regarding:

o	volume set membership identifiers
o	DOS extended partitioning
o	disklabels from "foreign" systems
o	SVR4 VTOC

We can also consider a "media perfection layer" as exporting a single
device smaller than the device it overlays, with bad area replacement.



Again, for typical logical devices, the layering collapses:

DOS partitioning overlays physical device and exports partitions
a)	start block	0
b)	block map	none (linear)
c)	VCD (stack)	physical device
d)	VCD (opt.)	physical device

BSD partition is DOS partition 1
a)	start block	64
b)	block map	none (linear)
c)	VCD (stack)	DOS partition 1 logical device
d)	VCD (opt.)	physical device

root device is BSD slice a
a)	start block	78 (64 + 8k)
b)	block map	none (linear)
c)	VCD (stack)	BSD slice 'a' logical device
d)	VCD (opt.)	physical device


In other words, there is no additional stacking overhead after device
instantiation for linearly mapped devices, and no additional overhead
beyond what we would encounter anyway for non-linear devices (like
CCD, LVM, and/or media perfection devices).

Pretty obvious, actually.


					Regards,
					Terry Lambert
					terry@lambert.org
---
Any opinions in this posting are my own and not those of my present
or previous employers.