On Friday, 10 October 2003 at 17:00:33 +1000, matthew green wrote:
>
>> What's the deal with putting Vinum-specific hacks into generic FFS
>> support code?
>
> It's not really Vinum-specific. It applies to any file system where
> the name doesn't include information about partitioning. But yes, it
> *is* a hack. Arguably, so are partition encodings in the device name.
> I'm open to discussion on a better way of doing it.
>
> see the raw partition.
Hmm, that doesn't help much.
> On Friday, 10 October 2003 at 16:23:31 +1000, matthew green wrote:
>>
>> what's this all about? this sounds like a strange option to me
>> and i don't recall it being discussed anywhere...
>>
>> how is it different to using `sysctl kern.rawpartition`?
>
> Good question. Where do I find the docco for kern.rawpartition?
>
> try sysctl(8)?
Yes, before writing that. It says:
kern.rawpartition integer no
That doesn't exactly say what it's good for. Setting it as root
doesn't help much either:
# sysctl -w kern.rawpartition=1
kern.rawpartition: sysctl() failed with Operation not permitted
> In any case, the intention here is to stop newfs from looking at the
> last letter of the device name and saying "Ah, that must be partition
> x. But we don't have that many partitions". If there's a nicer way
> of doing it, I'm all for it. In FreeBSD it became superfluous during
> the transition to GEOM.
>
> BTW, this applies to fsck as well, and I haven't committed that code
> yet. I'm holding off pending the outcome of this discussion.
>
> i'm almost certainly you just need to document that people should
> run newfs on the raw partition, but i haven't looked at the code at
> all.
That's probably the problem. A Vinum drive (partition) contains a
quantity of metadata and chunks of a potentially large number of
volumes. If you run newfs on the drive, you'll completely stuff up
the drive. You need to run newfs on the volumes, which could have
their data spread all over the place.
The issue here is that Vinum creates volumes with arbitrary names in
the directory /dev/vinum. You might have, for example,
brwxr-xr-- 1 root wheel 25, 2 Oct 10 17:04 bah
brwxr-xr-- 1 root wheel 25, 3 Oct 10 17:04 baz
brwxr-xr-- 1 root wheel 25, 0 Oct 10 17:04 first
brwxr-xr-- 1 root wheel 25, 1 Oct 10 17:04 foo
brwxr-xr-- 1 root wheel 25, 4 Oct 10 17:04 foo1
If you try to newfs these volumes, you'll get:
# for i in bah baz foo foo1 foo; do echo $i; newfs /dev/vinum/$i; done
bah
newfs: `h' partition is unavailable
baz
newfs: can't figure out file system partition
foo
newfs: `o' partition is unavailable
foo1
/dev/vinum/foo1: 100.0MB (204800 sectors) block size 8192, fragment size 1024
using 4 cylinder groups of 25.00MB, 3200 blks, 6144 inodes.
super-block backups (for fsck -b #) at:
32, 51232, 102432, 153632,
The -V flag tells newfs not to make assumptions about the device name.
Greg
--
See complete headers for address and phone numbers.
Attachment:
pgpuZFGKgSAGJ.pgp
Description: PGP signature