Re: System crash on vinum start
At 03:14 PM 9/28/99 +0930, Greg Lehey wrote: And the preferred method is... a) /dev/da0 b) /dev/da0s1 c) /dev/da0s1e (-current and -stable I hope :) (b) or (c). (a) isn't a slice. Note that it won't take slice c, either. Thanks for the clarification. Was recalling a past dicussion on how Vinum determined what belonged to it . Not using "c" is just plain common sense. It's surprising. Good software shouldn't panic. But this input is valuable, because now I know where to look. Should have spoken up quite a while back. Figured it was pilot error and the panic was a self-inflicted gunshot wound. Read http://www.lemis.com/vinum/how-to-debug.html. It's also in vinum(4). Again? ;) May try some old pilot errors and see if I can panic it. Just need to recall what I was doing, since it happened when (almost) trying to break things. Forgot to mention that software should not panic, but if you are doing something wrong... Goes back to recent mention of sanity checking. You don't want to use vinum read. Just vinum start. And I've found the bug (thanks, Brad). I'll be committing a fix Real Soon Now. So then if only the module is loaded and rc does nothing further then doing a 'vinum read ...' is a Bad Thing. Use 'start' myself, but just to clarify for others. It's still in the pipeline. I can't give any time frame. There are some bugs I need to look at (http://www.lemis.com/vinum/bugs.html), and then I can start thinking about it. Perhaps I should have been more specific, but from what I understand there are some issues with the boot process (space limitations?) and possibly requiring other changes of a more significant nature beyond that, which you were waiting for to come about first. Jeff Mountin - [EMAIL PROTECTED] Systems/Network Administrator FreeBSD - the power to serve '86 Yamaha MaxiumX (not FBSD powered) To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: System crash on vinum start
On Fri, Oct 01, 1999 at 09:20:53AM +1000, Jeffrey J. Mountin wrote: At 12:59 PM 9/28/99 +1000, Peter Jeremy wrote: On Tue, Sep 28, 1999 at 09:11:31AM +1000, Greg Lehey wrote: Good software shouldn't panic. I wish _I_ could convince some people of this :-(. It can be difficult to consider what a user can do and tends to bloat the code a bit. Frustrates my instructors, since it very much a habit when I script and carried over to C. 8-) I was thinking of some `production' code (written by a sister company) that I used to provide customer support for. It would regularly core dump (but was automatically restarted). After a few years they did manage to fix the core dump, but that exposed a memory leak which they never did manage to fix (fairly embarrasing in a supposedly permanently running process). Speaking of, why is (would) root filesystem support necessary for non root/swap automagical recovery. I gather that root support is the most-asked-for feature in Vinum (when I asked Greg about it some weeks ago, I got about as far as `when will Vinum' before he answered me). As long as recovery works, making it nicer to use is (should be) a lower priority. Peter -- Peter Jeremy (VK2PJ)[EMAIL PROTECTED] Alcatel Australia Limited 41 Mandible St Phone: +61 2 9690 5019 ALEXANDRIA NSW 2015 Fax: +61 2 9690 5982 To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: System crash on vinum start
At 09:44 AM 10/1/99 +1000, Peter Jeremy wrote: I was thinking of some `production' code (written by a sister company) that I used to provide customer support for. It would regularly core dump (but was automatically restarted). After a few years they did manage to fix the core dump, but that exposed a memory leak which they never did manage to fix (fairly embarrasing in a supposedly permanently running process). Eeew! Can see your point. Tracking down a sig11 problem in a custom program right now. Seems to be OS related, but think a bit of work around the problem code is in order first. Oh, the pain of learning. My first project fixing another's code. Or at least trying. At least it doesn't harm functionality, so has been bugging me for a while and decided enough is enough. I gather that root support is the most-asked-for feature in Vinum (when I asked Greg about it some weeks ago, I got about as far as `when will Vinum' before he answered me). As long as recovery works, making it nicer to use is (should be) a lower priority. This was more directed torwards Greg, but would guess that auto-recovery would be fairly requested. Growing plexes (any type) would be #1 on my list, auto-recovery #2, and root #3. Best not to bother him about desired features. Would be nice for a work status/todo list, but then *that* has to be updated. And yet might reduce questions of the "when will" type. Rather like the problem page he added. Otherwise should just stop here now. duck n cover "Is it done yet? Is it done yet?" 8-0 Jeff Mountin - [EMAIL PROTECTED] Systems/Network Administrator FreeBSD - the power to serve '86 Yamaha MaxiumX (not FBSD powered) To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: System crash on vinum start
On Thursday, 30 September 1999 at 18:20:53 -0500, Jeffrey J. Mountin wrote: At 12:59 PM 9/28/99 +1000, Peter Jeremy wrote: On Tue, Sep 28, 1999 at 09:11:31AM +1000, Greg Lehey wrote: Good software shouldn't panic. I wish _I_ could convince some people of this :-(. It can be difficult to consider what a user can do and tends to bloat the code a bit. Frustrates my instructors, since it very much a habit when I script and carried over to C. 8-) It's all in the pipeline. But first we need Vinum on the root file system. And whilst we're discussing wish-lists... After several fights with Digital/Compaq's Logical Storage Manager, it would be _very_ nice if recovery could be done at the physical disk level (ie, "I've just replaced da3 - autorecover all vinum volumes that used that disk"), rather than having to recover each logical volume. It would also be nice if you could recover mirrored root/swap without needing to unmirror and re-mirror them. Haven't looked at the code for it, but "hotspare" appeared for the drive configuration recently. Bit a tease really. No offense to Greg of course. ;) This is -CURRENT. Expect work in progress. From the commit log: replaceobject: Add preliminary code. This is not yet complete. Add keyword 'hotspare'. Speaking of, why is (would) root filesystem support necessary for non root/swap automagical recovery. Or will this be part of other to-be-implemented functionalities. I'm not sure I understand the question. But if I parse it correctly, the answer is "no". Greg -- See complete headers for address, home page and phone numbers finger [EMAIL PROTECTED] for PGP public key To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: System crash on vinum start
At 10:19 AM 10/1/99 +0930, Greg Lehey wrote: This is -CURRENT. Expect work in progress. From the commit log: replaceobject: Add preliminary code. This is not yet complete. Add keyword 'hotspare'. Yessir. Read -current, track commits, eat my veggies, get a bit of sun every other week, but am not running -current (for now). Willing to test before MFC, however. Speaking of, why is (would) root filesystem support necessary for non root/swap automagical recovery. Or will this be part of other to-be-implemented functionalities. I'm not sure I understand the question. But if I parse it correctly, the answer is "no". If you parsed as "auto-recovery || root support", then "Yes, great!" Thanks, Jeff Mountin - [EMAIL PROTECTED] Systems/Network Administrator FreeBSD - the power to serve '86 Yamaha MaxiumX (not FBSD powered) To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: System crash on vinum start
On Thursday, 30 September 1999 at 19:37:23 -0500, Jeffrey J. Mountin wrote: At 09:44 AM 10/1/99 +1000, Peter Jeremy wrote: I was thinking of some `production' code (written by a sister company) that I used to provide customer support for. It would regularly core dump (but was automatically restarted). After a few years they did manage to fix the core dump, but that exposed a memory leak which they never did manage to fix (fairly embarrasing in a supposedly permanently running process). Eeew! Can see your point. Tracking down a sig11 problem in a custom program right now. Seems to be OS related, but think a bit of work around the problem code is in order first. Oh, the pain of learning. My first project fixing another's code. Or at least trying. At least it doesn't harm functionality, so has been bugging me for a while and decided enough is enough. I gather that root support is the most-asked-for feature in Vinum (when I asked Greg about it some weeks ago, I got about as far as `when will Vinum' before he answered me). As long as recovery works, making it nicer to use is (should be) a lower priority. This was more directed torwards Greg, but would guess that auto-recovery would be fairly requested. Growing plexes (any type) would be #1 on my list, auto-recovery #2, and root #3. You're not typical. But you *can* grow concatenated plexes. You just can't expand UFS to use the space. That's not a Vinum issue, but somebody's working on it. Best not to bother him about desired features. Would be nice for a work status/todo list, but then *that* has to be updated. And yet might reduce questions of the "when will" type. Rather like the problem page he added. That's a good idea, I suppose. I'll do that. Done: http://www.lemis.com/vinum/wishlist.html. Greg -- See complete headers for address, home page and phone numbers finger [EMAIL PROTECTED] for PGP public key To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: System crash on vinum start
At 10:57 AM 10/1/99 +0930, Greg Lehey wrote: You're not typical. But you *can* grow concatenated plexes. You just can't expand UFS to use the space. That's not a Vinum issue, but somebody's working on it. Yes, I realized that and donned a pointy hat. Root (/) and OS specific files are of interest, but not as critical to me. There are other allowance one can make for redundancy. Beyond the scope of this discussion. That's a good idea, I suppose. I'll do that. Done: http://www.lemis.com/vinum/wishlist.html. Excellent! As for the root issue, #3 looks the most feasible, IMHO, and should eliminate the problems of #2 if the kernel's fs dies (unless it could try another drive) and yet would there not be an issue should the drive that does the bootstrapping die and the system rebooted. Small thing, not Vinum related, but at least things would keep going when a mirrored root fs lost a plex. The "snapshot" feature is interesting as well. Guess the logging changes is not a wish (yet) and is somewhat similar. Thanks, Jeff Mountin - [EMAIL PROTECTED] Systems/Network Administrator FreeBSD - the power to serve '86 Yamaha MaxiumX (not FBSD powered) To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: System crash on vinum start
On Thursday, 30 September 1999 at 20:54:39 -0500, Jeffrey J. Mountin wrote: At 10:57 AM 10/1/99 +0930, Greg Lehey wrote: You're not typical. But you *can* grow concatenated plexes. You just can't expand UFS to use the space. That's not a Vinum issue, but somebody's working on it. Yes, I realized that and donned a pointy hat. Root (/) and OS specific files are of interest, but not as critical to me. There are other allowance one can make for redundancy. Beyond the scope of this discussion. That's a good idea, I suppose. I'll do that. Done: http://www.lemis.com/vinum/wishlist.html. Excellent! As for the root issue, #3 looks the most feasible, IMHO, and should eliminate the problems of #2 if the kernel's fs dies (unless it could try another drive) and yet would there not be an issue should the drive that does the bootstrapping die and the system rebooted. Once we've loaded the kernel, we don't need it again. You can delete the kernel on a running system without any problem. Greg -- See complete headers for address, home page and phone numbers finger [EMAIL PROTECTED] for PGP public key To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: System crash on vinum start
On Monday, 27 September 1999 at 13:05:35 -0400, Brad Chisholm wrote: I'm having a problem where the "vinum start" command crashes my system. This happens regardless of whether it's being issued during bootup via /etc/rc or from the command line on a running system. Interestingly, however, if I issue the start command from the vinum interactive prompt, it works properly with no crash. I'm currently running on a snap built this morning (0924), but it was also happening on a snap from 0914. Crash info, vinum config, and disk info are below. Let me know if I can provide any additional information. Yes. Please read the instructions in vinum(4) about debugging panic dumps. I found a minor bug in 'vinum start' recently, but I doubt it's causing your problem. I'll commit it Real Soon Now. Well, I believe I discovered the source of my problem. It turns out that I did not have the correct devices configured in /dev for the component drives. I had da[0-3]e, but not da[0-3]s1e. The documentation seemed to indicate that the da?s1? devices were not required, but once I made them, the crashes stopped. Thanks. This was the clue that helped me find the bug. It's fixed in 3.3-STABLE now. Greg -- See complete headers for address, home page and phone numbers finger [EMAIL PROTECTED] for PGP public key To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: System crash on vinum start
On Tue, Sep 28, 1999 at 09:11:31AM +1000, Greg Lehey wrote: Good software shouldn't panic. I wish _I_ could convince some people of this :-(. Most certainly is. Could use the functionality to add to a plex's size for striped or RAID5, but a bit of planning cures that. 8-) It's all in the pipeline. But first we need Vinum on the root file system. And whilst we're discussing wish-lists... After several fights with Digital/Compaq's Logical Storage Manager, it would be _very_ nice if recovery could be done at the physical disk level (ie, "I've just replaced da3 - autorecover all vinum volumes that used that disk"), rather than having to recover each logical volume. It would also be nice if you could recover mirrored root/swap without needing to unmirror and re-mirror them. Hummm.. this may seem like a really stange question, but I'll throw it out anyway: Would $9,000 paid to a developer here with immediate time avaliable bring FreeBSD 3.x to a state of being able to replace our current use of hardware raid to do Raid-1 mirroring with hot swap automagic rebuild capabilities? (It would need to be production quality code for very serious business, and completed in 3 weeks time.) Serious responses only please. -- Rod Grimes - KD7CAX - (RWG25)[EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: System crash on vinum start
As Rodney W. Grimes wrote ... On Tue, Sep 28, 1999 at 09:11:31AM +1000, Greg Lehey wrote: Good software shouldn't panic. I wish _I_ could convince some people of this :-(. rather than having to recover each logical volume. It would also be nice if you could recover mirrored root/swap without needing to unmirror and re-mirror them. Hummm.. this may seem like a really stange question, but I'll throw it out anyway: Would $9,000 paid to a developer here with immediate time avaliable bring FreeBSD 3.x to a state of being able to replace our current use of hardware raid to do Raid-1 mirroring with hot swap automagic rebuild capabilities? (It would need to be production quality code for very serious business, and completed in 3 weeks time.) Serious responses only please. Rod, Being in the hardware RAID business myself I cannot help asking: why do you want to loose the hardware RAID in favor of a software solution? Flexibility (just guessing) or price maybe? Wilko -- | / o / / _ Arnhem, The Netherlands- Powered by FreeBSD - |/|/ / / /( (_) BulteWWW : http://www.tcja.nl http://www.freebsd.org To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: System crash on vinum start
As Rodney W. Grimes wrote ... On Tue, Sep 28, 1999 at 09:11:31AM +1000, Greg Lehey wrote: Good software shouldn't panic. I wish _I_ could convince some people of this :-(. rather than having to recover each logical volume. It would also be nice if you could recover mirrored root/swap without needing to unmirror and re-mirror them. Hummm.. this may seem like a really stange question, but I'll throw it out anyway: Would $9,000 paid to a developer here with immediate time avaliable bring FreeBSD 3.x to a state of being able to replace our current use of hardware raid to do Raid-1 mirroring with hot swap automagic rebuild capabilities? (It would need to be production quality code for very serious business, and completed in 3 weeks time.) Serious responses only please. Rod, Being in the hardware RAID business myself I cannot help asking: why do you want to loose the hardware RAID in favor of a software solution? Flexibility (just guessing) or price maybe? Because DPT has screwed this customer over for the last time... -- Rod Grimes - KD7CAX - (RWG25)[EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: System crash on vinum start
At 01:05 PM 9/27/99 -0400, Brad Chisholm wrote: Well, I believe I discovered the source of my problem. It turns out that I did not have the correct devices configured in /dev for the component drives. I had da[0-3]e, but not da[0-3]s1e. The documentation seemed to indicate that the da?s1? devices were not required, but once I made them, the crashes stopped. Unless it's changed (again) you only need "/dev/da[0-3]" with no slice or partition. Not to surprising that it paniced with what appeared to be a "dedicated" disk (ie da0e). It's interesting that I could bring the array up using the 'start' command from the vinum interactive prompt, and things would work properly with the missing devices, while issuing a direct 'vinum start' would cause a panic. Expected behaviour. From vinum.8: If no object names are specified, vinum scans the disks known to the system for vinum drives and then reads in the configuration as described under the read commands. The vinum drive contains a header with all information about the data stored on the drive, including the names of the other drives which are required in order to represent plexes and volumes. Similarly you could list only one drive for the read command in rc.conf and it should bring up all drives. Emphasis on the "could" and "should" here. Doing a "dd if=/dev/da0s1e skip=8 count=6 | tr -d '\000-\011\200-\377'" would show why, but then you should have seen this if read the section abover kernel panics. ;) Even though this may have been a stupid user error, it would be nice if vinum could catch this without a system crash. To that end, I'm including an updated traceback from my panic dump which has the vinum calls included. The only time recently that I've seen it panic is when doing something wrong. Earlier in the year made pretty much the same mistake you have here. Thanks for providing such a useful piece of software! Most certainly is. Could use the functionality to add to a plex's size for striped or RAID5, but a bit of planning cures that. 8-) Jeff Mountin - [EMAIL PROTECTED] Systems/Network Administrator FreeBSD - the power to serve '86 Yamaha MaxiumX (not FBSD powered) To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: System crash on vinum start
On Monday, 27 September 1999 at 15:37:30 -0500, Jeffrey J. Mountin wrote: At 01:05 PM 9/27/99 -0400, Brad Chisholm wrote: Well, I believe I discovered the source of my problem. It turns out that I did not have the correct devices configured in /dev for the component drives. I had da[0-3]e, but not da[0-3]s1e. The documentation seemed to indicate that the da?s1? devices were not required, but once I made them, the crashes stopped. Unless it's changed (again) you only need "/dev/da[0-3]" with no slice or partition. It has changed (again). Not to surprising that it paniced with what appeared to be a "dedicated" disk (ie da0e). It's surprising. Good software shouldn't panic. But this input is valuable, because now I know where to look. It's interesting that I could bring the array up using the 'start' command from the vinum interactive prompt, and things would work properly with the missing devices, while issuing a direct 'vinum start' would cause a panic. Expected behaviour. From vinum.8: If no object names are specified, vinum scans the disks known to the system for vinum drives and then reads in the configuration as described under the read commands. The vinum drive contains a header with all information about the data stored on the drive, including the names of the other drives which are required in order to represent plexes and volumes. Similarly you could list only one drive for the read command in rc.conf and it should bring up all drives. Emphasis on the "could" and "should" here. I think you're misinterpreting what Brad was saying. He was issuing the same command, once during boot and once later. I've had a number of reports of this problem, but this is the first one that helps me find the bug. Thanks for providing such a useful piece of software! Most certainly is. Could use the functionality to add to a plex's size for striped or RAID5, but a bit of planning cures that. 8-) It's all in the pipeline. But first we need Vinum on the root file system. Greg -- See complete headers for address, home page and phone numbers finger [EMAIL PROTECTED] for PGP public key To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: System crash on vinum start
On Tuesday, 28 September 1999 at 12:59:34 +1000, Peter Jeremy wrote: On Tue, Sep 28, 1999 at 09:11:31AM +1000, Greg Lehey wrote: Good software shouldn't panic. I wish _I_ could convince some people of this :-(. Most certainly is. Could use the functionality to add to a plex's size for striped or RAID5, but a bit of planning cures that. 8-) It's all in the pipeline. But first we need Vinum on the root file system. And whilst we're discussing wish-lists... After several fights with Digital/Compaq's Logical Storage Manager, it would be _very_ nice if recovery could be done at the physical disk level (ie, "I've just replaced da3 - autorecover all vinum volumes that used that disk"), rather than having to recover each logical volume. It would also be nice if you could recover mirrored root/swap without needing to unmirror and re-mirror them. Yup, it's all on the way. I've just found the second-last bug in Vinum, so now I'll have time to do that sort of thing :-) Greg -- See complete headers for address, home page and phone numbers finger [EMAIL PROTECTED] for PGP public key To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: System crash on vinum start
At 08:41 AM 9/28/99 +0930, Greg Lehey wrote: It has changed (again). And the preferred method is... a) /dev/da0 b) /dev/da0s1 c) /dev/da0s1e (-current and -stable I hope :) Not to surprising that it paniced with what appeared to be a "dedicated" disk (ie da0e). It's surprising. Good software shouldn't panic. But this input is valuable, because now I know where to look. Should have spoken up quite a while back. Figured it was pilot error and the panic was a self-inflicted gunshot wound. I think you're misinterpreting what Brad was saying. He was issuing the same command, once during boot and once later. I've had a number of reports of this problem, but this is the first one that helps me find the bug. Interpreted as an either/or. Vinum read followed by a vinum read (or start)? It's all in the pipeline. But first we need Vinum on the root file system. How is this coming along, been quite a while since anything has discussed (-current/-stable/-cvs). Last thing was back in July. Jeff Mountin - [EMAIL PROTECTED] Systems/Network Administrator FreeBSD - the power to serve '86 Yamaha MaxiumX (not FBSD powered) To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: System crash on vinum start
On Fri, Sep 24, 1999 at 04:36:54PM -0400, Brad Chisholm wrote: D d0State: up Device /dev/da0eAvail: 0/17366 MB (0%) D d1State: up Device /dev/da1eAvail: 0/17366 MB (0%) D d2State: up Device /dev/da2eAvail: 0/17366 MB (0%) D d3State: up Device /dev/da3eAvail: 0/17366 MB (0%) da0: 17366MB (35566480 512 byte sectors: 255H 63S/T 2213C) da3: 17366MB (35566480 512 byte sectors: 255H 63S/T 2213C) da2: 17366MB (35566480 512 byte sectors: 255H 63S/T 2213C) da1: 17366MB (35566480 512 byte sectors: 255H 63S/T 2213C) What disk are you booting from? Does it only happen on start or do you have problems using read too? I have one host on which I don't use start, because one removeable drive (SyQuest SQ5200) missbehaves reading while there is no media inserted - but it does not panic the host - it only was trying to read from it longer than my finger needed to reach reset... -- B.Walter COSMO-Project http://www.cosmo-project.de [EMAIL PROTECTED] Usergroup[EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: System crash on vinum start
On Friday, 24 September 1999 at 16:36:54 -0400, Brad Chisholm wrote: I'm having a problem where the "vinum start" command crashes my system. This happens regardless of whether it's being issued during bootup via /etc/rc or from the command line on a running system. Interestingly, however, if I issue the start command from the vinum interactive prompt, it works properly with no crash. I'm currently running on a snap built this morning (0924), but it was also happening on a snap from 0914. Crash info, vinum config, and disk info are below. Let me know if I can provide any additional information. Yes. Please read the instructions in vinum(4) about debugging panic dumps. I found a minor bug in 'vinum start' recently, but I doubt it's causing your problem. I'll commit it Real Soon Now. Greg -- See complete headers for address, home page and phone numbers finger [EMAIL PROTECTED] for PGP public key To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
