Réponse automatique
Nos bureaux seront fermés jusqu'au lundi 23 juillet 2007. Nous répondrons à votre email dès notre retour et vous remercions de votre compréhension. Nous profitons de la présente afin de vous souhaiter un bel été! Our offices are closed until July 23rd. We will answer to your email as soon as we come back and we thank you for your comprehension. We would like to take this opportunity to wish you a nice summer!
Re: 32-bit vs AMD64 on Opteron for LAMP server
[EMAIL PROTECTED] wrote: I don't have any facts or numbers to bring forward, but you probably won't notice that much of a difference. What do you base this opinion on? Having said that, I would say go for the AMD64 port. I don't think the install is anywhere near less straightforward than the 32bit port. The AMD64 port is less straightforward because they do not include the dpt_i2o driver, which is necessary for my RAID card. Instead, I have to either use the i2o_block driver, which I gather has had some reliability issues under load, or else build a patched kernel with dpt_i2o, which isn't ideal since it always complicates and lengthens the install. Also, for some reason, my own kernels always seem to end up being slower than the stock kernels, even though I am careful to go through and build in/enable everything very specific to the hardware. But since you are running 4 Gig of RAM, take full advantage of it by running amd64. My understanding is that 32-bit can utilize up to 4 GB as well, it's when you have more than 4GB that it starts to matter. The developers have done a great job getting this port official and you won't be disappointed with it. Its rock solid. I know it's solid, it's been running in my server for over two years. I'm wondering about real world speed difference between 32-bit and 64-bit given the fact that the 64-bit world is still not as complete in terms of software support (dpt_i2o being case in point, but there is, I assume, other software that isn't 64-bit safe yet as well). The 32-bit version is also rock solid, even more so probably. If you can, try both in a test environment, and then make your decision. Perhaps there are some apache, or mysql benchmarks you can try? This is my only server. It's production, and in colo. I don't have money to have a multi-server setup at this time. When I take it down, the whole shebang is down, and I need to get things back up again asap. So it's going to be, ideally, a process of backing up the essential data, rebuild, restore essential data, reconfigure for Etch, and go. Also, the server is in Chicago IL, I am in Saint Louis MO, I don't have much time up there. The colo company has to accompany me in to the datacenter for security. They wanted to charge me $100 per hour to have someone be there with me, but they are doing me a favor by not charging me for their time. I know, it seems silly, but that's how they do it. I am getting a relatively good deal on the bandwidth so it's worth keeping them happy. Upshot is, I don't have unlimited time/opportunity to be at the console installing and reinstalling operating systems, or mucking around for that matter trying to get kernels patched. I know that once we have the base system up I can do stuff via ssh, but we're talking about console time here. Hence my desire to see how 32-bit would compare performance-wise, because I know that has dpt_i2o built-in and will work right out of the box. Oh, and I would ask you if you have considered Software raid instead of using an adaptec raid card? If you have time, try benchmarking between them. You might be suprised to see which one actually works better for you. I don't know why it would be faster to use up my main CPU cycles doing RAID rather than using the hardware RAID that is already in the box. The guy that built my server seemed to think that this RAID solution was very appropriate for this setup. In any case, see my previous paragraph - I won't have time to mess around with testing different setups. Also, from what I have seen of software RAID in linux, you still have to mess around with making a new kernel with the RAID personalities built into the kernel (rather than modules) to be able to boot off a software RAID partition. The Adaptec makes it all transparent to me, the 4 drives appear as one single drive and RAID 10 is done under the covers. Does anybody else have any opinions on whether software RAID would be faster than using the built-in Adaptec SmartRaid 2015S card? For reference, my travails using dpt_i2o with AMD64 were documented here: http://lists.debian.org/debian-amd64/2005/09/msg00201.html Thanks, /Neil -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: 32-bit vs AMD64 on Opteron for LAMP server
Quoting Neil Gunton [EMAIL PROTECTED]: [EMAIL PROTECTED] wrote: I don't have any facts or numbers to bring forward, but you probably won't notice that much of a difference. What do you base this opinion on? Nothing really, I've setup a handful of amd64 servers and a whack of i386 ones. Alot of them web servers running basic php and mysql stuff. Speeds felt the same. Having said that, I would say go for the AMD64 port. I don't think the install is anywhere near less straightforward than the 32bit port. The AMD64 port is less straightforward because they do not include the dpt_i2o driver, which is necessary for my RAID card. Instead, I have to either use the i2o_block driver, which I gather has had some reliability issues under load, or else build a patched kernel with dpt_i2o, which isn't ideal since it always complicates and lengthens the install. Also, for some reason, my own kernels always seem to end up being slower than the stock kernels, even though I am careful to go through and build in/enable everything very specific to the hardware. Ah, yes. If your missing some hardware drivers, it can be a pain. But since you are running 4 Gig of RAM, take full advantage of it by running amd64. My understanding is that 32-bit can utilize up to 4 GB as well, it's when you have more than 4GB that it starts to matter. I always thought that 32 bit sarge with 4G ram, would only show about 3.3G of available RAM. I could be wrong, and perhaps this doesn't happen in etch. Oh, and I would ask you if you have considered Software raid instead of using an adaptec raid card? If you have time, try benchmarking between them. You might be suprised to see which one actually works better for you. I don't know why it would be faster to use up my main CPU cycles doing RAID rather than using the hardware RAID that is already in the box. The guy that built my server seemed to think that this RAID solution was very appropriate for this setup. In any case, see my previous paragraph - I won't have time to mess around with testing different setups. Also, from what I have seen of software RAID in linux, you still have to mess around with making a new kernel with the RAID personalities built into the kernel (rather than modules) to be able to boot off a software RAID partition. The Adaptec makes it all transparent to me, the 4 drives appear as one single drive and RAID 10 is done under the covers. Does anybody else have any opinions on whether software RAID would be faster than using the built-in Adaptec SmartRaid 2015S card? Etch has full SW raid support right out of the install. No messing with kernels. You can even install raid on the / during the install if you wanted. I didn't want to get into a hardware vs software raid conversation, but figured if you had a few days of down time, it would nice to run some tests before hand. Cheers, Mike This message was sent using IMP, the Internet Messaging Program.
Re: 32-bit vs AMD64 on Opteron for LAMP server
On Fri, Jul 06, 2007 at 07:29:25AM -0700, [EMAIL PROTECTED] wrote: Quoting Neil Gunton [EMAIL PROTECTED]: Does anybody else have any opinions on whether software RAID would be faster than using the built-in Adaptec SmartRaid 2015S card? Etch has full SW raid support right out of the install. No messing with kernels. You can even install raid on the / during the install if you wanted. I didn't want to get into a hardware vs software raid conversation, but figured if you had a few days of down time, it would nice to run some tests before hand. The determining factor for whether to use hardware RAID or software RAID is whether your hardware RAID actually does hardware RAID. Do a Google search on fake RAID to get an idea of what I mean. Many hardware RAID cards, especially the cheaper varieties, are nothing more than proprietary software RAID implemented in the card BIOS. This is something that you DO NOT want. Use something that has REAL hardware RAID (Intel MegaRAID, HP SmartArray, 3Ware, etc), or just use the Linux built-in software RAID. Regards, -Roberto -- Roberto C. Sánchez http://people.connexer.com/~roberto http://www.connexer.com signature.asc Description: Digital signature
Re: 32-bit vs AMD64 on Opteron for LAMP server
On Thursday 05 July 2007 22:07, Neil Gunton wrote: Hi all, I am going to be rebuilding a server in August which has been running Sarge AMD64 for the last couple of years in a colo environment. I am going to do a total rebuild (need to repartition the disks). Since I am using the dpt_i2o drivers for Adaptec RAID, which I had a hell of a problem getting to work under Sarge AMD64 (and still aren't in the default modules for Etch), I am considering all options, including simply using 32-bit Etch on the new install. This is a LAMP server, running apache 1.3, mysql 5. You won't be able to use all of your 4GB RAM with a 32-bit kernel. A 32-bit processor only has 4GB of addressing space, and that has to be shared between memory and peripherals. You'd also do better with Apache 2.0 or 2.2, as long as you use the prefork version (which is more compatible with PHP, if that's your chosen P). The breaking-up of the configuration files is a bit of a pain to deal with, but worth it in the long run (I knocked up a Perl script to break up a 1.3-style configuration file into 2.0-style snippets; e-mail me if you are interested, on-list if you think others would be interested). Otherwise it's just like 1.3, only faster. If your RAID card is one of the ones that uses a binary-only driver, ignore it and use the open source drivers with md RAID instead -- md is faster than any manufacturer's proprietary alternative (anything that needs a driver is fake RAID. True hardware RAID never needs a special driver; the array just shows up as a single drive). Beside the non-polluted kernel, you also get the advantage that you can have your swap area without redundancy, hence running as fast as possible (just set up the partitions as separate swap areas). -- AJS -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: 32-bit vs AMD64 on Opteron for LAMP server
On July 6, 2007 07:29 am [EMAIL PROTECTED] wrote: Quoting Neil Gunton [EMAIL PROTECTED]: [EMAIL PROTECTED] wrote: I don't have any facts or numbers to bring forward, but you probably won't notice that much of a difference. What do you base this opinion on? Nothing really, I've setup a handful of amd64 servers and a whack of i386 ones. Alot of them web servers running basic php and mysql stuff. Speeds felt the same. Having said that, I would say go for the AMD64 port. I don't think the install is anywhere near less straightforward than the 32bit port. The AMD64 port is less straightforward because they do not include the dpt_i2o driver, which is necessary for my RAID card. Instead, I have to either use the i2o_block driver, which I gather has had some reliability issues under load, or else build a patched kernel with dpt_i2o, which isn't ideal since it always complicates and lengthens the install. Also, for some reason, my own kernels always seem to end up being slower than the stock kernels, even though I am careful to go through and build in/enable everything very specific to the hardware. Ah, yes. If your missing some hardware drivers, it can be a pain. But since you are running 4 Gig of RAM, take full advantage of it by running amd64. My understanding is that 32-bit can utilize up to 4 GB as well, it's when you have more than 4GB that it starts to matter. I always thought that 32 bit sarge with 4G ram, would only show about 3.3G of available RAM. I could be wrong, and perhaps this doesn't happen in etch. Depends on the motherboard. The top 256-768 MB of RAM is reserved for PCI mapped memory space and other devices. Some motherboards and CPUs let you re-map this memory above the 4 GB boundary (making it appear that you have up to 5 GB of RAM) while others don't. AMD systems tend to be better in allowing the remapping. 32-bit systems can use 3 GB without problems. It's when you have more than 3 GB that things start to get weird. 64-bit systems don't have these issues. -- Freddie Cash, LPIC-2 CCNT CCLP Network Support Technician School District 73 (250) 377-HELP [377-4357] [EMAIL PROTECTED] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: 32-bit vs AMD64 on Opteron for LAMP server
On Fri, Jul 06, 2007 at 04:07:23PM +0100, Adam Stiles wrote: You won't be able to use all of your 4GB RAM with a 32-bit kernel. A 32-bit processor only has 4GB of addressing space, and that has to be shared between memory and peripherals. Not true. With PAE, a 36-bit address is available, allowing access to 64 GB of RAM. What does not change, however, is that with a 32-bit kernel no single process can address more than 4 GB of RAM. You'd also do better with Apache 2.0 or 2.2, as long as you use the prefork version (which is more compatible with PHP, if that's your chosen P). The breaking-up of the configuration files is a bit of a pain to deal with, but worth it in the long run (I knocked up a Perl script to break up a 1.3-style configuration file into 2.0-style snippets; e-mail me if you are interested, on-list if you think others would be interested). Otherwise it's just like 1.3, only faster. This is true. Any pain spent transitioning from Apache v1 to Apache v2 or 2.2 is well worth it. If your RAID card is one of the ones that uses a binary-only driver, ignore it and use the open source drivers with md RAID instead -- md is faster than any manufacturer's proprietary alternative (anything that needs a driver is fake RAID. True hardware RAID never needs a special driver; the array just shows up as a single drive). Beside the non-polluted kernel, you also get the advantage that you can have your swap area without redundancy, hence running as fast as possible (just set up the partitions as separate swap areas). Clearly you don't know what you are talking about here. If you look, there are drivers in the kernel for megaraid (Intel), cciss (HP Smart Array) and 3ware. All of there are certainly hardware RAID. In fact, all of those are also in the kernel and free software drivers, developed primarly by the hardware vendors. In any case, your statement is equivalent to saying A true video card never needs a special driver; the card just shows up as a video device. *Every* device on the system needs a driver of some sort or another. Regards, -Roberto -- Roberto C. Sánchez http://people.connexer.com/~roberto http://www.connexer.com signature.asc Description: Digital signature
Re: 32-bit vs AMD64 on Opteron for LAMP server
On Fri, Jul 06, 2007 at 07:53:18AM -0500, Neil Gunton wrote: [EMAIL PROTECTED] wrote: The AMD64 port is less straightforward because they do not include the dpt_i2o driver, which is necessary for my RAID card. Instead, I have to either use the i2o_block driver, which I gather has had some reliability issues under load, or else build a patched kernel with dpt_i2o, which isn't ideal since it always complicates and lengthens the install. Also, for some reason, my own kernels always seem to end up being slower than the stock kernels, even though I am careful to go through and build in/enable everything very specific to the hardware. Without the driver, will the card just look like a non-raid card or will the drives not be visiable at all? If the drives are visible, forget the hardware raid. Otherwise, would something like module-assistant be able to make your module for you without compiling the whole kernel? But since you are running 4 Gig of RAM, take full advantage of it by running amd64. My understanding is that 32-bit can utilize up to 4 GB as well, it's when you have more than 4GB that it starts to matter. There's also something about the maximum amount of memory that a single process can access in 32-bit but I forget the details. The developers have done a great job getting this port official and you won't be disappointed with it. Its rock solid. I know it's solid, it's been running in my server for over two years. I'm wondering about real world speed difference between 32-bit and 64-bit given the fact that the 64-bit world is still not as complete in terms of software support (dpt_i2o being case in point, but there is, I assume, other software that isn't 64-bit safe yet as well). The 32-bit version is also rock solid, even more so probably. The only software I've found missing is a flash plugin for browsers but there's a fix in testing that I'm told can be dragged into one's Etch box (I'll try it in a bit). If you can, try both in a test environment, and then make your decision. Perhaps there are some apache, or mysql benchmarks you can try? This is my only server. It's production, and in colo. What about a test on any amd64 box. Borrow one for a few hours? I don't have money to have a multi-server setup at this time. When I take it down, the whole shebang is down, and I need to get things back up again asap. So it's going to be, ideally, a process of backing up the essential data, rebuild, restore essential data, reconfigure for Etch, and go. Also, the server is in Chicago IL, I am in Saint Louis MO, I don't have much time up there. The colo company has to accompany me in to the datacenter for security. They wanted to charge me $100 per hour to have someone be there with me, but they are doing me a favor by not charging me for their time. I know, it seems silly, but that's how they do it. I am getting a relatively good deal on the bandwidth so it's worth keeping them happy. Upshot is, I don't have unlimited time/opportunity to be at the console installing and reinstalling operating systems, or mucking around for that matter trying to get kernels patched. I know that once we have the base system up I can do stuff via ssh, but we're talking about console time here. Hence my desire to see how 32-bit would compare performance-wise, because I know that has dpt_i2o built-in and will work right out of the box. Fairly early in the install, there's a menu item continue install from ssh. Is there no way to get remote access to the console so that the datacenter people only have to put CD-bin1 into the drive? I can do an install from scratch on my Athlon64, including the raid setup, in about 20 minutes. The i386 installer looks the same so you could practice what you want to do on a spare i386 where you are and write it out step-by-step so that you minimize down time. Oh, and I would ask you if you have considered Software raid instead of using an adaptec raid card? If you have time, try benchmarking between them. You might be suprised to see which one actually works better for you. I don't know why it would be faster to use up my main CPU cycles doing RAID rather than using the hardware RAID that is already in the box. The guy that built my server seemed to think that this RAID solution was very appropriate for this setup. In any case, see my previous paragraph - I won't have time to mess around with testing different setups. Also, from what I have seen of software RAID in linux, you still have to mess around with making a new kernel with the RAID personalities built into the kernel (rather than modules) to be able to boot off a software RAID partition. The Adaptec makes it all transparent to me, the 4 drives appear as one single drive and RAID 10 is done under the covers. You can do software raid right from the installer. My box has two drives, with LVM over raid1 for the system including swap.
Re: 32-bit vs AMD64 on Opteron for LAMP server
On Fri, Jul 06, 2007 at 04:07:23PM +0100, Adam Stiles wrote: advantage that you can have your swap area without redundancy, hence running as fast as possible (just set up the partitions as separate swap areas). However, with non-raid swap, if something happens to one drive, the system dies due to dead swap. You should never need to swap much anyway so keep it on raid along with the rest of the system. Doug. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
System freezes after update (Update)
Hi dear maintainers, now I could verify the package which causes the freeze of my system: They are the Nvidia-packages (100.14.11), which are causing the freeze. A bugreport has been sent. I downgraded first the kernel, with no success. Then downgraded Nvidia-packages and it was o.k.. Upgrading kernel was o.k., too. Upgrading Nvidia-Packages did show the bug again. I hope, this information will be interstested for other users, too. Regards Hans -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: System freezes
On Thu July 5 2007 09:02:02 am Hans-J. Ullrich wrote: Hi dear maintainers, after the last upgrade my system randomly freezes when running in X. The main things I upgraded, was the kernel from 2.6.21-1-amd64 to 2.6.21-2-amd64 and the Nvidia-packages (nvidia-kernel, -glx and -glx-ia32) I suspect either the kernel or the Nvidia-packages, as everything went fine before the upgrade. To verify this, I would like to downgrade to the packages before. But they are gone, and the packages in /testing are too old. Where can I find them ? Maybe someone has stored them and could send them to me. There are no precompiled nvidia-kernel-* packages for testing/unstable kernels. I used module-assistant to build them for me. running the following commands did the trick for me.. module-assitant prepare module-assistant auto-install nvidia -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: flash for etch amd64? [FAILED]
On Wed, Jul 04, 2007 at 03:29:02PM +0100, Rob Andrews wrote: On 04-Jul-2007 02:54.42 (BST), Douglas Allan Tutty wrote: in the freeze of etch nspluginwrapper 0.9.91.3-1+b1 use libc6 = 2.3.5 I suppose you could use snapshot.debian.net to obtain that version that works very good until now in etch Retreiving it now. It also depends on ia32-libs-gtk which is unavailable in etch so I'm getting version 1 of that (since 2 just came out, its later than nspl* 0.9. I considered a backport for etch, but there is no 32-bit gtk2 in etch - it doesn't exist in ia32-libs, and not in ia32-libs-gtk. As such, it really isn't possible. I have communicated with another user regarding this, and it's okay to pull ia32-libs, ia32-libs-gtk and nspluginwrapper and install the three on etch. Any other dependancies can be installed from etch. 0.9.91.4-2 is in testing, and -3 is in unstable (should move to testing, as there should be no unexpected errors in there). Just to follow up. I tried teasing out the dependancies to see if I could get it to work and I couldn't. I trid the suggestion of just bringing in ia32-libs, ia32-libs-gtk, and nspluginwrapper but ran into a conflict with a requirement for libglib2.0-0 = 2.12.9, however, newer versions require a newer libc6. So I guess its either the chroot approach or upgrading to Lenny. To that end, I started a new thread asking about Lenny. Thanks for your help. Doug. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: flash for etch amd64? [FAILED]
On Fri July 6 2007 07:38:08 pm Douglas Allan Tutty wrote: On Wed, Jul 04, 2007 at 03:29:02PM +0100, Rob Andrews wrote: On 04-Jul-2007 02:54.42 (BST), Douglas Allan Tutty wrote: in the freeze of etch nspluginwrapper 0.9.91.3-1+b1 use libc6 = 2.3.5 I suppose you could use snapshot.debian.net to obtain that version that works very good until now in etch Retreiving it now. It also depends on ia32-libs-gtk which is unavailable in etch so I'm getting version 1 of that (since 2 just came out, its later than nspl* 0.9. I considered a backport for etch, but there is no 32-bit gtk2 in etch - it doesn't exist in ia32-libs, and not in ia32-libs-gtk. As such, it really isn't possible. I have communicated with another user regarding this, and it's okay to pull ia32-libs, ia32-libs-gtk and nspluginwrapper and install the three on etch. Any other dependancies can be installed from etch. 0.9.91.4-2 is in testing, and -3 is in unstable (should move to testing, as there should be no unexpected errors in there). Just to follow up. I tried teasing out the dependancies to see if I could get it to work and I couldn't. I trid the suggestion of just bringing in ia32-libs, ia32-libs-gtk, and nspluginwrapper but ran into a conflict with a requirement for libglib2.0-0 = 2.12.9, however, newer versions require a newer libc6. I ran into that to on an etch box and it concerned me. But I wanted to try out something or other so I did it and never regretted it. So I guess its either the chroot approach or upgrading to Lenny. To that end, I started a new thread asking about Lenny. I have run etch with both testing and unstable in my sources.list along with.. APT::Default-Release stable; in /etc/apt/apt.conf and it worked well for me. It can be tricky finding out what satisfies what with all those different versions available but if you are happy with etch it might be worth trying before going to lenny. Just something to think about.. :) -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: 32-bit vs AMD64 on Opteron for LAMP server
Douglas Allan Tutty wrote: Without the driver, will the card just look like a non-raid card or will the drives not be visiable at all? If the drives are visible, forget the hardware raid. Without the driver (either dpt_i2o or i2o_block) the hard drives are not visible at all, and you cannot boot. You need the driver to see the drives. As others have pointed out, this doesn't mean the RAID card isn't real hardware RAID; as with any other piece of hardware on the system, the kernel requires a driver to interact with it. The driver is not binary; I have the source code patch from Adaptec, which you need to build into the kernel for AMD64. It is not included with Etch because the community apparently made a decision that two different drivers for the same hardware were not needed, and they decided that they would go with i2o_block. I have heard that i2o_block has some issues with stability, people have talked about corruption and errors under load. Since the i2o_block driver has apparently been abandoned for a while, I don't have a great deal of confidence that these problems were ever really fixed. The dpt_i2o driver has worked very well for me for about two years now, with no problems at all under load, so I would prefer to continue using that. I recently communicated with Mark Salyzyn over at Adaptec, and he forwarded me the current source code version of dpt_i2o which works with the current 2.6 kernels. I haven't had the chance to try it out yet. Even if I go with jbod, I would still need one of these drivers just to see the hard drives. I have no handle on whether the hardware RAID would be better or worse than software RAID. Fairly early in the install, there's a menu item continue install from ssh. Is there no way to get remote access to the console so that the datacenter people only have to put CD-bin1 into the drive? I have never seen this option (I recently installed Etch from scratch on my home workstation, after my hard drive died). How is this accessed? Where do you get the (no doubt arcane) information that is needed to access the option, since it plainly wasn't visible during the stock install? You can do software raid right from the installer. My box has two drives, with LVM over raid1 for the system including swap. Grub can boot off of raid1 so put /boot on raid1 (no LVM) partition. Again, I saw no option for software RAID. I did see an option for LVM during the partitioning section, but nothing at all about RAID. How would I enable that? That's almost 2 years ago. You may find that it just works. If you No, it won't - I know for a fact, from the guy at Adaptec himself, that dpt_i2o is not included with AMD64 because the maintainers decided that they would be going with i2o_block. So I may be able to install using i2o_block, but that isn't the path I want to take since I have no confidence in that module for a production environment, and doing searches on google for it I can find no references to it except from the 2005 timeframe. This does not give me confidence that it was developed or fixed past the time when people were reporting that it had problems. So best case, I can maybe install using i2o_block, and then build my own kernel that uses dpt_i2o. However I need to be at the console to do this, because inevitably there will be hangs and suchlike that require my physical presence at the console. could find someone else with this card, even if they don't usually run debian, they could boot the installer CD and go through the motions and see if the drives appear as one drive (hardware RAID working) or many (no hardware RAID). Unfortunately, the RAID card I have doesn't seem to have been a type that really took off in any significant way. I don't know of anyone else who has one. If anyone does happen to have a spare Adaptec Smart RAID 2015S lying around in an unused server, then I'd love to hear whether they can try installing Etch and patching the kernel with the new dpt_i2o. But somehow I think anyone with such a server is probably using it. Thanks, /Neil -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: 32-bit vs AMD64 on Opteron for LAMP server
[EMAIL PROTECTED] wrote: Etch has full SW raid support right out of the install. No messing with kernels. I didn't see anything about this in the recent home install I did... and I was specifically paying attention to look out for it, since I had just bought two identical 320 GB WD drives to replace the one that had just died. I wanted to build a system that would allow me to have a disk die without having to rebuild everything from scratch again. But I saw nothing in the install process that mentioned an option for software RAID... obviously I missed a beat somewhere! Thanks again, /Neil -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: 32-bit vs AMD64 on Opteron for LAMP server
Adam Stiles wrote: You won't be able to use all of your 4GB RAM with a 32-bit kernel. A 32-bit processor only has 4GB of addressing space, and that has to be shared between memory and peripherals. Really? I thought that the only limitation was on individual processes not having more than 4GB available, but the entire system as a whole could address a lot more than that. But I could be wrong. You'd also do better with Apache 2.0 or 2.2, as long as you use the prefork I am using apache 1.3 because I also use mod_accel and mod_deflate from Igor Sysoev. His modules are 1.3 only, and the proxy module (mod_accel) does some things that mod_proxy didn't seem to provide back when I was trying to build my reverse proxy. The thing that pops up from memory is that mod_accel correctly passed cookies and differentiated requests based on cookies, whereas mod_proxy didn't. So if mod_proxy got two different requests that were for the same URI, but with the only difference being the cookie, then mod_proxy would see them as the same request and (incorrectly, in my book) give the same cached result. I discussed this with some of the httpd developers, and they insisted that differentiating requests based on cookies wasn't in the http spec, and wasn't a proper way to do things; I maintained that since cookies are the universal method of keeping track of sessions and users, thus it makes perfect sense to differentiate requests based on them. But they took a dogmatic line, whereupon Igor popped up and said Hey, my module does what you're needing, and it worked great, and has been for the last four years or so. I have no idea if Apache 2 has progressed to the point of being able to handle cookies correctly, but my discussions did not give me hope back then. Also, it was only recently that mod_perl 2 got to a point where it even worked, let alone was at the same level of reliability that mod_perl 1 was at after years of testing. Finally, Embperl, yet another module essential to my site, wasn't stable in version 2 for a long, long time, and continues to have compatibility issues that break my (large) existing code base. All of this prompted me to write an essay about the patterns I saw, called Rewrites considered harmful, published on my site and on slashdot a few years ago. All in all, I am leery of new systems that claim to get everything right that the old systems didn't, and I like to use well tested systems in production, not new stuff that might be faster for plain vanilla cases, but aren't reliable for more complex situations. Apache 1.3 has worked very well for me, and is rock solid, and for production I don't have time to mess around with completely new APIs that were changed just because some developers needed to feel important that they wrote version 2 of apache. Their little campaign to change the whole apache API caused a huge pain in the ass for many, many people such as myself who had working v1 modules that would have to be debugged and converted to v2 api calls. It's not trivial, and it makes all the old books on writing apache modules out of date. It throws the entire developer community into chaos. Just look at how long it took mod_perl 2 to stabilize. Very stupid situation. So I don't feel particularly well disposed toward apache 2, thanks. If your RAID card is one of the ones that uses a binary-only driver, ignore it and use the open source drivers with md RAID instead -- md is faster than any Not binary, I have the source code patch. manufacturer's proprietary alternative (anything that needs a driver is fake RAID. True hardware RAID never needs a special driver; the array just shows up as a single drive). Beside the non-polluted kernel, you also get the advantage that you can have your swap area without redundancy, hence running as fast as possible (just set up the partitions as separate swap areas). I don't think this is an accurate characterization of what constitutes hardware RAID. Any piece of hardware needs a driver for the kernel to interact with it. Once the Adaptec array has been defined (in its own config at boot time) then it does appear to be a single device. Four hard drives configured as two RAID 1 arrays, then striped into a single RAID 10 device, appears as a single hard drive to the kernel. Thanks again, /Neil -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: 32-bit vs AMD64 on Opteron for LAMP server
Roberto C. Sánchez wrote: On Fri, Jul 06, 2007 at 04:07:23PM +0100, Adam Stiles wrote: You won't be able to use all of your 4GB RAM with a 32-bit kernel. A 32-bit processor only has 4GB of addressing space, and that has to be shared between memory and peripherals. Not true. With PAE, a 36-bit address is available, allowing access to 64 GB of RAM. What does not change, however, is that with a 32-bit kernel no single process can address more than 4 GB of RAM. That sounds very much like what I have read as well. You'd also do better with Apache 2.0 or 2.2, as long as you use the prefork version (which is more compatible with PHP, if that's your chosen P). The breaking-up of the configuration files is a bit of a pain to deal with, but worth it in the long run (I knocked up a Perl script to break up a 1.3-style configuration file into 2.0-style snippets; e-mail me if you are interested, on-list if you think others would be interested). Otherwise it's just like 1.3, only faster. This is true. Any pain spent transitioning from Apache v1 to Apache v2 or 2.2 is well worth it. You're probably right; however, as is probably usual with production environments, I never really have the time or inclination to take time out to do such a major shift. Apache 1.3 works just fine for me, I really doubt there is that much difference between using apache 1.3 and apache 2, since the limiting factor for me is almost certainly not in the number of raw static connections that can be served, but rather the mod_perl backend communicating with the mysql database server. That is the heavyweight here, not apache itself. CPU used to do complex sql queries, and disk I/O in serving those queries, is what is going to kill performance, not how fast apache can fork a new process. Thanks, /Neil -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
