Re: how's vinum these days with DEVFS?
On Sunday, 11 March 2001 at 22:26:11 -0800, Alfred Perlstein wrote: * Greg Lehey [EMAIL PROTECTED] [010311 21:20] wrote: On Sunday, 11 March 2001 at 20:39:03 -0800, Alfred Perlstein wrote: * Greg Lehey [EMAIL PROTECTED] [010311 15:21] wrote: On Sunday, 11 March 2001 at 3:27:02 -0800, Alfred Perlstein wrote: Vinum+DEVFS doesn't make the million symlinks that non-devfs vinum does. The only symlinks that the non-devfs version makes are to the drives. Everything else is device nodes. But yes, it doesn't make as many device nodes, and that is a Good Thing. Try using /dev/vinum/vol/raid01 instead of /dev/vinum/raid01 (notice you need the '/vol/' path component) I missed that. This is not correct. The directory /dev/vinum/vol should go away. Er, too late. :) On a devfs system here's what you'll see: ls -lR /dev/vinum/ total 0 crw--- 1 root wheel 91, 0x4001 Feb 22 21:26 Control crw--- 1 root wheel 91, 0x4002 Feb 22 21:26 control crw--- 1 root wheel 91, 0x4000 Feb 22 21:26 controld drwxr-xr-x 2 root wheel 0 Mar 11 03:24 plex drwxr-xr-x 2 root wheel 0 Mar 11 03:24 sd drwxr-xr-x 2 root wheel 0 Mar 11 03:24 vol /dev/vinum/plex: total 0 crw--- 1 root wheel 91, 1 Feb 22 21:26 vinum0.p0 /dev/vinum/sd: total 0 crw--- 1 root wheel 91, 2 Feb 22 21:26 vinum0.p0.s0 crw--- 1 root wheel 91, 0x1002 Feb 22 21:26 vinum0.p0.s1 /dev/vinum/vol: total 0 crw--- 1 root wheel 91, 0 Feb 22 21:26 vinum0 I'd like to keep it this way, it just makes sense. No, that's a gratuitous change. All the docco talks about keeping the volumes in the main directory. That's why people are having trouble. Yes, it looks more uniform, but the objects aren't uniform. Since both you and Poul refused to fix the code I choose how I thought it should be. Can you explain why: Yes, it looks more uniform, but the objects aren't uniform. It just doesn't make sense to me to mix these device nodes in with the control/Control/controld nodes. Understood. But I don't like the very long device names. Also, why not have a /dev/vinum/ctl/ directory for those nodes? I can go along with that. They're almost completely invisible anyway. We could even call it /dev/vinum/.ctl. Greg -- Finger [EMAIL PROTECTED] for PGP public key See complete headers for address and phone numbers To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: how's vinum these days with DEVFS?
On Sun, Mar 11, 2001 at 12:03:34AM -0800, Matthew Jacob wrote:
On Sun, 11 Mar 2001, Greg Lehey wrote:
On Saturday, 10 March 2001 at 17:12:42 -0800, Matt Jacob wrote:
(top of tree within the last day or so):
Things seem *almost* okay, but:
nellie.feral.com root vinum
vinum - stripe -v /dev/da3a /dev/da4a /dev/da5a /dev/da6a /dev/da7a /dev/da8a
/dev/da9a /dev/da10a /dev/da11a /dev/da12a
drive vinumdrive0 device /dev/da3a
snip
Can't get config for plex 0: Invalid argument
and at the console:
WARNING: Driver mistake: repeat make_dev("vinum/control")
Hmm.
Mar 10 17:09:57 nellie /boot/kernel/kernel: vinumioctl: invalid ioctl from
process 682 (vinum): c1384644
This looks like a mismatch between the plex size in the userland and
kernel code. Did you rebuild vinum(8)?
Complete fresh build, top of tree... I'll try again...
I'll sneak in my experience with DEVFS+vinum here as well:
vinum: loaded
vinum: reading configuration from /dev/da3s1f
vinum: updating configuration from /dev/da1s1e
vinum: updating configuration from /dev/da2s1e
vinum: updating configuration from /dev/da0s1e
swapon: adding /dev/da1s1b as swap device
swapon: adding /dev/da2s1b as swap device
Automatic boot in progress...
/dev/da0s1a: FILESYSTEM CLEAN; SKIPPING CHECKS
/dev/da0s1a: clean, 406977 free (1049 frags, 50741 blocks, 0.2% fragmentation)
Can't stat /dev/vinum/raid01: No such file or directory
Can't stat /dev/vinum/raid01: No such file or directory
/dev/vinum/raid01: CAN'T CHECK FILE SYSTEM.
/dev/vinum/raid01: UNEXPECTED INCONSISTENCY; RUN fsck MANUALLY.
This was with a -current from around March 1. (don't think
anything has changed since). Booting a non-DEVFS kernel
passes the fs-check and works as expected.
/Niels Chr.
--
Niels Christian Bank-Pedersen, NCB1-RIPE.
Network Manager, Tele Danmark NET, IP-section.
"Hey, are any of you guys out there actually *using* RFC 2549?"
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message
Re: how's vinum these days with DEVFS?
* Niels Chr. Bank-Pedersen [EMAIL PROTECTED] [010311 02:29] wrote: I'll sneak in my experience with DEVFS+vinum here as well: vinum: loaded vinum: reading configuration from /dev/da3s1f vinum: updating configuration from /dev/da1s1e vinum: updating configuration from /dev/da2s1e vinum: updating configuration from /dev/da0s1e swapon: adding /dev/da1s1b as swap device swapon: adding /dev/da2s1b as swap device Automatic boot in progress... /dev/da0s1a: FILESYSTEM CLEAN; SKIPPING CHECKS /dev/da0s1a: clean, 406977 free (1049 frags, 50741 blocks, 0.2% fragmentation) Can't stat /dev/vinum/raid01: No such file or directory Can't stat /dev/vinum/raid01: No such file or directory /dev/vinum/raid01: CAN'T CHECK FILE SYSTEM. /dev/vinum/raid01: UNEXPECTED INCONSISTENCY; RUN fsck MANUALLY. This was with a -current from around March 1. (don't think anything has changed since). Booting a non-DEVFS kernel passes the fs-check and works as expected. Vinum+DEVFS doesn't make the million symlinks that non-devfs vinum does. Try using /dev/vinum/vol/raid01 instead of /dev/vinum/raid01 (notice you need the '/vol/' path component) -Alfred To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: how's vinum these days with DEVFS?
Alfred Perlstein [EMAIL PROTECTED] writes: Vinum+DEVFS doesn't make the million symlinks that non-devfs vinum does. Why not? make_dev_alias() is cheap and easy to use. DES -- Dag-Erling Smorgrav - [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: how's vinum these days with DEVFS?
* Dag-Erling Smorgrav [EMAIL PROTECTED] [010311 09:02] wrote: Alfred Perlstein [EMAIL PROTECTED] writes: Vinum+DEVFS doesn't make the million symlinks that non-devfs vinum does. Why not? make_dev_alias() is cheap and easy to use. Take a look at the /dev/vinum tree under devfs and non-devfs systems and you'll understand why I wanted to get rid of the symlinks. Basically, I found them to be distasteful and not worth keeping around. To completely emulate the rats' nest of symlinks I would have had to link to outside disks as well, I really didn't want to do that. Lastly make_dev_alias() is undocumented. -- -Alfred Perlstein - [[EMAIL PROTECTED]|[EMAIL PROTECTED]] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: how's vinum these days with DEVFS?
Lastly make_dev_alias() is undocumented. Really? That's a deficiency. It should be. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: how's vinum these days with DEVFS?
On Sun, 11 Mar 2001, Poul-Henning Kamp wrote: In message [EMAIL PROTECTED], Matthew Jacob writes: Lastly make_dev_alias() is undocumented. Right, just like most of the rest of the kernel. Really? That's a deficiency. It should be. Yes, ideally, yes. I'm hacking the man page now.. Feel free to correct the change To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: how's vinum these days with DEVFS?
* Poul-Henning Kamp [EMAIL PROTECTED] [010311 12:02] wrote:
In message [EMAIL PROTECTED], Matthew Jacob
writes:
Lastly make_dev_alias() is undocumented.
Right, just like most of the rest of the kernel.
Really? That's a deficiency. It should be.
Yes, ideally, yes.
The problem with make_dev_alias() not being documented is that it would
have been an effort to figure out if duplicate make_dev_alias() calls
were idempotent, done with refcounts or a good way to panic your
machine.
There's also no destroy_dev_alias() that I can see. So when vinum
goes away I didn't realize how one unpopulates the /dev/vinum/ tree.
What's up with devfs not gc'ing itself? Ie, after a directory
becomes empty it seems to still exist within the devfs namespace
instead of disappearing.
Since you guys are in docco mode, you might as well document how one
detects a devfs system in a running system. There's an example
in the vinum(8) source:
if (sysctlbyname("vfs.devfs.generation", NULL, NULL, NULL, 0) == 0)
devfs_is_active = 1;
else
devfs_is_active = 0;
--
-Alfred Perlstein - [[EMAIL PROTECTED]|[EMAIL PROTECTED]]
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message
Re: how's vinum these days with DEVFS?
On Sun, 11 Mar 2001, Alfred Perlstein wrote:
* Poul-Henning Kamp [EMAIL PROTECTED] [010311 12:02] wrote:
In message [EMAIL PROTECTED], Matthew
Jacob writes:
Lastly make_dev_alias() is undocumented.
Right, just like most of the rest of the kernel.
Really? That's a deficiency. It should be.
Yes, ideally, yes.
I've updated the man page.
The problem with make_dev_alias() not being documented is that it would
have been an effort to figure out if duplicate make_dev_alias() calls
were idempotent, done with refcounts or a good way to panic your
machine.
...I'm not following this. Too many dime or more expensive words! What you at?
There's also no destroy_dev_alias() that I can see. So when vinum
goes away I didn't realize how one unpopulates the /dev/vinum/ tree.
The destroy_dev destroys all aliases.
What's up with devfs not gc'ing itself? Ie, after a directory
becomes empty it seems to still exist within the devfs namespace
instead of disappearing.
Since you guys are in docco mode, you might as well document how one
detects a devfs system in a running system. There's an example
in the vinum(8) source:
if (sysctlbyname("vfs.devfs.generation", NULL, NULL, NULL, 0) == 0)
devfs_is_active = 1;
else
devfs_is_active = 0;
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message
Re: how's vinum these days with DEVFS (second part)
Since you guys are in docco mode, you might as well document how one
detects a devfs system in a running system. There's an example
in the vinum(8) source:
if (sysctlbyname("vfs.devfs.generation", NULL, NULL, NULL, 0) == 0)
devfs_is_active = 1;
else
devfs_is_active = 0;
Why should you care? You should be calling make_dev/make_dev_alias/destroy_dev
whether DEVFS is running or not. Why on earth would you want things to be
different? Is it because you see DEVFS as not offering something you can get
w/o it or what
-matt
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message
Re: how's vinum these days with DEVFS (second part)
Matthew Jacob [EMAIL PROTECTED] writes: Since you guys are in docco mode, you might as well document how one detects a devfs system in a running system. Why should you care? Because if the system doesn't have devfs, the userland vinum code needs to create the device nodes "manually". DES -- Dag-Erling Smorgrav - [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: how's vinum these days with DEVFS (second part)
On 11 Mar 2001, Dag-Erling Smorgrav wrote: Matthew Jacob [EMAIL PROTECTED] writes: Since you guys are in docco mode, you might as well document how one detects a devfs system in a running system. Why should you care? Because if the system doesn't have devfs, the userland vinum code needs to create the device nodes "manually". Hmm. Sounds to me more like an argument for requiring devfs if you use vinum. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: how's vinum these days with DEVFS (second part)
Matthew Jacob [EMAIL PROTECTED] writes: Hmm. Sounds to me more like an argument for requiring devfs if you use vinum. Not until vinum works equally well with devfs as without it. DES -- Dag-Erling Smorgrav - [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: how's vinum these days with DEVFS (second part)
I think I'm assuming that DEVFS will become standard. I really see it working very very well and solving lots of problems. I have yet to really find cases where it really *can't* work (modulo broken drivers). Matthew Jacob [EMAIL PROTECTED] writes: Hmm. Sounds to me more like an argument for requiring devfs if you use vinum. Not until vinum works equally well with devfs as without it. Har har har har har Almost a Catch-22... "We have to do really wierd things so vinum will work equally well without devfs as with it... so we can, then, remove all the wierd things we did to make vinum work equally well without devfs as with it"... I think what you really meant to say was "No, we won't require devfs". To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: how's vinum these days with DEVFS (second part)
Matthew Jacob [EMAIL PROTECTED] writes: Hmm. Sounds to me more like an argument for requiring devfs if you use vinum. Not until vinum works equally well with devfs as without it. Har har har har har Almost a Catch-22... "We have to do really wierd things so vinum will work equally well without devfs as with it... so we can, then, remove all the wierd things we did to make vinum work equally well without devfs as with it"... I think what you really meant to say was "No, we won't require devfs". To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: how's vinum these days with DEVFS (second part)
Matthew Jacob [EMAIL PROTECTED] writes: Matthew Jacob [EMAIL PROTECTED] writes: Hmm. Sounds to me more like an argument for requiring devfs if you use vinum. Not until vinum works equally well with devfs as without it. Har har har har har Please take your sarcasm and shove it. And get acquainted with the issue at hand before joining the discussion. DES -- Dag-Erling Smorgrav - [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: how's vinum these days with DEVFS?
In message [EMAIL PROTECTED], Matthew Jacob writes: Lastly make_dev_alias() is undocumented. Right, just like most of the rest of the kernel. Really? That's a deficiency. It should be. Yes, ideally, yes. -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 [EMAIL PROTECTED] | TCP/IP since RFC 956 FreeBSD committer | BSD since 4.3-tahoe Never attribute to malice what can adequately be explained by incompetence. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: how's vinum these days with DEVFS?
On Sunday, 11 March 2001 at 3:27:02 -0800, Alfred Perlstein wrote: * Niels Chr. Bank-Pedersen [EMAIL PROTECTED] [010311 02:29] wrote: I'll sneak in my experience with DEVFS+vinum here as well: vinum: loaded vinum: reading configuration from /dev/da3s1f vinum: updating configuration from /dev/da1s1e vinum: updating configuration from /dev/da2s1e vinum: updating configuration from /dev/da0s1e swapon: adding /dev/da1s1b as swap device swapon: adding /dev/da2s1b as swap device Automatic boot in progress... /dev/da0s1a: FILESYSTEM CLEAN; SKIPPING CHECKS /dev/da0s1a: clean, 406977 free (1049 frags, 50741 blocks, 0.2% fragmentation) Can't stat /dev/vinum/raid01: No such file or directory Can't stat /dev/vinum/raid01: No such file or directory /dev/vinum/raid01: CAN'T CHECK FILE SYSTEM. /dev/vinum/raid01: UNEXPECTED INCONSISTENCY; RUN fsck MANUALLY. This was with a -current from around March 1. (don't think anything has changed since). Booting a non-DEVFS kernel passes the fs-check and works as expected. Vinum+DEVFS doesn't make the million symlinks that non-devfs vinum does. The only symlinks that the non-devfs version makes are to the drives. Everything else is device nodes. But yes, it doesn't make as many device nodes, and that is a Good Thing. Try using /dev/vinum/vol/raid01 instead of /dev/vinum/raid01 (notice you need the '/vol/' path component) I missed that. This is not correct. The directory /dev/vinum/vol should go away. Greg -- Finger [EMAIL PROTECTED] for PGP public key See complete headers for address and phone numbers To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: how's vinum these days with DEVFS?
* Matthew Jacob [EMAIL PROTECTED] [010311 12:19] wrote: On Sun, 11 Mar 2001, Alfred Perlstein wrote: * Poul-Henning Kamp [EMAIL PROTECTED] [010311 12:02] wrote: In message [EMAIL PROTECTED], Matthew Jacob writes: Lastly make_dev_alias() is undocumented. Right, just like most of the rest of the kernel. Really? That's a deficiency. It should be. Yes, ideally, yes. I've updated the man page. The problem with make_dev_alias() not being documented is that it would have been an effort to figure out if duplicate make_dev_alias() calls were idempotent, done with refcounts or a good way to panic your machine. ...I'm not following this. Too many dime or more expensive words! What you at? There's also no destroy_dev_alias() that I can see. So when vinum goes away I didn't realize how one unpopulates the /dev/vinum/ tree. The destroy_dev destroys all aliases. Yeah... don't really need that. :) In vinum's case there's a directory /dev/vinum/drive that points to the device backing the vinum device: /dev/vinum % ls -lR total 7 brwx-- 1 root wheel 25, 0x4001 Sep 26 1999 Control brwx-- 1 root wheel 25, 0x4002 Sep 26 1999 control brwx-- 1 root wheel 25, 0x4000 Sep 26 1999 controld drwxr-xr-x 2 root wheel 512 Sep 26 1999 drive drwxr-xr-x 2 root wheel 512 Sep 26 1999 plex drwxr-xr-x 2 root wheel 512 Sep 26 1999 rplex drwxr-xr-x 2 root wheel 512 Sep 26 1999 rsd crwxr-xr-- 1 root wheel 91, 0 Sep 26 1999 rvinum0 drwxr-xr-x 2 root wheel 512 Sep 26 1999 rvol drwxr-xr-x 2 root wheel 512 Sep 26 1999 sd brwxr-xr-- 1 root wheel 25, 0 Sep 26 1999 vinum0 drwxr-xr-x 3 root wheel 512 Sep 26 1999 vol ./drive: total 0 lrwxr-xr-x 1 root wheel 9 Sep 26 1999 vinumdrive0 - /dev/da1e lrwxr-xr-x 1 root wheel 11 Sep 26 1999 vinumdrive1 - /dev/da2s1e Ok, now is there a way to get rid of these symlinks when vinum goes away? Ok, if there isn't a way to delete them, what if I unload and reload vinum then try to make them again? -- -Alfred Perlstein - [[EMAIL PROTECTED]|[EMAIL PROTECTED]] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: how's vinum these days with DEVFS?
* Greg Lehey [EMAIL PROTECTED] [010311 15:21] wrote: On Sunday, 11 March 2001 at 3:27:02 -0800, Alfred Perlstein wrote: Vinum+DEVFS doesn't make the million symlinks that non-devfs vinum does. The only symlinks that the non-devfs version makes are to the drives. Everything else is device nodes. But yes, it doesn't make as many device nodes, and that is a Good Thing. Try using /dev/vinum/vol/raid01 instead of /dev/vinum/raid01 (notice you need the '/vol/' path component) I missed that. This is not correct. The directory /dev/vinum/vol should go away. Er, too late. :) On a devfs system here's what you'll see: ~ % ls -lR /dev/vinum/ total 0 crw--- 1 root wheel 91, 0x4001 Feb 22 21:26 Control crw--- 1 root wheel 91, 0x4002 Feb 22 21:26 control crw--- 1 root wheel 91, 0x4000 Feb 22 21:26 controld drwxr-xr-x 2 root wheel 0 Mar 11 03:24 plex drwxr-xr-x 2 root wheel 0 Mar 11 03:24 sd drwxr-xr-x 2 root wheel 0 Mar 11 03:24 vol /dev/vinum/plex: total 0 crw--- 1 root wheel 91, 1 Feb 22 21:26 vinum0.p0 /dev/vinum/sd: total 0 crw--- 1 root wheel 91, 2 Feb 22 21:26 vinum0.p0.s0 crw--- 1 root wheel 91, 0x1002 Feb 22 21:26 vinum0.p0.s1 /dev/vinum/vol: total 0 crw--- 1 root wheel 91, 0 Feb 22 21:26 vinum0 I'd like to keep it this way, it just makes sense. -- -Alfred Perlstein - [[EMAIL PROTECTED]|[EMAIL PROTECTED]] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: how's vinum these days with DEVFS?
Yeah... don't really need that. :) In vinum's case there's a directory /dev/vinum/drive that points to the device backing the vinum device: /dev/vinum % ls -lR total 7 brwx-- 1 root wheel 25, 0x4001 Sep 26 1999 Control brwx-- 1 root wheel 25, 0x4002 Sep 26 1999 control brwx-- 1 root wheel 25, 0x4000 Sep 26 1999 controld drwxr-xr-x 2 root wheel 512 Sep 26 1999 drive drwxr-xr-x 2 root wheel 512 Sep 26 1999 plex drwxr-xr-x 2 root wheel 512 Sep 26 1999 rplex drwxr-xr-x 2 root wheel 512 Sep 26 1999 rsd crwxr-xr-- 1 root wheel 91, 0 Sep 26 1999 rvinum0 drwxr-xr-x 2 root wheel 512 Sep 26 1999 rvol drwxr-xr-x 2 root wheel 512 Sep 26 1999 sd brwxr-xr-- 1 root wheel 25, 0 Sep 26 1999 vinum0 drwxr-xr-x 3 root wheel 512 Sep 26 1999 vol ./drive: total 0 lrwxr-xr-x 1 root wheel 9 Sep 26 1999 vinumdrive0 - /dev/da1e lrwxr-xr-x 1 root wheel 11 Sep 26 1999 vinumdrive1 - /dev/da2s1e Ok, now is there a way to get rid of these symlinks when vinum goes away? Ok, if there isn't a way to delete them, what if I unload and reload vinum then try to make them again? I'm afraid to answer. DES will stay angry. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: how's vinum these days with DEVFS?
* Matthew Jacob [EMAIL PROTECTED] [010311 20:45] wrote: Yeah... don't really need that. :) In vinum's case there's a directory /dev/vinum/drive that points to the device backing the vinum device: /dev/vinum % ls -lR total 7 brwx-- 1 root wheel 25, 0x4001 Sep 26 1999 Control brwx-- 1 root wheel 25, 0x4002 Sep 26 1999 control brwx-- 1 root wheel 25, 0x4000 Sep 26 1999 controld drwxr-xr-x 2 root wheel 512 Sep 26 1999 drive drwxr-xr-x 2 root wheel 512 Sep 26 1999 plex drwxr-xr-x 2 root wheel 512 Sep 26 1999 rplex drwxr-xr-x 2 root wheel 512 Sep 26 1999 rsd crwxr-xr-- 1 root wheel 91, 0 Sep 26 1999 rvinum0 drwxr-xr-x 2 root wheel 512 Sep 26 1999 rvol drwxr-xr-x 2 root wheel 512 Sep 26 1999 sd brwxr-xr-- 1 root wheel 25, 0 Sep 26 1999 vinum0 drwxr-xr-x 3 root wheel 512 Sep 26 1999 vol ./drive: total 0 lrwxr-xr-x 1 root wheel 9 Sep 26 1999 vinumdrive0 - /dev/da1e lrwxr-xr-x 1 root wheel 11 Sep 26 1999 vinumdrive1 - /dev/da2s1e Ok, now is there a way to get rid of these symlinks when vinum goes away? Ok, if there isn't a way to delete them, what if I unload and reload vinum then try to make them again? I'm afraid to answer. DES will stay angry. Well now that was a giant waste of my time, wasn't it. -- -Alfred Perlstein - [[EMAIL PROTECTED]|[EMAIL PROTECTED]] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: how's vinum these days with DEVFS?
On Sun, 11 Mar 2001, Poul-Henning Kamp wrote: In message [EMAIL PROTECTED], Alfred Perlstein writes: What's up with devfs not gc'ing itself? Ie, after a directory becomes empty it seems to still exist within the devfs namespace instead of disappearing. That was a deliberate decision, removing a directory(-inode) which might have a valid vnode is kind of a nasty thing to attempt. Err, "might" ? These things are well defined by VFS interface. -- Boris Popov http://www.butya.kz/~bp/ To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: how's vinum these days with DEVFS?
* Boris Popov [EMAIL PROTECTED] [010311 20:52] wrote: On Sun, 11 Mar 2001, Poul-Henning Kamp wrote: In message [EMAIL PROTECTED], Alfred Perlstein writes: What's up with devfs not gc'ing itself? Ie, after a directory becomes empty it seems to still exist within the devfs namespace instead of disappearing. That was a deliberate decision, removing a directory(-inode) which might have a valid vnode is kind of a nasty thing to attempt. Err, "might" ? These things are well defined by VFS interface. You hand it off to deadfs no? You want to have the same sort of handling that the common FS does when let's say you have two xterms open, one in your homedir and the other in homedir/foo, in the first you rmdir foo and suddenly the second is a bit confused, but it doesn't panic the box... -- -Alfred Perlstein - [[EMAIL PROTECTED]|[EMAIL PROTECTED]] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: how's vinum these days with DEVFS?
On Sunday, 11 March 2001 at 20:39:03 -0800, Alfred Perlstein wrote: * Greg Lehey [EMAIL PROTECTED] [010311 15:21] wrote: On Sunday, 11 March 2001 at 3:27:02 -0800, Alfred Perlstein wrote: Vinum+DEVFS doesn't make the million symlinks that non-devfs vinum does. The only symlinks that the non-devfs version makes are to the drives. Everything else is device nodes. But yes, it doesn't make as many device nodes, and that is a Good Thing. Try using /dev/vinum/vol/raid01 instead of /dev/vinum/raid01 (notice you need the '/vol/' path component) I missed that. This is not correct. The directory /dev/vinum/vol should go away. Er, too late. :) On a devfs system here's what you'll see: ls -lR /dev/vinum/ total 0 crw--- 1 root wheel 91, 0x4001 Feb 22 21:26 Control crw--- 1 root wheel 91, 0x4002 Feb 22 21:26 control crw--- 1 root wheel 91, 0x4000 Feb 22 21:26 controld drwxr-xr-x 2 root wheel 0 Mar 11 03:24 plex drwxr-xr-x 2 root wheel 0 Mar 11 03:24 sd drwxr-xr-x 2 root wheel 0 Mar 11 03:24 vol /dev/vinum/plex: total 0 crw--- 1 root wheel 91, 1 Feb 22 21:26 vinum0.p0 /dev/vinum/sd: total 0 crw--- 1 root wheel 91, 2 Feb 22 21:26 vinum0.p0.s0 crw--- 1 root wheel 91, 0x1002 Feb 22 21:26 vinum0.p0.s1 /dev/vinum/vol: total 0 crw--- 1 root wheel 91, 0 Feb 22 21:26 vinum0 I'd like to keep it this way, it just makes sense. No, that's a gratuitous change. All the docco talks about keeping the volumes in the main directory. That's why people are having trouble. Yes, it looks more uniform, but the objects aren't uniform. Greg -- Finger [EMAIL PROTECTED] for PGP public key See complete headers for address and phone numbers To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: how's vinum these days with DEVFS?
* Greg Lehey [EMAIL PROTECTED] [010311 21:20] wrote: On Sunday, 11 March 2001 at 20:39:03 -0800, Alfred Perlstein wrote: * Greg Lehey [EMAIL PROTECTED] [010311 15:21] wrote: On Sunday, 11 March 2001 at 3:27:02 -0800, Alfred Perlstein wrote: Vinum+DEVFS doesn't make the million symlinks that non-devfs vinum does. The only symlinks that the non-devfs version makes are to the drives. Everything else is device nodes. But yes, it doesn't make as many device nodes, and that is a Good Thing. Try using /dev/vinum/vol/raid01 instead of /dev/vinum/raid01 (notice you need the '/vol/' path component) I missed that. This is not correct. The directory /dev/vinum/vol should go away. Er, too late. :) On a devfs system here's what you'll see: ls -lR /dev/vinum/ total 0 crw--- 1 root wheel 91, 0x4001 Feb 22 21:26 Control crw--- 1 root wheel 91, 0x4002 Feb 22 21:26 control crw--- 1 root wheel 91, 0x4000 Feb 22 21:26 controld drwxr-xr-x 2 root wheel 0 Mar 11 03:24 plex drwxr-xr-x 2 root wheel 0 Mar 11 03:24 sd drwxr-xr-x 2 root wheel 0 Mar 11 03:24 vol /dev/vinum/plex: total 0 crw--- 1 root wheel 91, 1 Feb 22 21:26 vinum0.p0 /dev/vinum/sd: total 0 crw--- 1 root wheel 91, 2 Feb 22 21:26 vinum0.p0.s0 crw--- 1 root wheel 91, 0x1002 Feb 22 21:26 vinum0.p0.s1 /dev/vinum/vol: total 0 crw--- 1 root wheel 91, 0 Feb 22 21:26 vinum0 I'd like to keep it this way, it just makes sense. No, that's a gratuitous change. All the docco talks about keeping the volumes in the main directory. That's why people are having trouble. Yes, it looks more uniform, but the objects aren't uniform. Since both you and Poul refused to fix the code I choose how I thought it should be. Can you explain why: Yes, it looks more uniform, but the objects aren't uniform. It just doesn't make sense to me to mix these device nodes in with the control/Control/controld nodes. Also, why not have a /dev/vinum/ctl/ directory for those nodes? -- -Alfred Perlstein - [[EMAIL PROTECTED]|[EMAIL PROTECTED]] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: how's vinum these days with DEVFS?
On Saturday, 10 March 2001 at 17:12:42 -0800, Matt Jacob wrote:
(top of tree within the last day or so):
Things seem *almost* okay, but:
nellie.feral.com root vinum
vinum - stripe -v /dev/da3a /dev/da4a /dev/da5a /dev/da6a /dev/da7a /dev/da8a
/dev/da9a /dev/da10a /dev/da11a /dev/da12a
drive vinumdrive0 device /dev/da3a
snip
Can't get config for plex 0: Invalid argument
and at the console:
WARNING: Driver mistake: repeat make_dev("vinum/control")
Hmm.
Mar 10 17:09:57 nellie /boot/kernel/kernel: vinumioctl: invalid ioctl from process
682 (vinum): c1384644
This looks like a mismatch between the plex size in the userland and
kernel code. Did you rebuild vinum(8)?
Greg
--
Finger [EMAIL PROTECTED] for PGP public key
See complete headers for address and phone numbers
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message
Re: how's vinum these days with DEVFS?
On Sun, 11 Mar 2001, Greg Lehey wrote:
On Saturday, 10 March 2001 at 17:12:42 -0800, Matt Jacob wrote:
(top of tree within the last day or so):
Things seem *almost* okay, but:
nellie.feral.com root vinum
vinum - stripe -v /dev/da3a /dev/da4a /dev/da5a /dev/da6a /dev/da7a /dev/da8a
/dev/da9a /dev/da10a /dev/da11a /dev/da12a
drive vinumdrive0 device /dev/da3a
snip
Can't get config for plex 0: Invalid argument
and at the console:
WARNING: Driver mistake: repeat make_dev("vinum/control")
Hmm.
Mar 10 17:09:57 nellie /boot/kernel/kernel: vinumioctl: invalid ioctl from process
682 (vinum): c1384644
This looks like a mismatch between the plex size in the userland and
kernel code. Did you rebuild vinum(8)?
Complete fresh build, top of tree... I'll try again...
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message
