On Saturday, 23 January 1999 at 7:10:08 +0800, Peter Wemm wrote: > Greg Lehey wrote: >> On Saturday, 23 January 1999 at 6:24:17 +0800, Peter Wemm wrote: >>> Greg Lehey wrote: >>>> On Friday, 22 January 1999 at 9:23:48 -0800, Jake wrote: >>>>> I can no longer bring up my vinum volume with the vinum read >>>>> command: >>>>> >>>>> vinum read /dev/wd0s1e /dev/wd2s1f >>>>> vinum read /dev/wd0s1e >>>>> vinum read /dev/wd2s1f >>>>> >>>>> all come back with >>>>> vinum: no drives >>>> >>>> Correct. As I explained in detail in my HEADS UP message a couple of >>>> days ago, you must now specify drives, not partitions. The correct >>>> command might be >>>> >>>> vinum read /dev/wd0 /dev/wd2 >>> >>> Does vinum scan the slices? What if there are two freebsd slices? >> >> Currently it just scans the compatibility slice. I'll change that >> later. > > What is worrying me was that wd0 is the "whole disk", not a "compatability > slice"... I'm not quite sure how this is dealt with, vinumio.c does a > DIOCGPART into &drive->partinfo.. Is this how it's finding the > compatability slice info? > > As I understand it by looking at the unit numbers in /dev, and the > subr_diskslice code: > > wd0c = whole compat slice (slice 0 = compat slice) > wd0 = whole disk (this is slice 1 == whole disk != compat slice) > wd0s1 == wd0s1c == whole of first slice (this is slice 2 in the major number). > > Now perhaps the DIOCGPART on slice 1 is being translated into the info for > slice 0 (compat slice) but I don't quite see where.
It's much more of a kludge than that. Remember, this is interim code while I look for the right way to do it. I take the name of the disk and append the letters a to h to them (omitting c), and try to open them. >>> If somebody is working on a disk shared with something else (eg: >>> DOS/windoze), then perhaps the examples should be: vinum read >>> /dev/wd0s1 /dev/wd2s1 >> >> Interesting. Yes, I think this would work. >> >> The real problem here is that, as you know from private >> correspondence, I haven't found a good way to determine what >> partitions are on the system, so I go through with brute force and try >> to open each possible partition. This will change when I find a >> better way, but it shouldn't require incompatible changes to the >> command line syntax again. With any luck, I *will* be able to say >> `vinum start', and it will go out and find the partitions by itself. > > Well, we used to have a way, it was the #ifdef SLICE code. It used to > actively probe the devices and went out and found all the disks, slices, > labels etc. It would have been an ideal thing for vinum to hook into as > it could notify vinum "hey, I've just found something that looks like it > belongs to vinum!". When vinum was told about all the components needed > to make up a volume and attached that to the system, the SLICE code would > have probed for disklabels etc inside. You mean Julian's SLICE code, right? Yes, I knew about that, and I'm agreed. But as you say, it's currently not there. I need a solution that works in all configurations. > That would have taken us 99% of the way to booting from a drive > array with a root partition. Maybe. There are a number of issues here, most of them minor but irritating. I haven't looked at it properly yet. Greg -- See complete headers for address, home page and phone numbers finger g...@lemis.com for PGP public key To Unsubscribe: send mail to majord...@freebsd.org with "unsubscribe freebsd-current" in the body of the message
