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?
* 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 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?
* 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 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?
* 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?
> > 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?
* 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?
* 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?
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?
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?
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. >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; Which is the correct and blessed way to find out. -- 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 (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. I am acquainted with this issue. I actually started it with the subject above. I have been mostly reading the threads. I think you owe me an apology. -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: > > 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 (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)
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. 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: > > 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)
> 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?
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?
* 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, 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?
> 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?
* 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?
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?
* 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?
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 > > > > > > 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?
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 > > > > 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
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 > > 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