Re: megamgr on 6.1?
kldload amr_linux did the trick for me, thanks! Cheers, B > Boris Samorodov writes: > | On Tue, 9 May 2006 12:37:43 -0400 (EDT) Brian Szymanski wrote: > | > PS - mknod c 254 /compat/linux/dev/megadev0 (which is what the device > is > | > under linux) doesn't help :( > | > | I't only my imho, use it with care: > | > | # cd /dev > | # ln -s amr0 megadev0 > > Nope, it needs to show up in devfs. Making a node manually is going > to cause trouble. If there isn't a /dev/megadev0 then you don't > have the amr_linux loaded. You can try to kldload but you might > have to compile it in static. > > Doug A. > > Brian Szymanski Software and Systems Developer Media Matters for America [EMAIL PROTECTED] ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: megamgr on 6.1?
PS - mknod c 254 /compat/linux/dev/megadev0 (which is what the device is under linux) doesn't help :( > >> On Tue, 9 May 2006 10:15:31 -0400 (EDT) Brian Szymanski wrote: >> >>> Oh, duh, it's been so long since I used linux binary emulation that I >>> forgot all about brandelf... Thanks Michael! >> >>> ... But now that the binary is properly branded, I get a different >>> error: >>> Error opening terminal: xterm. >>> I get the same error for xterm-color, cons25, vt220, and everything >>> else >>> I've tried... (and I know for a fact that TERM=xterm works on my linux >>> machines)... Any ideas? >> >> Just load >> http://www.lsilogic.com/cm/License.do?url=/files/support/rsa/utilities/megamgr/ut_linux_mgr_5.20.zip&prodName=MegaRAID%20SATA%20150-4&subType=Miscellaneous >> Unzipped it, branded and run ./megamgr.bin as root on _console_. I've >> got "Failed to open driver node /dev/megadev0" (really I don't have >> one). BTW on xterm it shows the same message. > > Oops - I was lacking a linux compat_linux port... Installed one, (fc3), > and now I have the same problem about not finding megadev0, even tho I > have an amr... > > Thanks for everyone's help so far... Any more ideas? > > Cheers, > Brian > >> >> >> WBR >> -- >> Boris B. Samorodov, Research Engineer >> InPharmTech Co, http://www.ipt.ru >> Telephone & Internet Service Provider >> >> > > > Brian Szymanski > Software and Systems Developer > Media Matters for America > [EMAIL PROTECTED] > aim: xbrianskix > > ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: megamgr on 6.1?
> On Tue, 9 May 2006 10:15:31 -0400 (EDT) Brian Szymanski wrote: > >> Oh, duh, it's been so long since I used linux binary emulation that I >> forgot all about brandelf... Thanks Michael! > >> ... But now that the binary is properly branded, I get a different >> error: >> Error opening terminal: xterm. >> I get the same error for xterm-color, cons25, vt220, and everything else >> I've tried... (and I know for a fact that TERM=xterm works on my linux >> machines)... Any ideas? > > Just load > http://www.lsilogic.com/cm/License.do?url=/files/support/rsa/utilities/megamgr/ut_linux_mgr_5.20.zip&prodName=MegaRAID%20SATA%20150-4&subType=Miscellaneous > Unzipped it, branded and run ./megamgr.bin as root on _console_. I've > got "Failed to open driver node /dev/megadev0" (really I don't have > one). BTW on xterm it shows the same message. Oops - I was lacking a linux compat_linux port... Installed one, (fc3), and now I have the same problem about not finding megadev0, even tho I have an amr... Thanks for everyone's help so far... Any more ideas? Cheers, Brian > > > WBR > -- > Boris B. Samorodov, Research Engineer > InPharmTech Co, http://www.ipt.ru > Telephone & Internet Service Provider > > Brian Szymanski Software and Systems Developer Media Matters for America [EMAIL PROTECTED] aim: xbrianskix ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: megamgr on 6.1?
Oh, duh, it's been so long since I used linux binary emulation that I forgot all about brandelf... Thanks Michael! ... But now that the binary is properly branded, I get a different error: Error opening terminal: xterm. I get the same error for xterm-color, cons25, vt220, and everything else I've tried... (and I know for a fact that TERM=xterm works on my linux machines)... Any ideas? Cheers, Brian > Brian Szymanski wrote: >> Hi... >> >> I saw this in the 6.1 release notes and eagerly upgraded: >> "The amr(4) driver now supports ioctl(2) requests necessary for Linux >> LSI MegaRaid tools on FreeBSD's Linux emulation environment." >> >> However, when I pulled over a megamgr.bin binary from a linux machine, >> and >> try to execute it on my freebsd machine, I get: >> [EMAIL PROTECTED] ~/src/megaraid]# ./megamgr.bin >> ELF binary type "0" not known. >> bash: ./megamgr.bin: cannot execute binary file >> >> Has anyone got this working? What did they need? Any help would be >> appreciated, as I'm seriously sick of megarc :) >> >> Thanks in advance! >> > > Since it appears to require Linux emulation, have you tried branding the > binary is a Linux ELF with brandelf(1)? > > > -Proto > > Brian Szymanski Software and Systems Developer Media Matters for America [EMAIL PROTECTED] skype: xbrianskix aim: xbrianskix ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
megamgr on 6.1?
Hi... I saw this in the 6.1 release notes and eagerly upgraded: "The amr(4) driver now supports ioctl(2) requests necessary for Linux LSI MegaRaid tools on FreeBSD's Linux emulation environment." However, when I pulled over a megamgr.bin binary from a linux machine, and try to execute it on my freebsd machine, I get: [EMAIL PROTECTED] ~/src/megaraid]# ./megamgr.bin ELF binary type "0" not known. bash: ./megamgr.bin: cannot execute binary file Has anyone got this working? What did they need? Any help would be appreciated, as I'm seriously sick of megarc :) Thanks in advance! Relevant bits of dmesg: FreeBSD 6.1-RELEASE #0: Tue May 9 09:01:31 EDT 2006 [EMAIL PROTECTED]:/usr/obj/usr/src-6.1/sys/OZELMO amr0: mem 0xef00-0xef00 irq 16 at device 13.0 on pci0 amr0: delete logical drives supported by controller amr0: Firmware 713N, BIOS G119, 64MB RAM ... amr0: delete logical drives supported by controller amrd0: on amr0 amrd0: 953656MB (1953087488 sectors) RAID 5 (optimal) [EMAIL PROTECTED] ~/src/megaraid]# kldstat Id Refs AddressSize Name 15 0xc040 504e7c kernel 21 0xc4bc2000 1a000linux.ko Brian Szymanski Software and Systems Developer Media Matters for America [EMAIL PROTECTED] aim: xbrianskix ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: well-supported SATA RAID card?
I sent an email to highpoint tech support detailing the problems, and have had no response after an initial ping :( ... Here is a summary of what I sent them: For all tests, I ran bonnie++ over and over again while concurrently copying the contents of /usr to the mounted disk, then rm -rf'ing repeatedly. I tried two configurations with 2 200G drives, one RAID-0, one RAID-1. In raid-0 mode, the kernel error was: IAL: COMPLETION ERROR, adapter 0, channel 1, flags=104 ATA regs: error 40, sector count 20, LBA low 5f, LBA mid 16, LBA high 5f, device 4c, status 51 Reset channel IAL: COMPLETION ERROR, adapter 0, channel 1, flags=104 ATA regs: error 40, sector count 20, LBA low 5f, LBA mid 16, LBA high 5f, device 4c, status 51 Reset channel ... hptmv: Device removed: controller 1 channel 1 (da0:hptmv0:0:0:0): Synchronize cache failed, status == 0x39, scsi status == 0x0 Opened disk da0 -> 5 Opened disk da0 -> 5 ... At this point any attempts to access any mounted files or the raw device die with an io error. In raid-1 mode, I got a panic: Fatal trap 12: page fault while in kernel mode fault virtual address = 0x400 fault code = supervisor read, page not present instruction pointer = 0x8:0xc073646c stack pointer = 0x10:0xe4e05ba4 frame pointer = 0x10:0xe4e05bf0 code segment = base 0x0, limit 0xf, type 0x1b - DPL 0, pres 1, def32 1, gran 1 processor eflags = interrupt enabled, resume, IOPL = 0 current process = 3 (g_up) trap number = 12 panic: page fault I later tried a RAID-5 array, and doing the same basic stress testing, the machine would panic after between 3-6 hours. I didn't record the error message, but it was something about freeing an already free page. I upgraded the BIOS to version 1.17c from the 1.13 that was on the cards when they shipped. This seemed to improve things, but did not eliminate the problems. I tried fbsd 5.4 and 6.0, with both a custom kernel and GENERIC versions. Never was I able to stress test for more than about 8-10 hours without a panic or the device becoming inaccessible. Of course, there is also the lack of management utilities while the OS is running which has me looking elsewhere. I'd be willing to try further tests if folks have patches or other ideas - I have a couple more weeks before I have to RMA the suckers, and am willing to do testing if someone wants to make a patch... Cheers, B > Interested to hear that you have a problem with your highpoint driver, what sort of problems are you seeing? > > On Fri, 2006-03-10 at 12:30 +, Steven Hartland wrote: >> What problems are you having there Brian, Im currently in contact with the Highpoint developers over a specific issue with that card's drivers and would be happy to raise any other issues you may be seeing. >> >> Aside from the that we have had good experiences with Areca card. >> >> Steve >> - Original Message - >> From: "Brian Szymanski" <[EMAIL PROTECTED]> >> > >> > After not having much success with the hptmv driver for highpoint's rocketraid 1820A, I'm wondering if other folks have had good luck with >> any >> > SATA RAID cards with at least 6 ports... Is there a SATA RAID card >> with >> > utilities that let you manage while the OS is running that folks have >> had >> > good luck with? I've been happy with the megaraid series on linux at >> my >> > job, but I'm wondering if the management utilities are there on >> freebsd, >> > etc >> >> >> >> This e.mail is private and confidential between Multiplay (UK) Ltd. and the person or entity to whom it is addressed. In the event of >> misdirection, the recipient is prohibited from using, copying, printing or otherwise disseminating it or any information contained in it. >> >> In the event of misdirection, illegible or incomplete transmission please telephone (023) 8024 3137 >> or return the E.mail to [EMAIL PROTECTED] >> >> ___ >> freebsd-stable@freebsd.org mailing list >> http://lists.freebsd.org/mailman/listinfo/freebsd-stable >> To unsubscribe, send any mail to >> "[EMAIL PROTECTED]" > > Brian Szymanski Software and Systems Developer Media Matters for America [EMAIL PROTECTED] ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: well-supported SATA RAID card?
Wow - Lots of votes for 3ware. Any votes for something cheaper? The 3ware's are more than I want to spend... Also, does anyone know if the megaraid management tools work on freebsd? Cheers, Brian >> Date: Fri, 10 Mar 2006 10:07:51 +0100 >> From: "Patrick M. Hausen" <[EMAIL PROTECTED]> >> Sender: [EMAIL PROTECTED] >> >> Mornin' >> >> > After not having much success with the hptmv driver for highpoint's >> > rocketraid 1820A, I'm wondering if other folks have had good luck with >> any >> > SATA RAID cards with at least 6 ports... Is there a SATA RAID card >> with >> > utilities that let you manage while the OS is running that folks have >> had >> > good luck with? I've been happy with the megaraid series on linux at >> my >> > job, but I'm wondering if the management utilities are there on >> freebsd, >> > etc. >> >> http://www.icp-vortex.com/english/product/pci/rz_sata_8/8586rz_e.htm >> >> Expensive? Yes. >> >> Fast, reliable, cheap - pick any two ;-) > > Well, they are also probably not too cheap, but I have been very happy > with the 3Ware SATA card. 3Ware has been very good at support for > FreeBSD and the management tool (3DM2) is in ports. > -- > R. Kevin Oberman, Network Engineer > Energy Sciences Network (ESnet) > Ernest O. Lawrence Berkeley National Laboratory (Berkeley Lab) > E-mail: [EMAIL PROTECTED] Phone: +1 510 486-8634 > > Brian Szymanski Software and Systems Developer Media Matters for America [EMAIL PROTECTED] cell: 202.243.9007 work: 202.756.4128 home: 202.470.2578 skype: xbrianskix aim: xbrianskix ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: well-supported SATA RAID card?
> Mornin' > >> After not having much success with the hptmv driver for highpoint's >> rocketraid 1820A, I'm wondering if other folks have had good luck with >> any >> SATA RAID cards with at least 6 ports... Is there a SATA RAID card with >> utilities that let you manage while the OS is running that folks have >> had >> good luck with? I've been happy with the megaraid series on linux at my >> job, but I'm wondering if the management utilities are there on freebsd, >> etc. > > http://www.icp-vortex.com/english/product/pci/rz_sata_8/8586rz_e.htm > > Expensive? Yes. > > Fast, reliable, cheap - pick any two ;-) In my case, I'm actually shooting for reliable and (relatively) cheap :) Fast is nice but I don't much care, so the megaraids look slightly better than this product, but thanks for the tip anyway :) Brian Szymanski Software and Systems Developer Media Matters for America [EMAIL PROTECTED] ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
well-supported SATA RAID card?
Howdy... After not having much success with the hptmv driver for highpoint's rocketraid 1820A, I'm wondering if other folks have had good luck with any SATA RAID cards with at least 6 ports... Is there a SATA RAID card with utilities that let you manage while the OS is running that folks have had good luck with? I've been happy with the megaraid series on linux at my job, but I'm wondering if the management utilities are there on freebsd, etc. Thanks in advance... Brian Szymanski Software and Systems Developer Media Matters for America [EMAIL PROTECTED] ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: gvinum/vinum on 6.0
>> Hmm, I upgraded to 6-STABLE and I'm still having the problem. > > Are you really using the very latest 6-STABLE? Oops - serious egg on my face - my build must have failed and I rebooted without checking the return value (sheepish grin)... I rebuilt and things seem to work now - thanks & sorry for the false alarm! I cannot tell you how happy I am to have (g?)vinum working in FreeBSD again - I can finally upgrade my file servers! One more question: Is gvinum on 6-STABLE's RAID-5 implementation bit-compatible with R5 on vinum from 4.x/5.x? Would it be possible to upgrade from vinum on 5.3 to gvinum on 6-STABLE without a dump/restore? I probably won't do this out of paranoia, but am curious if it's possible. Thanks again and cheers, Brian Brian Szymanski Software and Systems Developer Media Matters for America [EMAIL PROTECTED] ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: gvinum/vinum on 6.0
Stijn, thanks for your help, I'm getting closer... >> I took 6.0 for a test drive today and was disappointed to find that >> vinum/gvinum are still in disarray. For example there is a man page for >> vinum, but only a gvinum binary. gvinum help still lists lots of old >> vinum >> commands that are not implemented in gvinum. Lots of basic things I try >> from the gvinum prompt just tell me "not yet supported". > > Hmm. There is a manpage in 6-STABLE. And there are a few things that > don't work but I wouldn't call it "lots". Ah, a manpage! Progress... >> But most importantly, gvinum configuration (at least for a raid-5 plex) >> still doesn't persist across a reboot :( > > That's a bug; I think it might be related to compiling gvinum in the > kernel > as opposed to loading it from /boot/loader.conf. I also think there is a > fix already commited to 6-STABLE. Hmm, I upgraded to 6-STABLE and I'm still having the problem. Here's basically how it happens: gvinum create /etc/vinum.cnf newfs /dev/gvinum/VOLUME mount /dev/gvinum/VOLUME /mnt #screw with /mnt, everything works and is happy, yay! reboot At this point I call "gvinum l" (which loads geom_vinum.ko) by hand (after the reboot). My configuration mostly seems to persist - except or the "drives" section... One of two things happens here: Either a) The volumes/plexes appear down, the subdisks are stale. Additionally, /dev/gvinum is not there - suffice it to say I can't mount anything. b) Everything has status up (except the nonexistent drives). In this case as well, /dev/gvinum is not there - and I still can't mount anything. If I try to fix the configuration by gvinum rm'ing the volumes and plexes that are there, then reloading my vinum.cnf (gvinum create), either: a) everything seems to work b) the system panics Unfortunately there is no correlation between "gvinum l" output and whether the system panics or is happy when I run gvinum create again. Would I have better luck compiling gvinum into the kernel instead of loading the module? What do other folks who have successful config's do? Thanks in advance, Brian Brian Szymanski Software and Systems Developer Media Matters for America [EMAIL PROTECTED] vinum.r5.cf Description: Binary data gvinum.before Description: Binary data gvinum.after Description: Binary data ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
gvinum/vinum on 6.0
Howdy. I took 6.0 for a test drive today and was disappointed to find that vinum/gvinum are still in disarray. For example there is a man page for vinum, but only a gvinum binary. gvinum help still lists lots of old vinum commands that are not implemented in gvinum. Lots of basic things I try from the gvinum prompt just tell me "not yet supported". But most importantly, gvinum configuration (at least for a raid-5 plex) still doesn't persist across a reboot :( Has anyone had success with software Raid-5 under freebsd 6.0 ? If so, how did you do it? I've been forced, rather unhappily, to stick with 4.x and some early 5.x releases b/c vinum is critical for me... Any advice would be greatly appreciated. Brian Szymanski Software and Systems Developer Media Matters for America [EMAIL PROTECTED] ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
boot0/BIOS problem...
Hi. I'm having a problem with boot0. All of my hard drives have the freebsd boot manager (aka boot0) installed so I can select which disk to boot off of (I have 4 hard disks, 2 of which have bootable slices). When I boot up, I can only boot to my /altroot partition. boot0 only lets me toggle through 3 drives - 2 nonbootables and my /altroot. For clarity, here's the layout: MoboATA (atapci2) ---ch1-(ata0)--> PATA HD 1 (ad0: non-bootable) \-ch2-(ata1)--> PATA HD 2 (ad2: non-bootable) PCIATA card (atapci0) ---ch1-(ata2)--> PATA DVD drive (acd0, would be ad4) \-ch2-(ata3)--> (empty) MoboSATA (atapci1) --ch1-(ata4)--> SATA HD 1 (ad8: this should be /) \-ch2-(ata5)--> SATA HD 2 (ad10: /altroot ) Or the equivalent in dmesg-ese: atapci0: port 0xa800-0xa80f,0xb000-0xb003,0xb400-0xb407,0xb800-0xb803,0xd000-0xd007 mem 0xec00-0xecff irq 17 at device 14.0 on pci0 ata2: channel #0 on atapci0 ata3: channel #1 on atapci0 atapci1: port 0x8800-0x88ff,0x9000-0x900f,0x9400-0x9403,0x9800-0x9807,0xa000-0xa003,0xa400-0xa407 irq 20 at device 15.0 on pci0 ata4: channel #0 on atapci1 ata5: channel #1 on atapci1 atapci2: port 0x8400-0x840f,0x376,0x170-0x177,0x3f6,0x1f0-0x1f7 at device 15.1 on pci0 ata0: channel #0 on atapci2 ata1: channel #1 on atapci2 ad0: 239372MB [486344/16/63] at ata0-master UDMA133 ad2: 239372MB [486344/16/63] at ata1-master UDMA133 acd0: DVDR at ata2-master UDMA33 ad8: 238475MB [484521/16/63] at ata4-master SATA150 ad10: 238418MB [484406/16/63] at ata5-master SATA150 If I reboot, and cycle through the available drives by repeatedly pressing F5, I can access all the Hard Drives except the one I want, namely the first SATA HD (ad8, which is master on ata4). This exact same setup used to work when I had a different PCIATA card attached to my DVD drive (namely, an iTE board which I had to patch the kernel to get it to recognize it - I now have an adaptec SiI 0680 UDMA133 controller). The iTE board was also detected as atapci0 and gave ata2 and ata3. Of course this is all irrelevant because we don't even get to the kernel. So I'm a bit stumped as to what the problem is here. Is it possible that boot0 is making some weird call to the bios to figure out what the list of bootable devices are, and that my bios is the one who's really confused about the new card? I'm running 5.3-p15 (can't go to 5.4, because I need vinum R5 to at least partially work! sigh...) Thanks in advance, Brian Szymanski Software and Systems Developer Media Matters for America [EMAIL PROTECTED] ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
iTE IT8212 card/ata problems
Hello... FreeBSD 5.3 on x86 I've installed an addon ATA card, an IT8212(F), and it comes in at bios time, detects drives and such, but freebsd doesn't see it on booting. I thought maybe this was because no drives were attached, but no dice with a drive attached (even though the card sees this drive at boot time). My system has a somewhat unusual ATA situation - a built in 2-port ATA controller, another built in 2-port SATA controller, and now this card (2 port ATA as well). Is it possible that freebsd just doesn't expect so many ata devices, or is the card just not supported? I don't see it in hardware-i386.html, but generic ata cards have worked for me in the past - was I just been getting lucky before? Thanks for any ideas. Cheers, Brian Szymanski [EMAIL PROTECTED] ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
dump/restore with ufs2
When I run the following script, I get a warning message, and I'm wondering if it's ignorable or indicates there is a little more work to be done in getting dump/restore happy with ufs2... $ cd /altroot $ dump -L -0 -a -f - /dev/$ROOT | restore -rf - ... warning: ./.snap: File exists Does this mean my snapshots are being overwritten on the target disk? And if so, that's a good thing, right? Cheers, Brian Szymanski [EMAIL PROTECTED] ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: vinum raid 5
>>>>>> "Brian" == Brian Szymanski <[EMAIL PROTECTED]> writes:
>
> Brian> Actually I experienced a number of bugs with vinum in 5.3 that
> Brian> proved fatal to a root vinum install (in fact, everything on
> Brian> the second ATA channel was marked down after every reboot if I
> Brian> recall correctly).
>
> I had some problems with a vinum machine (still back at 5.1)
> recently. I removed a pair of drives and the remaining setup wouldn't
> come back up. Turns out that multiple incantations of 'vinum
> setdaemon 0' and 'vinum saveconfig' finally fixed things.
>
> vinum is fragile.
Hmm, the vinum setdaemon 0 ; vinum saveconfig ; trick didn't work for me.
If anyone else finds themself in a similar situation and feels like living
dangerously, I've implemented a solution with the below shell script, to
be called from /etc/rc.local. Use at your own risk.
First more on the symptom: on reboot, vinum looses all config information.
You can load the vinum.cfg again, but this puts every subdisk in the Raid5
in the empty state (when in fact they should usually be in the up state).
You can manually set these subdisks to be up, and find all your
information as it was, a nice "feature".
The solution: write a crappy little shell script to remember vinum's Raid5
config information, and set its state accordingly on boot before
mounting/fscking, etc.
If anyone uses this, I'd be interested to hear their results. It works for
me with drive power pulls. Right now it depends on state being recorded at
boot time, so if vinum thinks a subdisk is down (and thus out of date),
then you reboot and the drive comes back to life for a moment, you're in
deep doo-doo. That is to say: flaky drives may introduce errors onto the
R5, but a drive that fails once and then stays down forever will be fine
with this script (this is the usual case from what I've seen, but I
haven't seen everything)... Also I'm not sure why bgfsck doesn't catch the
filesystem automatically, so I used atd to schedule a job to run at +7
minutes with priority 10 to do the background fsck. The idea here being
that if bgfsck does for some reason catch your Raid5, this fsck should lag
behind and not cause any race condition problems. A future improvement
would be to call the state saving portion of the script in rc.shutdown and
periodically from cron. There are many others, but it "works for me" (tm).
Of course the right solution is to fix {g}vinum so this hideousness isn't
necessary...
Cheers,
Brian Szymanski
[EMAIL PROTECTED]
step 1:
in /etc/rc.local, add:
sh /etc/rc.vinum.raid5
step 2:
create /etc/rc.vinum.raid5:
#!/bin/sh
### configuration
# ie, mount /dev/vinum/$VINUM_NAME $VINUM_MOUNTPT
VINUM_MOUNTPT="/home"
VINUM_NAME="big"
# location of the configuration file with just the Raid5 info
VINUM_CFG="/etc/vinum.big.cfg"
# email address to send notifications to
ADMIN_EMAIL="[EMAIL PROTECTED]"
# place to store state
DEGRADE_FILE="/vinum.degraded"
# if n=# subdisks, SUBDISKS=0..n-1, e.g. the below works for a 4 drive raid5
SUBDISKS="0 1 2 3"
### no config below this point
#if already mounted, abort now
mount | grep -q "^/dev/vinum/$VINUM_NAME on $VINUM_MOUNTPT" && exit 0
# mount R5 device
# (why on earth doesn't vinum info persist across reboot?!?)
/sbin/vinum create -f "$VINUM_CFG"
if [ -e "$DEGRADE_FILE" ] ; then
# start subdisks based on content of DEGRADE_FILE
for i in $SUBDISKS ; do
#start all non-degraded subdisks
grep -q $VINUM_NAME.p0.s${i} "$DEGRADE_FILE" && \
echo $VINUM_NAME.p0.s$i down || \
vinum start $VINUM_NAME.p0.s${i}
done
#this maintains degraded state even if new drive is inserted
#this is important or else we will lose major information
else
/sbin/vinum start $VINUM_NAME.p0
fi
#let vinum catch up...
sleep 1
#check the state, mail $ADMIN_EMAIL if things are horked...
state=`/sbin/vinum l | grep "^P.$VINUM_NAME\.p0" | awk '{ print $5 }'`
echo state: $state
if [ "z$state" = zup ] ; then
# mount /dev/vinum/$VINUM_NAME "$VINUM_MOUNTPT"
#fsck and mount
fsck -F -p "/dev/vinum/$VINUM_NAME"
mount "/dev/vinum/$VINUM_NAME" "$VINUM_MOUNTPT"
#bgfsck should do this automagically, but it doesn't?
at "+7 minutes" <>"$DEGRADE_FILE"
#fsck and mount
fsck -F -p "/dev/vinum/$VINUM_NAME"
mount "/dev/vinum/$VINUM_NAME" "$VINUM_MOUNTPT"
#bgfsck should do this automagically, but it doesn't?
at "+7 minutes" <http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: graid3 - requirements or manpage wrong?
>>>>>> "Brian" == Brian Szymanski <[EMAIL PROTECTED]> writes: > >>> That is not completely fair for vinum >>> >>> I've been running vinum now for the better of 3-4 years, and even >>> with a set of very flaky seagate IDE drives I never lost a byte. >>> Vinum has served me well, and I trust gvinum will get there as >>> well. I just left my fileserver at 5.1, which I know is not an >>> option for everybody. > > Brian> Are you using vinum Raid5 ? I'm considering rolling back to 5.1 > Brian> myself if someone attests that things "just work" there with > Brian> R5, then waiting for gvinum to mature before getting my machine > Brian> back on stable. > > Brian> Also, when did vinum stop working in favor of gvinum? is it > Brian> with 5.3? Could I expect 5.2.1 to work? Pardon the barrage of > Brian> questions, but it would take me hours to test each case, so if > Brian> anyone knows, drop me a line. Thanks! > > In 5.3, it appears that you can load vinum or gvinum. Vinum appears > to have the functionality (and bugs) that it had back in 5.1. The > only missing function seems to be the ability to swap to a vinum > volume. Actually I experienced a number of bugs with vinum in 5.3 that proved fatal to a root vinum install (in fact, everything on the second ATA channel was marked down after every reboot if I recall correctly). As for the swap: why would you want to do that? It was my understanding that the kernel load balanced swap requests across drives? Cheers, Brian > Dave. > > -- > > |David Gilbert, Independent Contractor. | Two things can only be > | > |Mail: [EMAIL PROTECTED] | equal if and only if they > | > |http://daveg.ca | are precisely opposite. > | > =GLO > -- Brian Szymanski [EMAIL PROTECTED] ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: graid3 - requirements or manpage wrong?
> That is not completely fair for vinum > > I've been running vinum now for the better of 3-4 years, and even with a > set of very flaky seagate IDE drives I never lost a byte. > Vinum has served me well, and I trust gvinum will get there as well. > I just left my fileserver at 5.1, which I know is not an option for > everybody. Are you using vinum Raid5 ? I'm considering rolling back to 5.1 myself if someone attests that things "just work" there with R5, then waiting for gvinum to mature before getting my machine back on stable. Also, when did vinum stop working in favor of gvinum? is it with 5.3? Could I expect 5.2.1 to work? Pardon the barrage of questions, but it would take me hours to test each case, so if anyone knows, drop me a line. Thanks! Brian Szymanski [EMAIL PROTECTED] ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
gvinum raid 5 (was re: graid3)
> What's unusable about it? I've 4 250GB ATA drives, desiring capacity + > redundancy, but don't care about speed, much like you, and gvinum raid 5 > has suited me just fine this past few weeks. Eats a lot of system cpu when > there is heavy IO to the R5, but I've booted up with a drive unplugged and > it worked fine in degraded mode, so I'm content... Hmm... Maybe I got lucky/had an empty filesystem/hallucinated last time, but in any event when I try pulling the power on a drive now I get an error about a block not being found... Less than reassuring: drive 1: /dev/gvinum/big: CAN'T CHECK FILE SYSTEM /dev/gvinum/big: UNEXPECTED INCONSISTENCY; RUN fsck MANUALLY drive 2: /dev/gvinum/big: CANNOT READ BLK: 1401158656 /dev/gvinum/big: UNEXPECTED INCONSISTENCY; RUN fsck MANUALLY drive 3: /dev/gvinum/big: CANNOT READ BLK: 1401158656 /dev/gvinum/big: UNEXPECTED INCONSISTENCY; RUN fsck MANUALLY drive 4: Cannot find file system superblock /dev/gvinum/big: CANNOT READ BLK: 1401158656 /dev/gvinum/big: UNEXPECTED INCONSISTENCY; RUN fsck MANUALLY /dev/gvinum/big: CANNOT WRITE BLK: 12000 /dev/gvinum/big: UNEXPECTED INCONSISTENCY; RUN fsck MANUALLY --- THE FOLLOWING FILE SYSTEM HAD AN UNEXPECTED INCONSISTENCY: ufs: /dev/gvinum/big (/home) Automatic file system check failed; help! Pulling power on the RAID0/RAID1 arrays I have does what I expect it to do... Anyone have any idea what's going on here? Cheers, Brian Szymanski [EMAIL PROTECTED] ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: 5.3 on Intel 386 ?
> Note that you will need a hardware FPU (i387 math co-pro). > FreeBSD 4.x supports math emulation, so you don't need a > hardware FPU there, but apparently that support has been > removed in FreeBSD 5.x. Out of curiosity, what happened to this code? Was there some incompatibility, did it have the wrong license, etc? Cheers, Brian > Best regards >Oliver > > -- > Oliver Fromme, secnetix GmbH & Co KG, Oettingenstr. 2, 80538 München > Any opinions expressed in this message may be personal to the author > and may not necessarily reflect the opinions of secnetix in any way. > > "If you think C++ is not overly complicated, just what is a protected > abstract virtual base pure virtual private destructor, and when was the > last time you needed one?" > -- Tom Cargil, C++ Journal > ___ > [EMAIL PROTECTED] mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-stable > To unsubscribe, send any mail to "[EMAIL PROTECTED]" > -- Brian Szymanski [EMAIL PROTECTED] ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: graid3 - requirements or manpage wrong?
>>The only problem then is - gvinum being in a completely unusable state >>(for raid5 anyway), what are my alternatives? I have four 160gb IDE >>drives, and I want capacity+redundancy. Performance is a non-issue, >>really. What do I do - in software? What's unusable about it? I've 4 250GB ATA drives, desiring capacity + redundancy, but don't care about speed, much like you, and gvinum raid 5 has suited me just fine this past few weeks. Eats a lot of system cpu when there is heavy IO to the R5, but I've booted up with a drive unplugged and it worked fine in degraded mode, so I'm content... > Vinum and now gvinum (I have not tried the latter, your words) have > never had reliable RAID-5 implementation. That is my experience only. ? This is the first I've heard of such problems? Vinum has served me well in the past, although I've never used Raid-5 before... If there are known bugs, I'd appreciate someone sending me a link to where I can read more. Cheers, Brian Szymanski [EMAIL PROTECTED] ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: make -j$n buildworld : use of -j investigated
Did you try any machines that used Hyperthreading? I'd be interested to see how those machines fare based on the number of logical and real CPUs. > Although people suggest "-j4" as optimal in general > case, I have come to a very different conclusion: > > 1) single CPU with enough RAM (2 GHz, 512 MB) > there's no significant speed up in the range > "-j1" to "-j9". > So "-j1" is as good as "-j9". If you went to all that trouble, you might as well post the numbers :-) > 2) single CPU with little RAM (333 MHz, 64 MB) > speed slows down rapidly from "-j1" to "-j9", > because of intensive swapping. > So "-j1" performs best in this case. This is expected. A note should probably be added to the handbook giving rough approximations of how much memory per simultaneous process is necessary for optimal performance. I'd guess 48MB * p + c, where c = the machine's memory load while idle and p = the number of compile processes (most don't take nearly that much memory, but c++ can gobble it) > 3) dual CPU with enough RAM (2 x 800 MHz, 1GB) > speed up by almost two from "-j1" to "-j2", > but after that no noticeable speed up anymore. > So "-j2" is as good as "-j9". Again, you went to the trouble, post the numbers? > With these simple tests, I come to the conclusion that > "make -j$n buildworld" is best with n = number of CPUs. > Does that make sense? Sort of. It depends on more than just the number of CPUs. IO speed is also very important. If you're using NFS over non-gigabit ethernet or to a slow NFS server, it's worth ratcheting the number of threads up. The same would go for old slow disks, or if you have /usr/src union-mounted from a cdrom drive, etc. Also disk layout: having /usr/src on a different drive from /usr/obj can speed up the IO-bound portions of the process a great deal by eliminating contention. If you do less waiting for IO, adding more threads has a less pronounced or even negative effect due to cpu contention instead of the positive "work while the other thread waits on IO" effect. This is the basic underlying principle, which the handbook doesn't really point out. Seems to me the pluses and minuses of increasing n are: + More chances to do work when other processes are waiting on IO. - CPU contention resulting in context switches and other wasted cycles due to extra scheduling overhead (probably negligible, maybe significant with high HZ in kernel config). - Memory contention (aka usage). It might be worth decreasing the number recommended somewhat, but I think j = ncpu is too small for a general recommendation, because unless you are memory tight there is very little harm in increasing the number. I'd suspect j = 2 * ncpu or even j = ncpu + 1 are better rules of thumb. A better formula would take average IO thruput and latency rates from bonnie++, amount of available memory, and the number and speed of cpus. A perl script that measures these numbers and determines the optimal setting is left as an excersize to the reader. Extra credit - code it in C and get it integrated in -CURRENT so that "make buildworld" automagically calls "make -j=$n real_buildworld" with the optimal value of n :-) My results, for what it's worth: Specs: Athlon XP 2500+, 512M of 333MHz DDR ram. /usr/obj is a gvinum raid0 (striped) volume of two SATA disks. /usr/src is on a gvinum raid1 (mirrored) volume of two PATA disks. options HZ=1000 in the kernel config, pretty vanilla besides that.. in make.conf: CFLAGS=-O2 -pipe -march=athlon-xp CXXFLAGS empty due to a bug with memoization last time i tried a compile... make -j1 buildworld: real64m54.298s user52m56.915s sys 9m13.041s make -j2 buildworld: real67m55.816s user56m20.778s sys 10m20.247s make -j3 buildworld: real70m53.936s user59m2.447s sys 10m43.325s make -j4 buildworld: real72m25.904s user60m19.098s sys 10m59.492s -- Brian Szymanski [EMAIL PROTECTED] ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
DEAD THREAD: What OS are you? fun
This thread needs to die. The speed of light has nothing to do with this mailing list, period. Let this be the last post to it. Thank you! Cheers, Brian Szymanski [EMAIL PROTECTED] > In message: <[EMAIL PROTECTED]> > Gregory Bond <[EMAIL PROTECTED]> writes: > : Rob wrote: > : > : >>> You'd better cite your source and / or reasoning, as ~3*10^8m/s =is= > : >>> the > : >>> accepted constant speed of light in vacuum. > : >> > : It's deeper than that. The "second" and the "meter" are both defined in > : terms of wavelengths of light, which (as a consequence) fixes the speed > : of light _by definition_, at _exactly_ *299 792 458 m s^-1. > > The second is not defined in terms of the speed of light. It is > defined in terms of the number of hyperfine transitions of cesium: > > http://www.bipm.fr/en/si/si_brochure/chapter2/2-1/second.html > The second is the duration of 9 192 631 770 periods of the > radiation corresponding to the transition between the two > hyperfine levels of the ground state of the caesium 133 atom. > This definition refers to a caesium atom at rest at a > temperature of 0 K. > > The meter used to be defined in terms the wavelength of Krypton-86 > radiation, but that was changed in 1983. It is nowdefined in terms of > how far light travels in a given time interval. See > http://physics.nist.gov/cuu/Units/meter.html for a good historical > perspective. > > So the definition of the meter is dependent on the second, but the > second is independent. > > However, the definition implicitly assumes that today's fundamental > constants of the universe are indeed constant. There's been some > evidence that suggests, but is so far inconclusive, that some or all > of the fundamental constants of the universe may vary on the order of > a few parts in 10^15 over the last few billion years or so. The > definition of the meter was changed before this evidence was known. > > And this is indeed, very off topic. > > Warner > > ___ > [EMAIL PROTECTED] mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-stable > To unsubscribe, send any mail to "[EMAIL PROTECTED]" > -- Brian Szymanski [EMAIL PROTECTED] I prefer pgp encrypted email: keyid: 4E7A4703 server: keys.indymedia.org fingerprint: 5BD3 0B0C C8E3 0746 3550 5648 0CFE 1BE7 4E7A 4703 ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: portupgrade crash on 4.9-stable
Sweet, that did the trick. Thanks a bundle... Cheers, Brian > Hi Brian, > > Just add: > > ENV['PORTS_DBDRIVER'] = 'bdb1_hash' > > to your /usr/local/etc/pkgtools.conf. > > Ran into that yesterday and came across a page on the web that helped > me. > > Good luck. > > Cheers > -- > Ricardo Oliva > Core Systems Administrator > Zoology Department > University of British Columbia > Ph.: 604-822-3882 > E-mail: [EMAIL PROTECTED] > > On 17-Nov-04, at 1:21 PM, Brian Szymanski wrote: > >> Hi, I'm having a problem with portupgrade on 4.9: >> >> # portupgrade -f sudo\* >> Updating the ports index ... Generating INDEX.tmp - please wait.. Done. >> done >> [Updating the portsdb in /usr/ports ... - 11962 >> port >> entries found >> .1000.2000.3000.4000.5000.. >> ...6000.7000.8000../usr/local/lib/ruby/site_ruby/ >> 1.8/portsdb.rb:587: >> [BUG] Segmentation fault >> ruby 1.8.2 (2004-07-29) [i386-freebsd4] >> >> Abort trap (core dumped) >> >> I'm not sure why /usr/ports/INDEX isn't there anymore - it's a problem >> I'm >> having on all of my 4.x machines - everytime I cvsup portupgrade wants >> to >> generate an INDEX.tmp before it doesn anything... But the real problem >> is >> the segfault with ruby, which can be reliably reproduced ad infinitum. >> >> Any ideas? >> >> Thanks in advance. >> >> -- >> Brian Szymanski >> [EMAIL PROTECTED] >> >> I prefer pgp encrypted email: >> keyid: 4E7A4703 >> server: keys.indymedia.org >> fingerprint: 5BD3 0B0C C8E3 0746 3550 5648 0CFE 1BE7 4E7A 4703 >> >> >> ___ >> [EMAIL PROTECTED] mailing list >> http://lists.freebsd.org/mailman/listinfo/freebsd-stable >> To unsubscribe, send any mail to >> "[EMAIL PROTECTED]" > -- Brian Szymanski [EMAIL PROTECTED] I prefer pgp encrypted email: keyid: 4E7A4703 server: keys.indymedia.org fingerprint: 5BD3 0B0C C8E3 0746 3550 5648 0CFE 1BE7 4E7A 4703 ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
portupgrade crash on 4.9-stable
Hi, I'm having a problem with portupgrade on 4.9: # portupgrade -f sudo\* Updating the ports index ... Generating INDEX.tmp - please wait.. Done. done [Updating the portsdb in /usr/ports ... - 11962 port entries found .1000.2000.3000.4000.5000.6000.7000.8000../usr/local/lib/ruby/site_ruby/1.8/portsdb.rb:587: [BUG] Segmentation fault ruby 1.8.2 (2004-07-29) [i386-freebsd4] Abort trap (core dumped) I'm not sure why /usr/ports/INDEX isn't there anymore - it's a problem I'm having on all of my 4.x machines - everytime I cvsup portupgrade wants to generate an INDEX.tmp before it doesn anything... But the real problem is the segfault with ruby, which can be reliably reproduced ad infinitum. Any ideas? Thanks in advance. -- Brian Szymanski [EMAIL PROTECTED] I prefer pgp encrypted email: keyid: 4E7A4703 server: keys.indymedia.org fingerprint: 5BD3 0B0C C8E3 0746 3550 5648 0CFE 1BE7 4E7A 4703 ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
ad0 vs. ad0s1 (was Re: vinum troubles on 5.3)
> That's strange. What is the output of > > fdisk ad0 > bsdlabel ad0s1 > > Maybe something in GEOM gets confused... > > If the disappearing device node problem is fixed, gvinum should work in > this case. -bash-2.05b# bsdlabel ad0 # /dev/ad0s1: 8 partitions: #size offsetfstype [fsize bsize bps/cpg] b: 20971520 swap c: 802928070unused0 0 # "raw" part, don't edit e: 40146404 40146403 vinum f: 38049248 2097153 vinum -bash-2.05b# bsdlabel ad0s1 # /dev/ad0: 8 partitions: #size offsetfstype [fsize bsize bps/cpg] a: 40140800 401466684.2BSD0 0 0 b: 20971520 swap c: 802932480unused0 0 # "raw" part, don't edit e: 40146404 40146403 vinum f: 38049248 2097153 vinum [ I omitted fdisk output because it's very verbose - it's just a standard everything on the drive is freebsd type 165 dealie. ] When I tell bsdlabel to look at ad0, it doesn't see partition a. But when looking at ad0s1, it does. So I just told bsdlabel to add slice a on ad0s1 and things seem peachy keen (bsdlabel -e ad0s1) - I can't verify that this solves the (g)vinum problem since I need to get in to the bios to change boot settings and can't do that remotely. So that begs the question, what is the difference between ad0 and ad0s1 to these utilities, and what *should* it be? And, where on earth is the disklabel for "ad0" being saved, if not in ad0s1? Is it possibly overwriting something important, e.g. in the bootstrap code, which could explain the reason I was getting "not ufs" when I tried to boot with vinum? Other less relevant follow-ups below, thanks to all who helped: > A root mirrored configuration isn't that straightforward, imo :) But it > should work. It seemed straightforward on 4.x :-) >> Using vinum, I lose state information for the drive on ad2 after reboot - >> M2 is shown in "vinum l" output only as "referenced"... > > That is to be expected, as you discovered below... Why is this to be expected, because of gvinum? >> I originally was trying a complex configuration like so: >> drive A 200G >> drive B 200G >> drive C 100G >> drive D 100G >> >> I set the concat of drive all of drives C+D to be a volume makeshift, and >> added drive definition like so: >> drive MS /dev/gvinum/makeshift >> > Then, the idea was to do a raid5 of drives A, B, and "drive" MS. > I don't know if this is even possible. It's an interesting idea but even if it > works, recovery is totally non-trivial when either drive C or drive D goes > away. Plus, you'll surely take a huge performance hit because of the two vinum > layers you have to go through for every single access. Recovery is trivial when drive C or D goes. Since drives C and D form one raid-5 volume together, just chuck both drives and replace the makeshift drive with a new 200G drive. I am aware of and don't care about the performance hit. Cheers, Brian Szymanski [EMAIL PROTECTED] ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
vinum troubles on 5.3
Howdy... After a long and happy time with vinum under 4.8 -> 4.10, I'm finding things very broken in 5.3. The config I'm trying to accomplish is relatively simple, just a root mirrored volume configuration which worked under 4.x. drive M1 device /dev/ad0s1e drive M2 device /dev/ad2s1e volume root plex org concat sd length 19600m drive M1 plex org concat sd length 19600m drive M2 Using vinum, I lose state information for the drive on ad2 after reboot - M2 is shown in "vinum l" output only as "referenced"... Browsing some mailing lists I found that gvinum is the way to go these days, so I changed to using geom_vinum/gvinum, and the information is retained across boot, but when I try to boot to the root volume, it says that the drive is not UFS. When I boot on another partition to look at the situation, I found that there were no entries in /dev for /dev/ad0s1a. I wanted to create a ad0s1a entry with mknod, but of course we've got devfs now, so that didn't work. I'm stumped and not sure how to proceed. Any ideas? I originally was trying a complex configuration like so: drive A 200G drive B 200G drive C 100G drive D 100G I set the concat of drive all of drives C+D to be a volume makeshift, and added drive definition like so: drive MS /dev/gvinum/makeshift Then, the idea was to do a raid5 of drives A, B, and "drive" MS. Unfortunately this caused a panic, which is less surprising. Does anyone know of another way to accomplish the same thing (Raid5 over two disks and 2 half sized disks concatenated together?) or a similar result? Any help would be most appreciated. Cheers, Brian Szymanski [EMAIL PROTECTED] ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: setting kern.ngroups
On Tue, Mar 18, 2003 at 11:53:00AM -0500, Brandon S. Allbery KF8NH wrote: > On Tue, 2003-03-18 at 11:10, Brian Szymanski wrote: > > I'm having some trouble setting the (read-only) sysctl value kern.ngroups. > > Raising the maximum number of groups requires changes all over the > place; even if you find them all and rebuild the world (yes, libc > depends on it as well) you'll find that any program that looks at the > group vector will blow up because it only has space reserved for 16 > groups. You don't want to go there. Aren't these programs broken by not using NGROUPS_MAX from syslimits.h? Peace, Brian To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-stable" in the body of the message
setting kern.ngroups
Hi, I'm having some trouble setting the (read-only) sysctl value kern.ngroups. athlon system, running 4.x-stable. The reason I need to modify this value is for some software that requires user www to be in a lot of different groups, and the default value of 16 is insufficient. As per handbook section 6.9.1 "sysctl(8) read only", I've tried to modify the value by adding the line kern.ngroups="256" in /boot/loader.conf.local. When this boots up, I do a manual sysctl kern.ngroups, and it tells me 16 still... So I tried throwing the value straight in to /boot/defeaults/loader.conf... When I boot up, kern.ngroups is still at 16. I even tried editing /usr/src/sys/sys/syslimits.h and setting kern.ngroups to be 256 in the source. However, this results in some sort of bug in the kernel - when I reboot to a kernel compiled in this way, my machine dies trying to mount_msdos. I'm assuming that this is a sign of bad things happening in the kernel. I didn't actually try to boot further with this kernel. So, the question of the day is, what is the best way to set kern.ngroups? And, is 256 for some reason a "bad" value to set it to? If so, what value should I choose? I've also tried 128 with no success, and am working my way down to 16, but I'm not sure if I trust the kernel that I might get by compiling in such a way... Any help would be greatly appreciated. Thanks for reading, Brian Szymanski [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-stable" in the body of the message
