[DRBD-user] Re: heartbeat 2.0.8: lockups kerneloops

Ross S. W. Walker rwalker at medallion.com
Sun Feb 25 21:15:30 CET 2007

Note: "permalinks" may not be as permanent as we would like,
direct links of old sources may well be a few messages off.


> -----Original Message-----
> From: Gerry Reno [mailto:greno at verizon.net] 
> Sent: Sunday, February 25, 2007 2:31 PM
> To: Ross S. W. Walker
> Cc: drbd-user at lists.linbit.com
> Subject: Re: [DRBD-user] Re: heartbeat 2.0.8: lockups kerneloops
> 
> Ross S. W. Walker wrote:
> > Yes, well 2.6.9 doesn't have the well honed plug-and-pray hal system
> > that the later distros have. It means you will have to 
> manually kick off
> > kudzu or some other older plug-and-pray method to get new hardware
> > recognized, or know what driver it is that needs to be installed.
> >
> > I personally use the manufacturer's latest linux drivers, I 
> don't care
> > about kernel GPL taint just want the best performance from 
> my hardware,
> > so normally I replace the kernel versions with the manufacturer's
> > latest. CentOS helps because most manufacturers directly 
> support RHEL4
> > which means their drivers will just work as-is 90% of the time.
> >
> > I try to avoid CompUSA or Staples hardware as it is mostly 
> designed for
> > consumer use and doesn't have the enterprise level performance
> > characteristics that I like to deploy on my servers.
> >
> > Of course if it were a desktop deployment then Fedora or 
> Ubuntu would
> > work out fine, that is where all the fancy bells and whistles help.
> >
> > -Ross
> >
> >   
> We were concerned about upgradability and that's why we 
> didn't want to 
> use manufacturers tarred up drivers. The reason we felt that 
> FC6 would 
> work out long term was because we already had some boxes with FC5 on 
> them that we had upgraded to FC6 (yes upgraded - no fresh 
> install) with 
> no problems and these boxes are working fine. The FC6 upgrade worked 
> because I had taken the advice of someone who told me that if I made 
> sure to only install software using the packager and did not 
> install any 
> software outside of the package manager say via tarballs, etc. that 
> upgrading FC would work. And they were right. All the upgrades worked 
> perfectly. So this has become our strategy, to only install via the 
> packager and when FC releases a new version we should be able 
> to upgrade 
> without much/any difficulty and in this way we can keep 
> hardware support 
> for our systems very current. Now we've only done this through one 
> release so when FC7 is out and looks stable enough we will do 
> this again 
> and then I'll see if this strategy really looks valid long term.

It is always best practice these days to package all installs, so it is
our policy too. If a package isn't in the distro and we need it in our
environment we first see if a RPM spec file exists for it, and if it
doesn't we write our own using our generic spec file template. We then
build the package and put it in our company repository. Of course now
we're responsible for maintaining it, so we try to keep the repository
small (dozen or two) for essential stuff like apcupsd, and such.

For manufacturer drivers, most of them these days come with dkms
flavors. If you've never used dkms it is basically a driver source
versioning system, maintained by Dell, that if the kernel changes does a
auto-recompile, RPM package build and install. It's nifty and it allows
us to keep our RPM package policy with third party kernel drivers.

> Yes, I agree that places like CompUSA and Staples mostly have 
> consumer 
> level hardware but sometimes that is all that is needed even in a 
> server. For our servers I've set them up with pretty much vanilla 
> hardware, I just buy the cheap video cards - after all I'm 
> not playing 
> games on these boxes so lots of fancy graphics aren't necessary; the 
> gigabit nic cards - I've bought both the server versions and 
> the client 
> versions and after testing found there was very little real 
> difference. 

If it works for you than why change? I just setup a company account with
CDW and they can have replacement parts overnighted to me and when I
build out a system I provide some temporary redundancy built-in, I also
don't run X on my servers which takes that out of the picture. Basically
if I need a graphical interface I use webmin or some other remote
web-based management app.

> You have to tweak and tweak to get jumbo frames to do anything 
> significant and really I just don't have the time for all that so the 
> client versions have been working just fine; I do use 
> usb-flash rescue 
> boot disks and usb external dvd and hard drives and FC6 works 
> great with 
> these. For network gear, SATA/PATA/SCSI hard drives and power 
> supplies I 
> order these online mainly because I can never seem to find 
> what we need 
> locally - usually the ATX PS leads are too short for any 
> rackmount case.

I gave up on jumbo frames. They are not well supported across the board
and most network equipment does not handle them efficiently enough for
my needs (I need very low latency network for my iSCSI).

> Some of our servers are using ATX PS in the rackmounts but 
> you have to 
> check and get the real long leads. But everything else, I 
> just buy local 
> and after all that's the point of Linux - to run on commodity 
> hardware.

Yes, I just buy my commodity hardware from Dell, but it leaves the
choices directly in the user's hands.

> I like CentOS and I think it will be much better once they get to 
> version 5 which will be based on RHEL5 which itself is based 
> on FC6. And 
> that would work for us. We just needed to get a jump start to 
> get to the 
> newer kernels and udev and hotplug support sooner and that 
> part for us 
> has been great.

Current CentOS is very good performer. I would upgrade to CentOS 5 to
get more recent kernel and the support of newer software it provides.

TTFN,

Ross


______________________________________________________________________
This e-mail, and any attachments thereto, is intended only for use by
the addressee(s) named herein and may contain legally privileged
and/or confidential information. If you are not the intended recipient
of this e-mail, you are hereby notified that any dissemination,
distribution or copying of this e-mail, and any attachments thereto,
is strictly prohibited. If you have received this e-mail in error,
please immediately notify the sender and permanently delete the
original and any copy or printout thereof.




More information about the drbd-user mailing list