ext4 change in v3.3-rc2 broke user space
Specifically this change: http://git.kernel.org/cgit/linux/kernel/git/stable/linux-stable.git/commit/?id=d1f5273e9adb40724a85272f248f210dc4ce919a This change has broken gluster when using ext4 as the backing filesystem. Details are here: http://www.gluster.org/2012/08/glusterfs-bit-by-ext4-structure-change/ The change is about a year old now but it is finally making its way into distribution binaries. As a user it sucks because "ext4" the "stable" fs basically breaks. Fortunately for myself I've used xfs as suggested by GlusterFS (older versions stated ext4/ext3 was fine). However, there are many installs (particularly older installs) that used ext4 and are finding they must now run outdated old kernels until they can completely reinstall their gluster cluster with non-ext4 underlying filesystems. Another side effect is users like myself dealing with the fallout on mailinglists. I've run across this issue on glusterfs maillinglist (obviously) and also cloudstack. It is so damn annoying to tell people a kernel change screwed up gluster and that is why their cluster is busted. To be frank, most will just assume kernel would never do such a bad thing and it is nonsense that the kernel is to blame. This sucks. I'm not hear to bitch (well maybe a little) but I hope changes like this STOP happening. I think the biggest blame is on RedHat for backporting the above patch and pushing out kernel binaries before a workaround in kernel-land was found. On the other hand - a work-around should have been part of the original patch. I'm resigned to the fact there is NO hope of this being fixed since everyone has moved on and it has been accepted for so long. Damnit. If ext4 is seriously this much in flux - I'd like to politely suggest it is marked experimental, non-prod, or dangerous. -Bryan -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
ext4 change in v3.3-rc2 broke user space
Specifically this change: http://git.kernel.org/cgit/linux/kernel/git/stable/linux-stable.git/commit/?id=d1f5273e9adb40724a85272f248f210dc4ce919a This change has broken gluster when using ext4 as the backing filesystem. Details are here: http://www.gluster.org/2012/08/glusterfs-bit-by-ext4-structure-change/ The change is about a year old now but it is finally making its way into distribution binaries. As a user it sucks because ext4 the stable fs basically breaks. Fortunately for myself I've used xfs as suggested by GlusterFS (older versions stated ext4/ext3 was fine). However, there are many installs (particularly older installs) that used ext4 and are finding they must now run outdated old kernels until they can completely reinstall their gluster cluster with non-ext4 underlying filesystems. Another side effect is users like myself dealing with the fallout on mailinglists. I've run across this issue on glusterfs maillinglist (obviously) and also cloudstack. It is so damn annoying to tell people a kernel change screwed up gluster and that is why their cluster is busted. To be frank, most will just assume kernel would never do such a bad thing and it is nonsense that the kernel is to blame. This sucks. I'm not hear to bitch (well maybe a little) but I hope changes like this STOP happening. I think the biggest blame is on RedHat for backporting the above patch and pushing out kernel binaries before a workaround in kernel-land was found. On the other hand - a work-around should have been part of the original patch. I'm resigned to the fact there is NO hope of this being fixed since everyone has moved on and it has been accepted for so long. Damnit. If ext4 is seriously this much in flux - I'd like to politely suggest it is marked experimental, non-prod, or dangerous. -Bryan -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Disableing USB.
> Er... Well, the traditional solution has been "don't build it into your > kernel if you don't want it", but in the case of stock kernels, that > isn't always an option, I suppose. Theoretically, the two devices > shouldn't step on each other, but this is a computer. Theory is so far > removed from practice that it's... Well, I can't think up a good > analogy. It's far. > > *looks at kernel config options* > > Well, it looks like the usb cores (UHCI and OHCI) can be modular. Why > aren't they in the stock kernel, other than possibly autodetection > problems? If they are built as modules, using expert mode in RedHat or > whatever equivalent may be in other dists may let you avoid insmodding > the USB stuff... Nope. Expert just means you'll be doing allot of stuff manually, Like partitioning, package selection, configureing X, and some net stuff. > Beyond that, having a command-line disable feature does seem pretty > neat. Although why would you want to disable procfs? Maybe I missed > something there, but it seems awful darn important to leave out. :-) I was just using that as an example. Being able to disbale whatever part of the kernel you want might be really helpfull in many cases... Maybe procfs was a bad example... :P -- --- Bryan Whitehead Email: [EMAIL PROTECTED] WorkE: [EMAIL PROTECTED] - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: Disableing USB.
Er... Well, the traditional solution has been "don't build it into your kernel if you don't want it", but in the case of stock kernels, that isn't always an option, I suppose. Theoretically, the two devices shouldn't step on each other, but this is a computer. Theory is so far removed from practice that it's... Well, I can't think up a good analogy. It's far. *looks at kernel config options* Well, it looks like the usb cores (UHCI and OHCI) can be modular. Why aren't they in the stock kernel, other than possibly autodetection problems? If they are built as modules, using expert mode in RedHat or whatever equivalent may be in other dists may let you avoid insmodding the USB stuff... Nope. Expert just means you'll be doing allot of stuff manually, Like partitioning, package selection, configureing X, and some net stuff. Beyond that, having a command-line disable feature does seem pretty neat. Although why would you want to disable procfs? Maybe I missed something there, but it seems awful darn important to leave out. :-) I was just using that as an example. Being able to disbale whatever part of the kernel you want might be really helpfull in many cases... Maybe procfs was a bad example... :P -- --- Bryan Whitehead Email: [EMAIL PROTECTED] WorkE: [EMAIL PROTECTED] - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Disableing USB.
Is there a way I can disble a part of the kernel that is compiled into the kernel? For example I'd like to pass this to lilo: "usb=disable" and then the usb code is not loaded even though USB has been built into the kernel. Is such a feature stupid? Or has this already been implemented? It would be nice if this was generic and I could also pass things like "procfs=disabled". The resone I ask is a friend of mine got a new Sony Vaio Laptop that has the ethernet card and USB device stepping on eachother. It would be nice to pass to the Redhat/Mandrake/whatever installation boot disk usb=disable so the ethernet card can work freely (he's doiung a ntwork install becasue he has no CD-ROM), as he doesn't use any USB devices anyway. -- --- Bryan Whitehead Email: [EMAIL PROTECTED] WorkE: [EMAIL PROTECTED] - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Disableing USB.
Is there a way I can disble a part of the kernel that is compiled into the kernel? For example I'd like to pass this to lilo: "usb=disable" and then the usb code is not loaded even though USB has been built into the kernel. Is such a feature stupid? Or has this already been implemented? It would be nice if this was generic and I could also pass things like "procfs=disabled". The resone I ask is a friend of mine got a new Sony Vaio Laptop that has the ethernet card and USB device stepping on eachother. It would be nice to pass to the Redhat/Mandrake/whatever installation boot disk usb=disable so the ethernet card can work freely (he's doiung a ntwork install becasue he has no CD-ROM), as he doesn't use any USB devices anyway. -- --- Bryan Whitehead Email: [EMAIL PROTECTED] WorkE: [EMAIL PROTECTED] - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: RAID HW Questions...
On Sun, 17 Sep 2000, Ricky Beam wrote: > I used to have the respect for DPT. Well, there's one more fine company > ruined. I guess I caught the tail end of DPT being nice. When i got the card it was highly recommended. > The root problem is that you don't know what to do to get it working. There's > nothing wrong with that aside from you storming into lkml as if you knew > what you were doing (your little "resumette") but couldn't get anything to > work "for 6 months." [2.2.15 was the latest kernel six months ago. The > 1.09 driver from DPT drops directly into 2.2.15 without modification.] I'm sorry for what I said. I'm just used to being able to easily contact the author of software I'm working on wether they are still around or have moved on. I was frustrated and tiered. The machine there DPT cards are on are actually a community college where I do vollenteer sysadming for about 30 machines. This gives an entire lab of machines running Linux for CS students. I only get 2-3 hours a week (if that) of actual time to keep the lab up. Last friday I took a day off to finally complete the move to the new kernel becasue of hacking attempts from students. I've tried off and on for the past 6 months trying to get help from DPT/Adaptec because I was always running into problems. And you know the rest of the story. I wish I was more of kernel hacker but I'm basically a "patch and build" guy when it comes to Linux. RT VxWorks on PPC is where all my hard-core development goes. :| Sorry for causing problems and thanks for your help. --- Bryan Whitehead Email: [EMAIL PROTECTED] WorkE: [EMAIL PROTECTED] - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: RAID HW Questions...
http://www.rccacm.org/~driver/dpt1.14-2.2.16.tar.bz2 A guy in the down under (.au) sent me this driver. Aparently Adaptec developes their OpenSource driver privatly and only gives out copies to "special" customers. It works in 2.2.16 and 2.2.17 :)) 6 months of hell has come (mostly) to an end. On Sat, 16 Sep 2000, Alan Cox wrote: > > One of the primary reasons for use the DPT driver is to use the DPT RAID > > mananger. The Linux I2O code doesn't (currently) have that support. It > > could be added later, but someone's got to get the card to work with the > > DPT don't do standard I2O block management. Linux supports the standard stuff > including configuring your raid card with a web browser > > -- --- Bryan Whitehead Email: [EMAIL PROTECTED] WorkE: [EMAIL PROTECTED] - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: RAID HW Questions...
On Sun, 17 Sep 2000, Ricky Beam wrote: I used to have the respect for DPT. Well, there's one more fine company ruined. I guess I caught the tail end of DPT being nice. When i got the card it was highly recommended. The root problem is that you don't know what to do to get it working. There's nothing wrong with that aside from you storming into lkml as if you knew what you were doing (your little "resumette") but couldn't get anything to work "for 6 months." [2.2.15 was the latest kernel six months ago. The 1.09 driver from DPT drops directly into 2.2.15 without modification.] I'm sorry for what I said. I'm just used to being able to easily contact the author of software I'm working on wether they are still around or have moved on. I was frustrated and tiered. The machine there DPT cards are on are actually a community college where I do vollenteer sysadming for about 30 machines. This gives an entire lab of machines running Linux for CS students. I only get 2-3 hours a week (if that) of actual time to keep the lab up. Last friday I took a day off to finally complete the move to the new kernel becasue of hacking attempts from students. I've tried off and on for the past 6 months trying to get help from DPT/Adaptec because I was always running into problems. And you know the rest of the story. I wish I was more of kernel hacker but I'm basically a "patch and build" guy when it comes to Linux. RT VxWorks on PPC is where all my hard-core development goes. :| Sorry for causing problems and thanks for your help. --- Bryan Whitehead Email: [EMAIL PROTECTED] WorkE: [EMAIL PROTECTED] - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: RAID HW Questions...
On Sat, 16 Sep 2000, Ricky Beam wrote: > This is true of _any_ binary module. That's why I never use binary modules. That's why I don't want to use them either. > Have you bothered tell us what that error is? I've not seen anything on > dpt's mail-list. (Which is where this should be discussed.) I've emailed [EMAIL PROTECTED] (that's what the linuxi2oreadme.txt says to do for help) MANY times pleading for help. i asked for Phone#'s, web pages, ftp sites, and yes email lists. I've yet to get a reply in 6 months of asking. > Yes they do. You just are talking to the right people. (Maybe those "right > people" aren't there anymore. DPT is now an Adaptec company, remember.) If I can call and email for 6 months and never get a reply that means they DON'T care in my book. > Point of fact: There _are_ people using >2.2.12 with the DPT driver. > Point of fact: There _are_ people usin 2.4 with the DPT driver. You know what? I REALLY hope I'm wrong. I really do. I hope it was sitting in front of me the whole time. Please please please tell me where I can get it. (and 2.2.12 isn't good enough). > I'm the one who made it work at 2.3.33... I sent those changes to DPT and > mailed several lists. > > (http://chickenboo.bluetopia.net/~jfbeam/DPT/) Great! What about 2.2.17? ot 2.4.0(test) ? I really don't care much about 2.3.33. > For starters, you can tell us exactly what the hell your problem is. Blow > off all the steam you want, but no one can help you until you tell us your > specific problem. He's something to start on: If you want full build logs let me know. They may take awile to get. (I'd rather not work on the weekend). I have 2 systems. one in production, one just sitting around for me to mess with. They both have the same exact software. I'll show the current configuration from the production machine using the binary drivers from DPT. BTW this is where I got the drivers: ftp://ftp.adaptec.com/raid/dpt/SRV/software/drivers/linux/ here is my sysinfo (same as what you put out). uname -a Linux www.rccacm.org 2.2.5-22smp #1 SMP Wed Jun 2 09:11:51 EDT 1999 i686 unknown gcc -v Reading specs from /usr/lib/gcc-lib/i586-mandrake-linux/2.95.2/specs gcc version 2.95.2 19991024 (release) cat /proc/scsi/dpt/1 Vendor: DPT Model: PM2554U2 Rev: 211D, scsi 1: DPT I2O Driver Version: 1.06/1.1: cmd_per_lun = 210, max_id = 15, max_lun = 7, max_channel = 0 sg_tablesize = 39, irq = 18, OutstandingMsgs = 0 maxfromiopmsgs = 64, maxtoiopmsgs = 210 Devices: Channel = 0, Target = 1, Lun = 0 cat /proc/scsi/scsi Attached devices: Host: scsi0 Channel: 00 Id: 00 Lun: 00 Vendor: QUANTUM Model: ATLAS IV 9 WLS Rev: 0808 Type: Direct-AccessANSI SCSI revision: 03 Host: scsi1 Channel: 00 Id: 01 Lun: 00 Vendor: DPT Model: RAID-5 Rev: 211D Type: Direct-AccessANSI SCSI revision: 02 Now for the Building. This is using 2.2.17 Kernel. The errors are the same for the previous Kernels as well. I patched in the 109patch.gz file found in the FTP site I gave you. (As it's stated to do in the readme - you neet to d/l dpti2olinux.zip to get the linuxi2oreadme.txt). At the very end of the .txt file it states a error I *might* get. i get that one. This is what it says: Q: When attempting to compile my kernel, I am getting lots of error such as: drivers/scsi/scsi.a(dpt_i2o.o): In function `dpt_add_timer': dpt_i2o.o(.text+0x10): undefined reference to `del_timer_Rsmp_5811f067' A: This is an error seen when using a compiler newer than gcc 2.7.2. Use gcc 2.7.2 or older. I've used gcc 2.7.2 and get the same results. :( Another wierd thing is even though they have a "patch" for this card they give instructions to manually edit it a .h file they forgot to include. -- --- Bryan Whitehead Email: [EMAIL PROTECTED] WorkE: [EMAIL PROTECTED] - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: RAID HW Questions...
On Sat, 16 Sep 2000, Alan Cox wrote: > > Well. Since DPT rammed me in the ass with their "SmartRAID V" RAID I need > > to buy a new RAID card. I don't know who to trust. I was told (about 1 > > year ago) that DPT was the Co. that liked/worked with the linux community. > > Obviously they don't. I don't a driver for over $12,000 in RAID HW. So, > > The driver should be on DPT's site. Im not sure on the current state with the > DPT decade/century/millenium series but source (ugly or otherwise) is around > and I am hoping to get it merged once some headers have been cleaned up. The driver directory is on thier web site. true. But it only works for specific versions of kernel's from RH. They do have the sources available also. The problem comes when compiling. They specifically say not to use Linux's i2o stuff. Fine. They claim they have their "own" i2o implementaion. But it won't build, actually it won;t link. After looking at the FAQ more they say I need to build with gcc version 2.7.2. Becasue their driver only works with that. So i remove the gcc from my system and install an old gcc / linker. no change. Still the same damn error. It's not like I'm some stupid moron (i wish that were the case then I'd be able to ask someone else WTF the problem is and they could answer). I'm a sysadmin at JPL and am responsible for (in our section) all our builds of GNU software. Plus I manage all the Linux machines. To top it off I do development for Mission and Control for NASA's Deep Space network. So i'm used to building wierd-ass stuff and getting it workin. I've worked so long and hard on this problem I finally gave up and want to buy a new card. i'm sick of the bitches at DPT not responding to my email and giving me no help. I'm not going to run that crap ass 2.2.5 kernel or the 2.2.12 kernel from RH (the only kernels they support according to the web page). I need to have at LEAST 2.2.16 for security resons. But they don't give a crap. If Linux can get the card working with they native i2o drivers then great. I'd be very happy with that. But I've waited for 6 months now and I'm to the point I don't mind blowing another $10,000 in taxpayers money to get the fsck'n RAID working in 2.2.17 land and hopefully 2.4 soon. > > > supported, I mean not some crap ass driver written by an intern. I want > > something that inspires love from the author. I want a driver that works. > > > > Who out there (for the HW RAID stuff) really works with the Linux Kernel > > Developers? ie What HW vendor? > > Currently in kernel > --- > IBM write their own drivers for the ServeRAID > AMI/DELL for the MegaRAID > Mylex help Leonard Zubkoff with the DAC960 driver > Compaq write their own drivers for the SMART2 and ISS interfaces > ICP Vortex have been doing their own drivers for their cards back since > 1996 (1.2.13) > DPT have been heling with their older SmartRAID cards and there are drivers > in kernel > > and I may have forgotten some. > > The current I2O based smartraid stuff got tangled in some I2O sig sillies about > copyrights on their own header files but thats something I talked with > DPT about and not that hard to fix All I gatta say is thier driver is a piece of crap. I'll use Linux's i2o if it works but I'm not using there crap. I'v lost all respect and trust from DPT and they will not get any of MY money/budget. If you would like me to try *ANYTHING* out to aid in getting the Card working I'm all yours. I'm a bit burned out but hell, If you think it's not that far away. Then who am i to argue? > > > -- --- Bryan Whitehead Email: [EMAIL PROTECTED] WorkE: [EMAIL PROTECTED] - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: RAID HW Questions...
On Sat, 16 Sep 2000, Ricky Beam wrote: This is true of _any_ binary module. That's why I never use binary modules. That's why I don't want to use them either. Have you bothered tell us what that error is? I've not seen anything on dpt's mail-list. (Which is where this should be discussed.) I've emailed [EMAIL PROTECTED] (that's what the linuxi2oreadme.txt says to do for help) MANY times pleading for help. i asked for Phone#'s, web pages, ftp sites, and yes email lists. I've yet to get a reply in 6 months of asking. Yes they do. You just are talking to the right people. (Maybe those "right people" aren't there anymore. DPT is now an Adaptec company, remember.) If I can call and email for 6 months and never get a reply that means they DON'T care in my book. Point of fact: There _are_ people using 2.2.12 with the DPT driver. Point of fact: There _are_ people usin 2.4 with the DPT driver. You know what? I REALLY hope I'm wrong. I really do. I hope it was sitting in front of me the whole time. Please please please tell me where I can get it. (and 2.2.12 isn't good enough). I'm the one who made it work at 2.3.33... I sent those changes to DPT and mailed several lists. (http://chickenboo.bluetopia.net/~jfbeam/DPT/) Great! What about 2.2.17? ot 2.4.0(test) ? I really don't care much about 2.3.33. For starters, you can tell us exactly what the hell your problem is. Blow off all the steam you want, but no one can help you until you tell us your specific problem. He's something to start on: If you want full build logs let me know. They may take awile to get. (I'd rather not work on the weekend). I have 2 systems. one in production, one just sitting around for me to mess with. They both have the same exact software. I'll show the current configuration from the production machine using the binary drivers from DPT. BTW this is where I got the drivers: ftp://ftp.adaptec.com/raid/dpt/SRV/software/drivers/linux/ here is my sysinfo (same as what you put out). uname -a Linux www.rccacm.org 2.2.5-22smp #1 SMP Wed Jun 2 09:11:51 EDT 1999 i686 unknown gcc -v Reading specs from /usr/lib/gcc-lib/i586-mandrake-linux/2.95.2/specs gcc version 2.95.2 19991024 (release) cat /proc/scsi/dpt/1 Vendor: DPT Model: PM2554U2 Rev: 211D, scsi 1: DPT I2O Driver Version: 1.06/1.1: cmd_per_lun = 210, max_id = 15, max_lun = 7, max_channel = 0 sg_tablesize = 39, irq = 18, OutstandingMsgs = 0 maxfromiopmsgs = 64, maxtoiopmsgs = 210 Devices: Channel = 0, Target = 1, Lun = 0 cat /proc/scsi/scsi Attached devices: Host: scsi0 Channel: 00 Id: 00 Lun: 00 Vendor: QUANTUM Model: ATLAS IV 9 WLS Rev: 0808 Type: Direct-AccessANSI SCSI revision: 03 Host: scsi1 Channel: 00 Id: 01 Lun: 00 Vendor: DPT Model: RAID-5 Rev: 211D Type: Direct-AccessANSI SCSI revision: 02 Now for the Building. This is using 2.2.17 Kernel. The errors are the same for the previous Kernels as well. I patched in the 109patch.gz file found in the FTP site I gave you. (As it's stated to do in the readme - you neet to d/l dpti2olinux.zip to get the linuxi2oreadme.txt). At the very end of the .txt file it states a error I *might* get. i get that one. This is what it says: Q: When attempting to compile my kernel, I am getting lots of error such as: drivers/scsi/scsi.a(dpt_i2o.o): In function `dpt_add_timer': dpt_i2o.o(.text+0x10): undefined reference to `del_timer_Rsmp_5811f067' A: This is an error seen when using a compiler newer than gcc 2.7.2. Use gcc 2.7.2 or older. I've used gcc 2.7.2 and get the same results. :( Another wierd thing is even though they have a "patch" for this card they give instructions to manually edit it a .h file they forgot to include. -- --- Bryan Whitehead Email: [EMAIL PROTECTED] WorkE: [EMAIL PROTECTED] - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
RAID HW Questions...
Well. Since DPT rammed me in the ass with their "SmartRAID V" RAID I need to buy a new RAID card. I don't know who to trust. I was told (about 1 year ago) that DPT was the Co. that liked/worked with the linux community. Obviously they don't. I don't a driver for over $12,000 in RAID HW. So, What RAID card (for RAID 5 or 0/1) is supported under linux? When I mean supported, I mean not some crap ass driver written by an intern. I want something that inspires love from the author. I want a driver that works. Something I don't need to worry about through Kernel version 3.x.x. In other words, something GPLed and Open. I don't care who makes the card, I just want it to be well supported in Linux. (I also Obviously want something fast etc). To sum up: Who out there (for the HW RAID stuff) really works with the Linux Kernel Developers? ie What HW vendor? If this seems a bit offtopic then please just reply off-list. (I do subscribe and have been reading for under a year now). --- Bryan Whitehead UTA - Space and Science Division. Email: [EMAIL PROTECTED] WorkE: [EMAIL PROTECTED] - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
RAID HW Questions...
Well. Since DPT rammed me in the ass with their "SmartRAID V" RAID I need to buy a new RAID card. I don't know who to trust. I was told (about 1 year ago) that DPT was the Co. that liked/worked with the linux community. Obviously they don't. I don't a driver for over $12,000 in RAID HW. So, What RAID card (for RAID 5 or 0/1) is supported under linux? When I mean supported, I mean not some crap ass driver written by an intern. I want something that inspires love from the author. I want a driver that works. Something I don't need to worry about through Kernel version 3.x.x. In other words, something GPLed and Open. I don't care who makes the card, I just want it to be well supported in Linux. (I also Obviously want something fast etc). To sum up: Who out there (for the HW RAID stuff) really works with the Linux Kernel Developers? ie What HW vendor? If this seems a bit offtopic then please just reply off-list. (I do subscribe and have been reading for under a year now). --- Bryan Whitehead UTA - Space and Science Division. Email: [EMAIL PROTECTED] WorkE: [EMAIL PROTECTED] - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
