HighPoint RR 2640 support in 8.0-RELEASE?
Hello everyone, I recently upgraded to 8, and purchased a HighPoint RocketRAID 2640 card. Sadly I had remembered incorrectly that this was supported by either the hptrr or hptiop driver, and instead it seems to only be supported by a binary driver from HighPoint. However, the latest release of the driver is for 7.2, and although it kldload's correctly, I see in dmesg: module_register_init: MOD_LOAD (pci/rr26xx, 0x805a92e0, 0x81145ca0) error 22 rr26xx: RocketRAID 26xx controller driver v1.0.08.1230 (Jul 9 2009 13:58:26) rr26xx: no controller detected. it does not seem to work. Is there any hope of it being supported by the built-in drivers anytime soon, or is this an intentional oversight and do I have to wait for HighPoint to fix their drivers for 8.0? 03:00.0 SCSI storage controller: HighPoint Technologies, Inc. RocketRAID 2640 SAS/SATA Controller (rev 02) Thank you for any suggestions, Steven Schlansker___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to "freebsd-questions-unsubscr...@freebsd.org"
zfs raidz2 marked as UNAVAIL even though only one vdev is missing?
Hello, This morning I found that one of my disks was going bad, so I thought I would replace it (using zpool replace) with a new disk. This worked fine, and it was about 1/3 of the way through. Then, as I was moving things around, I accidentally jostled some of the cables. This of course made the system extremely unhappy and eventually resulted in a kernel panic. Then when I tried to bring the system back up, it reported the pool as FAULTED due to missing devices. Figuring that it just needed to "re-discover" the devices and considering that every zpool / zfs command was unavailable, I decided to export and re-import the pool. However, now the pool is not importable! The status shows (typed since no SSH access): pool: universe id: (uuid) state: UNAVAIL action: The pool cannot be imported due to damaged devices or data config: universe UNAVAIL insufficient replicas raidz2 UNAVAIL corrupted data replacing DEGRADED (uuid) UNAVAIL cannot open ad16 ONLINE ad10 ONLINE ad8 ONLINE ... five more drives, all ONLINE To my eye, there should be no reason it can't import. The drives are all marked ONLINE except for the one I know failed. I can't zpool status -v to see *what* is corrupted because I can't import. So here I am, stuck, unable to import. Any suggestions as to how I can recover from this situation? Any way to tell what is corrupted so I can maybe intentionally fail that disk and allow a scrub to recreate it? Thanks for any advice, Steven Schlansker___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to "freebsd-questions-unsubscr...@freebsd.org"
zfs raidz2 marked as UNAVAIL even though only one vdev is missing?
Hello, This morning I found that one of my disks was going bad, so I thought I would replace it (using zpool replace) with a new disk. This worked fine, and it was about 1/3 of the way through. Then, as I was moving things around, I accidentally jostled some of the cables. This of course made the system extremely unhappy and eventually resulted in a kernel panic. Then when I tried to bring the system back up, it reported the pool as FAULTED due to missing devices. Figuring that it just needed to "re-discover" the devices and considering that every zpool / zfs command was unavailable, I decided to export and re-import the pool. However, now the pool is not importable! The status shows (typed since no SSH access): pool: universe id: (uuid) state: UNAVAIL action: The pool cannot be imported due to damaged devices or data config: universe UNAVAIL insufficient replicas raidz2 UNAVAIL corrupted data replacing DEGRADED (uuid) UNAVAIL cannot open ad16 ONLINE ad10 ONLINE ad8 ONLINE ... five more drives, all ONLINE To my eye, there should be no reason it can't import. The drives are all marked ONLINE except for the one I know failed. I can't zpool status -v to see *what* is corrupted because I can't import. So here I am, stuck, unable to import. Any suggestions as to how I can recover from this situation? Any way to tell what is corrupted so I can maybe intentionally fail that disk and allow a scrub to recreate it? Thanks for any advice, Steven Schlansker___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to "freebsd-questions-unsubscr...@freebsd.org"
Re: Reproduce previous stdout output without running previous command
On Jun 8, 2009, at 8:48 PM, Lord Of Hyphens wrote: On Mon, Jun 8, 2009 at 10:44 PM, Daniel Underwood >wrote: $ fdupes -r ~/directorywithlotsoflargefiles (.lots of output, woops, should have sent to a text file!) $ output[1] >> ~/textfile.txt Hopefully this has made (some) sense. Check the manpage for tee. That should give you a solution you're looking for. I think the intention of the original question was for the case where you have forgotten to set up a pipe/redirection properly before starting the long- running command. Tee would work fine if you have the foresight to use it... Steven ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to "freebsd-questions-unsubscr...@freebsd.org"
Re: how do i use gdb with < input?
On Jun 5, 2009, at 8:33 PM, Gary Kline wrote: i'm trying to walk thru a short program and see what's actually happening. can anybody remind me how to send a file file "< redirect" to ./ a.out? gdb myprog (gdb) run < myfile ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to "freebsd-questions-unsubscr...@freebsd.org"
Re: Waiting for a process to die
Chris Rees wrote: [ `ps ax |grep pid | wc -l ` = 1 ] && (echo "done!" | Mail -s "PROC DONE" kelly.terry.jo...@gmail.com) Not always going to work. For example, [ste...@scs:~]% ps ax | grep init 1 ?Ss 0:39 init [2] 13421 pts/1R+ 0:00 grep init Also if you use its pid, 1, you get a whole bunch of uninteresting processes as you're grepping for "1" ;) [ste...@scs:~]% ps ax | grep 1 | wc -l 94 ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to "freebsd-questions-unsubscr...@freebsd.org"
Re: pfsync in GENERIC?
On May 29, 2009, at 5:29 PM, Michael Powell wrote: Steven Schlansker wrote: [snip] A custom kernel can free up a little RAM, and maybe boot a little sooner, but it won't produce any earth shattering differences. I think most do it to 'shrink' down and eliminate anything which is not required for a particular piece of hardware. It decreases the possibility of something unneeded causing a problem, and enhances problem resolution by making the list of potential culprits smaller. Yeah, that's basically how I felt as well. However as to the "something unneeded causing a problem" I must say I've never had a GENERIC kernel fail due to some unneeded device driver, but I've definitely had a custom built kernel fail because of some tunable or driver I misconfigured! I'm just thinking that since pf is included in the base distribution, there's enough people that use it that it's worth including. It seems that pfsync would be a negligible addon, and much more attractive due to the lack of support for building it as a module. IIRC, quite a while back IPFW was the default firewall and was included in GENERIC by default. With the advent of IPFILTER and PF we now have 3 to choose from. Since theoretically(?) each should be usable as modules and user freedom/choice are paramount, I believe it was decided to remove any default firewall from the GENERIC kernel to enable a user to simply load the module of their choice without needing to do a kernel re-compile first. In other words, flexibility. That makes perfect sense and answers my question. I hadn't realized that there were alternatives to pf and that people still actively used them. Anyway, if I have further questions about pfsync in particular I guess I'll go ask -pf. I may have some free time coming up; maybe I'll even try my hand at hacking on the kernel and see if I can't make it build as a module... (would that be a semi-reasonable project for someone with light familiarity with kernel coding? I've coded up Linux kernel modules before, but haven't worked in-tree on a "real" OS) I believe the module situation may be a known entity. Consult the PR bug reports for more details. At some point a dev may take care of the situation and it will just show up in some future release. There is no PR apparently; I shall file one. Should you desire to "hack" into it yourself and succeed the devs will welcome the patch/diffs for perusal and testing provided you go about it the right way. Advancing the state of FreeBSD is always a plus, and I as a user salute all those who strive and work towards making FreeBSD a better OS. I like to try to be one of the more useful retards on the internet ;) I'm hopeful that getting it to work at least for the unicast setup shouldn't be too hard; granted I haven't perused the code yet... ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to "freebsd-questions-unsubscr...@freebsd.org"
Re: pfsync in GENERIC?
On May 29, 2009, at 1:44 PM, Mel Flynn wrote: On Friday 29 May 2009 20:38:54 Steven Schlansker wrote: And not to be argumentative, but sys/conf/NOTES does not really provide any information. The only comment explains what the device does, not why it wouldn't be enabled in GENERIC. Is there any reason it could not be? (For those of us who want to use freebsd-update, for example) Choice of the project. You'd have to ask on -current, -pf or - hackers for a more authoritative answer, but my guess would be that 80% of the people using this feature in production have a highly optimized kernel and wouldn't be using GENERIC to begin with. Hm. I was actually under the impression that you wouldn't gain much by compiling your own kernel (except for maybe some disk space). Is that not the case? Is there a strong reason to compile your own kernel for "production" machines? The discussion online is not conclusive (then again I'll probably just get contradictory opinions again here!) I'm just thinking that since pf is included in the base distribution, there's enough people that use it that it's worth including. It seems that pfsync would be a negligible addon, and much more attractive due to the lack of support for building it as a module. Anyway, if I have further questions about pfsync in particular I guess I'll go ask -pf. I may have some free time coming up; maybe I'll even try my hand at hacking on the kernel and see if I can't make it build as a module... (would that be a semi-reasonable project for someone with light familiarity with kernel coding? I've coded up Linux kernel modules before, but haven't worked in-tree on a "real" OS) Best, Steven ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to "freebsd-questions-unsubscr...@freebsd.org"
Re: pfsync in GENERIC?
On May 29, 2009, at 11:01 AM, Mel Flynn wrote: On Friday 29 May 2009 18:19:52 Steven Schlansker wrote: [ste...@gateway2:~]% sudo /etc/rc.d/pfsync start /etc/rc.d/pfsync: WARNING: pfsync(4) must be statically compiled in the kernel. Is pfsync not in GENERIC? I checked the amd64 config file and indeed it does not show up, however pf and pflog are not there either but are usable in the base system, so I am not positive that pfsync being missing is therefore conclusive. I would like to if at all possible use GENERIC so that I can take advantage of freebsd-update etc. Is there some way to get this all running without recompiling the kernel? No, the error message is clear. pfsync cannot currently be loaded as kernel module and it's not in GENERIC. The same goes for altq. See sys/conf/ NOTES for details. Ah, now I get it. I'm used to the Linux way of configuring modules where if a device is a module, it still appears in the configuration file. So I was interpreting the missing "pf" and "pflog" entries not as "built as a module" but as "missing, why can I still use them?" And not to be argumentative, but sys/conf/NOTES does not really provide any information. The only comment explains what the device does, not why it wouldn't be enabled in GENERIC. Is there any reason it could not be? (For those of us who want to use freebsd-update, for example) By digging around on the internet it seems that the problem arises from the use of multicast protocols (ref: http://lists.freebsd.org/pipermail/freebsd-pf/2005-October/001521.html) . pfsync allows the use of unicast as well - would it be feasible to have a modular version that only supports unicast (via syncpeer) perhaps? There's not been much of a discussion about this since 2005, it seems. I'm curious as to that the prevailing opinion is. FYI: On -current it's still not possible to load as a module. ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to "freebsd-questions-unsubscr...@freebsd.org"
pfsync in GENERIC?
Hello freebsd-questions, I'm attempting to set up a redundant NAT system where failover is provided by ucarp and using pfsync to keep NAT tables in sync. When I try to set up pfsync, [ste...@gateway2:~]% sudo /etc/rc.d/pfsync start /etc/rc.d/pfsync: WARNING: pfsync(4) must be statically compiled in the kernel. [ste...@gateway2:~]% ifconfig pfsync0 ifconfig: interface pfsync0 does not exist additionally: [ste...@gateway2:~]% sudo ifconfig pfsync0 create ifconfig: SIOCIFCREATE2: Invalid argument Is pfsync not in GENERIC? I checked the amd64 config file and indeed it does not show up, however pf and pflog are not there either but are usable in the base system, so I am not positive that pfsync being missing is therefore conclusive. I would like to if at all possible use GENERIC so that I can take advantage of freebsd-update etc. Is there some way to get this all running without recompiling the kernel? (You may notice I'm using ucarp instead of carp to avoid recompiling) Thank you for any guidance, Steven Schlansker ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to "freebsd-questions-unsubscr...@freebsd.org"
Using ccd with zfs
Hello -questions, I have a FreeBSD ZFS storage system working wonderfully with 7.0. It's set up as three 3-disk RAIDZs -triplets of 500, 400, and 300GB drives. I recently purchased three 750GB drives and would like to convert to using a RAIDZ2. As ZFS has no restriping capabilities yet, I will have to nuke the zpool from orbit and make a new one. I would like to verify my methodology against your experience to see if what I wish to do is reasonable: I plan to first take 2 of the 750GB drives and make an unreplicated 1.5TB zpool as a temporary storage. Since ZFS doesn't seem to have the ability to create zpools in degraded mode (with missing drives) I plan to use iSCSI to create two additional drives (backed by /dev/ zero) to fake having two extra drives, relying on ZFS's RAIDZ2 protection to keep everything running despite the fact that two of the drives are horribly broken ;) To make these 500, 400, and 300GB drives useful, I would like to stitch them together using ccd. I would use it as 500+300 = 800GB and 400+400=800GB That way, in the end I would have 750 x 3 500 + 300 x3 400 + 400 x 1 400 + 200 + 200 x 1 as the members in my RAIDZ2 group. I understand that this is slightly less reliable than having "real" drives for all the members, but I am not interested in purchasing 5 more 750GB drives. I'll replace the drives as they fail. I am wondering if there are any logistical problems. The three parts I am worried about are: 1) Are there any problems with using an iSCSI /dev/zero drive to fake drives for creation of a new zpool, with the intent to replace them later with proper drives? 2) Are there any problems with using CCD under zpool? Should I stripe or concatenate? Will the startup scripts (either by design or less likely intelligently) decide to start CCD before zfs? The zpool should start without me interfering, correct? 3) I hear a lot about how you should use whole disks so ZFS can enable write caching for improved performance. Do I need to do anything special to let the system know that it's OK to enable the write cache? And persist across reboots? Any other potential pitfalls? Also, I'd like to confirm that there's no way to do this pure ZFS-like - I read the documentation but it doesn't seem to have support for nesting vdevs (which would let me do this without ccd) Thanks for any information that you might be able to provide, Steven Schlansker ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to "[EMAIL PROTECTED]"
