Date: Wed, 29 Nov 1995 18:04:52 -0700 (MST) From: Terry Lambert <terry@lambert.org> To: scrappy@hub.org (Marc G. Fournier) Cc: current@FreeBSD.org, hackers@FreeBSD.org Subject: Re: Concatenated Drives ... Message-ID: <199511300104.SAA29251@phaeton.artisoft.com> In-Reply-To: <Pine.BSF.3.91.951129180209.175F-100000@hub.org> from "Marc G. Fournier" at Nov 29, 95 06:04:44 pm
next in thread | previous in thread | raw e-mail | index | archive | help
> I've seen some discussions go by dealing with the > ability to make multiple drives look like one big drive, and I'm > curious as to what is involved in doing so? > > Mainly, isn't that what the swap devices are doing already? > Or is there something extra that needs to be added when combining > several drives into one virtual drive? Ideally (not-so-ideally follows), using devfs: 1) Allow a block device driver to specify offset + size relative to another driver. 2) Allow drivers to be stacked so that one logical drive can be a fragment of another. 3) Support creation of logical devices exported to the user via the devfs /dev name space. 4) Create a driver that exports a device given a tag mechanism on a drive for recognition. So you have: PHY: wdc0 target 0 start = 0 | size = <size of drive> | pdev = /dev/dsk/wdc0 | name = /dev/dsk/wdc0/d0 v LOG: OnTrack 6.x start =64 | size = <size of drive> - 64 | pdev = /dev/dsk/wdc0/d0 | name = /dev/dsk/wdc0/d0 <replaces> v LOG: DOS partitioning start = 64 + <Partiton 1 start> | size = <Partition 1 size> | pdev = /dev/dsk/wdc0/d0 | name = /dev/dsk/wdc0/d0/p1 | start = 64 + <Partiton 2 start> | size = <Partition 2 size> | pdev = /dev/dsk/wdc0/d0 | name = /dev/dsk/wdc0/d0/p2 | start = 64 + <Partiton 3 start> | size = <Partition 3 size> | pdev = /dev/dsk/wdc0/d0 | name = /dev/dsk/wdc0/d0/p3 | start = 64 + <Partiton 4 start> | size = <Partition 4 size> | pdev = /dev/dsk/wdc0/d0 | name = /dev/dsk/wdc0/d0/p4 V LOG: Extended partitoning, if any | V LOG: Concatentation driver start = 0 size = <Adjusted size> pdev = /dev/dsk/ccd name = /dev/dsk/ccd/d0 Concatenation driver, operation: <Adjusted partition 1 size> = <Partition 1 size> - <CCD header size> <Adjusted partition 3 size> = <Partition 3 size> - <CCD header size> <Adjusted size> = <Adjusted partition 1 size> + <Adjusted partition 3 size> if <sector> > <Adjusted size> [fail operation] if <sector> < <Adjusted partition 1 size> <real sector> = <sector> + 64 + <Partition 1 start> else <real sector> = <sector> + 64 + <Partition 3 start> <CD header> :== <Which CCD drive number of which this device is a member> <Member lexical order> <Total number of members in volume span set> Obviously, you can stick in media perfection at any layer, just like you put in OnTrack management. Also Obviously, DOS partitioning, OpenFirmware partitioning, DOS extended partitioning, BSD disk slices, OSF disk slices, and Sun disk slices, etc., are all memebrs of the same class of driver and can be layered freely. A device that overlays a device that does not change sector ordering (ie: does not do bad sector replacement, etc.) can be collapsed to a single start/offset reference, making the code no more overhead than the current partition handling, and less overhead than the disk-slice-on-DOS-partition handling. Graphs containing removable media are not collapsed down, only up. The full theory of operation is: You register all physical devices. For each unclaimed logical or physical device in the system, you ask each logical driver to claim the device. A CCD (really, a "volume spanning driver") will only claim logical devices when the full set is present. You repeat this until no more logical devices are added, and no more are claimed (this last is because you might have a volume spanning driver layered on another, such as two or more stripe sets, which would delay the claiming of the final device by N+1 for each logical device that consisted of multiple logical or phsical devices). For each file system is asked to claim each logical device. Claimed devices are considered "mounted". Not-so-ideally: For the current code set, which can't support this, you can write a CCD driver (or port NetBSD's) with little effort. It operates by making a block major/minor dev that refers to multiple physical volume vnodes, and referencing the device vnodes (which it vn_open's internally). It does not protect against access to the underlying file systems. Regards, Terry Lambert terry@lambert.org --- Any opinions in this posting are my own and not those of my present or previous employers.
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199511300104.SAA29251>