Re: AHCI finds disks; no /dev/sd inodes bound?
Matthew Wilcox wrote: On Wed, Jan 09, 2008 at 12:36:26PM -0800, Jon Watte wrote: Stefan Richter wrote: Those systems (servers) typically have enough memory to tolerate a few extra KB of code without problems. In fact most PCs these days have. It would be a stupid solution nevertheless. (We also don't "select EXT3".) Not selecting EXT3 is a little more understandable, because there are many options -- cramfs, xfs, reiserfs, etc, depending on target. However, the number of people who DO want SATA support but DO NOT want SD block device support is... uh.. anyone? Solving the problem bigger and better, by factoring "SD" into a mid-level menu, and maybe calling it something non-SCSI, would probably be even better. And even more work. OK, how about this? config BLK_DEV_ATA_SD tristate "ATA disc support" select BLK_DEV_SD config BLK_DEV_ATA_SR tristate "ATA CDROM support" select BLK_DEV_SR Help text left as an exercise for the reader. Speaking as one who strongly objects to CONFIG_ATA unconditionally selecting SD or SR... I think you are on the right track. IMO a more clean and future-proof solution would be config ATA_PROT_ATA select SD config ATA_PROT_ATAPI (or ATAPI_PROT) select SR But that's just an example. Maybe the choices could be ATA_DISK and ATA_EVERYTHING_ELSE. :) The main points are * its not just CDROM support, but floppy/tape/etc. too for ATAPI * do not include "sd" or "sr" in the config name, it should be more generic, because SCSI will eventually be an optional module for libata. When libata talks to straight blkdev, we don't want this same problem to resurface! Jeff (very tired, so pardon any incoherence) - To unsubscribe from this list: send the line "unsubscribe linux-scsi" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: AHCI finds disks; no /dev/sd inodes bound?
Andi Kleen wrote: > On Thu, Jan 10, 2008 at 12:03:59AM +0100, Stefan Richter wrote: >>> Kconfig is also not an educational facility or high level >>> design description of the code, but a pragmatic tool to get the job >>> done. >> I did not talk about education or design decription. I did talk about >> appropriately showing what the Kconfig options do. > > That's "high level design description" ...of the Kconfig option. But it's not a "design description of the code" which we are configuring. (Even though intelligent beings might be able to draw conclusions about the code, based on what config options are offered.) -- Stefan Richter -=-==--- ---= -=-=- http://arcgraph.de/sr/ - To unsubscribe from this list: send the line "unsubscribe linux-scsi" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: AHCI finds disks; no /dev/sd inodes bound?
On Thu, Jan 10, 2008 at 12:03:59AM +0100, Stefan Richter wrote: > Andi Kleen wrote: > > On Wed, Jan 09, 2008 at 10:41:59PM +0100, Stefan Richter wrote: > >> However, this further obfuscates the fact that libata uses Linux' SCSI > >> midlayer and highlevel. Which is a bad thing. For example, there are > > > > People are not interested in how libata is implemented internally. > > They just want their SATA interfaces to work. > > > > Kconfig is also not an educational facility or high level > > design description of the code, but a pragmatic tool to get the job > > done. > > I did not talk about education or design decription. I did talk about > appropriately showing what the Kconfig options do. That's "high level design description" -Andi - To unsubscribe from this list: send the line "unsubscribe linux-scsi" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: AHCI finds disks; no /dev/sd inodes bound?
Stefan Richter wrote: > The Kconfig menu layouts, prompts, and help texts are there to inform/ > "educate"/ guide the user when configuring the build environment, with > the goal that he safely and efficiently gets to a working software > configuration. It might have been not entirely clear from my earlier postings, but I (and others) actually made alternative suggestions how to improve the menus. Namely, split the SCSI menu and get to the following order of prompts: "Do you have HDDs?" "(Then you need this option here, except in this and that very special case.)" "Do you have an IDE or SATA controller?" "I see your attention is beginning to slip, but let me ask one more thing --- do you have one of those SCSI controllers? No? Thought so." No need to use the buggy and conceptually problematic "select" keyword anywhere. -- Stefan Richter -=-==--- ---= -=-=- http://arcgraph.de/sr/ - To unsubscribe from this list: send the line "unsubscribe linux-scsi" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: AHCI finds disks; no /dev/sd inodes bound?
Andi Kleen wrote: > On Wed, Jan 09, 2008 at 10:41:59PM +0100, Stefan Richter wrote: >> However, this further obfuscates the fact that libata uses Linux' SCSI >> midlayer and highlevel. Which is a bad thing. For example, there are > > People are not interested in how libata is implemented internally. > They just want their SATA interfaces to work. > > Kconfig is also not an educational facility or high level > design description of the code, but a pragmatic tool to get the job > done. I did not talk about education or design decription. I did talk about appropriately showing what the Kconfig options do. Kconfig is the tool to configure the Linux build environment before building the program. In particular, we are talking about how to present the configuration of the Linux ATA component, which happens - to have a build-time dependence on the Linux SCSI midlayer and - to be not very useful at runtime if certain Linux SCSI highlevel components aren't present as well. The Kconfig menu layouts, prompts, and help texts are there to inform/ "educate"/ guide the user when configuring the build environment, with the goal that he safely and efficiently gets to a working software configuration. If some "internals" of the implementation are not entirely invisible to users at run-time, then we should provide information about them. Or change the implementation so that these internals become truly invisible at runtime use, if that is preferable, all things considered. Furthermore, people who use Kconfig are _not_ people who "just want their SATA interfaces to work". These are specifically people who need to or want to create an own configuration before build time, for what ever reason. /These/ are the people to which the Kconfig menus and texts must be tailored for. People who just want their SATA interfaces to work _and_ cannot or don't want to spend time with configuring the kernel build environment can be served to. We give them ready-made .config files or kernels. Or in short: Setting BLK_DEV_SD=y does not mean "make my disk work". It means "enable building one of the program parts which are necessary to make my disk work". And however hard you try, you can't transform it to truly take on the former meaning. Therefore better stay true to the actual meaning. -- Stefan Richter -=-==--- ---= -=--= http://arcgraph.de/sr/ - To unsubscribe from this list: send the line "unsubscribe linux-scsi" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: AHCI finds disks; no /dev/sd inodes bound?
On Wed, Jan 09, 2008 at 10:41:59PM +0100, Stefan Richter wrote: > Matthew Wilcox wrote: > > OK, how about this? > > > > config BLK_DEV_ATA_SD > > tristate "ATA disc support" > > select BLK_DEV_SD > > > > config BLK_DEV_ATA_SR > > tristate "ATA CDROM support" > > select BLK_DEV_SR > > It's probably OK for many uses. > > However, this further obfuscates the fact that libata uses Linux' SCSI > midlayer and highlevel. Which is a bad thing. For example, there are People are not interested in how libata is implemented internally. They just want their SATA interfaces to work. Kconfig is also not an educational facility or high level design description of the code, but a pragmatic tool to get the job done. > further configuration options in the SCSI menu which influence the SCSI > midlayer and highlevel, and therefore influence the software stack which > drives the ATA disks and ATA CD-ROMs. Hence this change does not make > the configuration menu more logical. I think Matthew's patch with appropiate help texts is a good idea. -Andi - To unsubscribe from this list: send the line "unsubscribe linux-scsi" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: AHCI finds disks; no /dev/sd inodes bound?
Matthew Wilcox wrote: > OK, how about this? > > config BLK_DEV_ATA_SD > tristate "ATA disc support" > select BLK_DEV_SD > > config BLK_DEV_ATA_SR > tristate "ATA CDROM support" > select BLK_DEV_SR It's probably OK for many uses. However, this further obfuscates the fact that libata uses Linux' SCSI midlayer and highlevel. Which is a bad thing. For example, there are further configuration options in the SCSI menu which influence the SCSI midlayer and highlevel, and therefore influence the software stack which drives the ATA disks and ATA CD-ROMs. Hence this change does not make the configuration menu more logical. > Help text left as an exercise for the reader. A pro pos, the help texts and prompts for the SCSI midlayer and highlevel options are... suboptimal. At least as long as these help texts and prompts aren't changed¹ to say what they really do, your BLK_DEV_ATA_SD and BLK_DEV_ATA_SR are actually very nice to have. --- ¹) No patch attached. I posted something a while ago. -- Stefan Richter -=-==--- ---= -=--= http://arcgraph.de/sr/ - To unsubscribe from this list: send the line "unsubscribe linux-scsi" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: AHCI finds disks; no /dev/sd inodes bound?
On Wed, Jan 09, 2008 at 12:36:26PM -0800, Jon Watte wrote: > Stefan Richter wrote: > >>Those systems (servers) typically have enough memory to tolerate a few > >>extra KB of code without problems. In fact most PCs these days have. > >> > > > >It would be a stupid solution nevertheless. > > > >(We also don't "select EXT3".) > > > Not selecting EXT3 is a little more understandable, because there are > many options -- cramfs, xfs, reiserfs, etc, depending on target. > However, the number of people who DO want SATA support but DO NOT want > SD block device support is... uh.. anyone? > > Solving the problem bigger and better, by factoring "SD" into a > mid-level menu, and maybe calling it something non-SCSI, would probably > be even better. And even more work. OK, how about this? config BLK_DEV_ATA_SD tristate "ATA disc support" select BLK_DEV_SD config BLK_DEV_ATA_SR tristate "ATA CDROM support" select BLK_DEV_SR Help text left as an exercise for the reader. -- Intel are signing my paycheques ... these opinions are still mine "Bill, look, we understand that you're interested in selling us this operating system, but compare it to ours. We can't possibly take such a retrograde step." - To unsubscribe from this list: send the line "unsubscribe linux-scsi" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: AHCI finds disks; no /dev/sd inodes bound?
Stefan Richter wrote: Those systems (servers) typically have enough memory to tolerate a few extra KB of code without problems. In fact most PCs these days have. It would be a stupid solution nevertheless. (We also don't "select EXT3".) It's not the prettiest solution, but it would reduce the number of "support incidents." And, after all, reducing the number of support incidents is the goal of usability. Not selecting EXT3 is a little more understandable, because there are many options -- cramfs, xfs, reiserfs, etc, depending on target. However, the number of people who DO want SATA support but DO NOT want SD block device support is... uh.. anyone? Solving the problem bigger and better, by factoring "SD" into a mid-level menu, and maybe calling it something non-SCSI, would probably be even better. And even more work. OK, I'll go hide now and try not to fan any flames. And thanks again to Andi for nailing my problem right away! Cheers, / h+ - To unsubscribe from this list: send the line "unsubscribe linux-scsi" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: AHCI finds disks; no /dev/sd inodes bound?
Stefan Richter wrote: > The "select SCSI" in libata's Kconfig option is not of great > help with that issue and is misguided and unnecessary as well. +comment "Serial and Parallel ATA need SCSI command sets" + depends on SCSI=n menuconfig ATA tristate "Serial ATA (prod) and Parallel ATA (experimental) drivers" ... - select SCSI + depends on SCSI ... - NOTE: ATA enables basic SCSI support; *however*, - 'SCSI disk support', 'SCSI tape support', or - 'SCSI CDROM support' may also be needed, - depending on your hardware configuration. + NOTE: 'SCSI disk support', 'SCSI tape support', or + 'SCSI CDROM support' is also required if you have + ATA disks, tapes, or CD/DVD-ROM/R/Ws respectively. ... -- Stefan Richter -=-==--- ---= -=--= http://arcgraph.de/sr/ - To unsubscribe from this list: send the line "unsubscribe linux-scsi" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: AHCI finds disks; no /dev/sd inodes bound?
Stefan Richter wrote: >>> On Wed, 2008-01-09 at 09:21 -0800, Jon Watte wrote: >>> > I wonder if it's possible to magically turn that on when selecting >>> > AHCI support in menuconfig? That way, it'd be harder for someone else >>> > to make the same mistake. > (We also don't "select EXT3".) Perhaps a better analogy: Ethernet options don't automatically turn on IP support. -- Stefan Richter -=-==--- ---= -=--= http://arcgraph.de/sr/ - To unsubscribe from this list: send the line "unsubscribe linux-scsi" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: AHCI finds disks; no /dev/sd inodes bound?
Andi Kleen wrote: > On Wed, Jan 09, 2008 at 11:29:26AM -0600, James Bottomley wrote: >> On Wed, 2008-01-09 at 09:21 -0800, Jon Watte wrote: >> > Yes, that turns out to be the case. Thanks for the quick sanity check! >> > I wonder if it's possible to magically turn that on when selecting >> > AHCI support in menuconfig? That way, it'd be harder for someone else >> > to make the same mistake. >> >> We've had several discussions on this. However, AHCI is used in a lot >> of systems for CD-ROM support only. > > Those systems (servers) typically have enough memory to tolerate a few > extra KB of code without problems. In fact most PCs these days have. It would be a stupid solution nevertheless. (We also don't "select EXT3".) There are other possible solutions. For example the split of the SCSI Kconfig menu which has been proposed some times before. Provide one menu for highlevel protocol-type options, and one menu devoted to SCSI transports and interconnects. This underlines the central role of the SCSI midlayer and SCSI highlevel in the kernel, and makes it easier for people to spot that they need the SCSI highlevel even for their non-SCSI hardware. menuconfig "SCSI command sets (for HDDs, CD/DVD-ROM/R/W, tapes, scanners, and more)" tristate SCSI help This is for [alls sorts of] internal and external devices, [e.g. this and that]. This option is also required for a variety of hardware which isn't actually SCSI hardware. You especially need this option for [such and such common kinds of non-SCSI hardware whose drivers make use of the SCSI subsystem]. If unsure, say Y. (SCSI midlayer options follow) (SCSI highlevel options follow) endmenu if SCSI menuconfig "SCSI transports and interconnects" bool SCSI_LOWLEVEL help Most of the SCSI transport protocols and interconnect drivers are configured here. Some SCSI transports live in other menus. [obligatory SBP-2 reference] (SCSI lowlevel options follow) endmenu endif SCSI PS: It seems only libata users have difficulties to configure SD correctly. USB users apparently and FireWire users definitely never had that problem. The "select SCSI" in libata's Kconfig option is not of great help with that issue and is misguided and unnecessary as well. -- Stefan Richter -=-==--- ---= -=--= http://arcgraph.de/sr/ - To unsubscribe from this list: send the line "unsubscribe linux-scsi" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: AHCI finds disks; no /dev/sd inodes bound?
On Wed, Jan 09, 2008 at 11:29:26AM -0600, James Bottomley wrote: > > On Wed, 2008-01-09 at 09:21 -0800, Jon Watte wrote: > > Yes, that turns out to be the case. Thanks for the quick sanity check! > > I wonder if it's possible to magically turn that on when selecting > > AHCI support in menuconfig? That way, it'd be harder for someone else > > to make the same mistake. > > We've had several discussions on this. However, AHCI is used in a lot > of systems for CD-ROM support only. Those systems (servers) typically have enough memory to tolerate a few extra KB of code without problems. In fact most PCs these days have. -Andi - To unsubscribe from this list: send the line "unsubscribe linux-scsi" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: AHCI finds disks; no /dev/sd inodes bound?
On Wed, 2008-01-09 at 09:21 -0800, Jon Watte wrote: > Yes, that turns out to be the case. Thanks for the quick sanity check! > I wonder if it's possible to magically turn that on when selecting > AHCI support in menuconfig? That way, it'd be harder for someone else > to make the same mistake. We've had several discussions on this. However, AHCI is used in a lot of systems for CD-ROM support only. The resolution last time was to add this to the help text for ATA: If you want to use a ATA hard disk, ATA tape drive, ATA CD-ROM or any other ATA device under Linux, say Y and make sure that you know the name of your ATA host adapter (the card inside your computer that "speaks" the ATA protocol, also called ATA controller), because you will be asked for it. NOTE: ATA enables basic SCSI support; *however*, 'SCSI disk support', 'SCSI tape support', or 'SCSI CDROM support' may also be needed, depending on your hardware configuration. The bottom line is that working out how to configure your own kernel is really hard (even I haven't done it from scratch for ages ... I usually steal a distro config as the basis for my choices). > On Jan 9, 2008 8:45 AM, Andi Kleen <[EMAIL PROTECTED]> wrote: > > "Jon Watte" <[EMAIL PROTECTED]> writes: > > > > > > Any help or pointers to self-help would be appreciated! > > > > The usual mistake is to not enable CONFIG_BLK_DEV_SD > > > > -Andi James - To unsubscribe from this list: send the line "unsubscribe linux-scsi" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: AHCI finds disks; no /dev/sd inodes bound?
Yes, that turns out to be the case. Thanks for the quick sanity check! I wonder if it's possible to magically turn that on when selecting AHCI support in menuconfig? That way, it'd be harder for someone else to make the same mistake. Cheers, / h+ On Jan 9, 2008 8:45 AM, Andi Kleen <[EMAIL PROTECTED]> wrote: > "Jon Watte" <[EMAIL PROTECTED]> writes: > > > > Any help or pointers to self-help would be appreciated! > > The usual mistake is to not enable CONFIG_BLK_DEV_SD > > -Andi > -- -- Americans might object: there is no way we would sacrifice our living standards for the benefit of people in the rest of the world. Nevertheless, whether we get there willingly or not, we shall soon have lower consumption rates, because our present rates are unsustainable. - To unsubscribe from this list: send the line "unsubscribe linux-scsi" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: AHCI finds disks; no /dev/sd inodes bound?
"Jon Watte" <[EMAIL PROTECTED]> writes: > > Any help or pointers to self-help would be appreciated! The usual mistake is to not enable CONFIG_BLK_DEV_SD -Andi - To unsubscribe from this list: send the line "unsubscribe linux-scsi" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
AHCI finds disks; no /dev/sd inodes bound?
I ran out of PATA ports, and figured I'd use the un-used SATA ports on the motherboard of the current machine (Intel G33/ICH9 based) to expand storage that has run out again (like storage usually does). I shut down the machine, put in the disks, booted up, made sure the BIOS said enhanced/AHCI mode, and gave it a spin. Unfortunately, while the AHCI system sees the disks, they appear to not get mapped to any block devices in /dev, so I can't actually partition and mount them. What am I missing, to make the devices bind to (I assume) /dev/sda and /dev/sdb, or similar? (They also don't bind to /dev/sgX). I've tried to google for this particular problem, but because I'm not using a specific distribution, all I'm getting is various information about how to write SCSI subsystem modules, or how to use tools when the device binding has already happened -- nothing about what makes that happen, and what's missing on my machine to make it so. (I'm assuming it's something I'm missing in my init scripts here -- but that assumption could be wrong, too) Here is the output from dmesg that has to do with AHCI (before it is PATA output; after it is 1394 output). ahci :00:1f.2: version 2.2 ACPI: PCI Interrupt :00:1f.2[B] -> GSI 22 (level, low) -> IRQ 19 ahci :00:1f.2: AHCI 0001.0200 32 slots 4 ports 3 Gbps 0x33 impl SATA mode ahci :00:1f.2: flags: 64bit ncq stag pm led clo pmp pio slum part PCI: Setting latency timer of device :00:1f.2 to 64 scsi0 : ahci scsi1 : ahci scsi2 : ahci scsi3 : ahci scsi4 : ahci scsi5 : ahci ata1: SATA max UDMA/133 cmd 0xf8822900 ctl 0x bmdma 0x irq 221 ata2: SATA max UDMA/133 cmd 0xf8822980 ctl 0x bmdma 0x irq 221 ata3: DUMMY ata4: DUMMY ata5: SATA max UDMA/133 cmd 0xf8822b00 ctl 0x bmdma 0x irq 221 ata6: SATA max UDMA/133 cmd 0xf8822b80 ctl 0x bmdma 0x irq 221 ata1: SATA link up 3.0 Gbps (SStatus 123 SControl 300) ata1.00: ATA-7: ST3500630SV, 3.ACH, max UDMA/133 ata1.00: 976773168 sectors, multi 0: LBA48 NCQ (depth 31/32) ata1.00: configured for UDMA/133 ata2: SATA link up 3.0 Gbps (SStatus 123 SControl 300) ata2.00: ATA-7: WDC WD5000ABYS-01TNA0, 12.01C01, max UDMA/133 ata2.00: 976773168 sectors, multi 0: LBA48 NCQ (depth 31/32) ata2.00: configured for UDMA/133 ata5: SATA link down (SStatus 0 SControl 300) ata6: SATA link down (SStatus 0 SControl 300) scsi 0:0:0:0: Direct-Access ATA ST3500630SV 3.AC PQ: 0 ANSI: 5 scsi 1:0:0:0: Direct-Access ATA WDC WD5000ABYS-0 12.0 PQ: 0 ANSI: 5 Here is the output of # ls -l /sys/bus/scsi/devices total 0 lrwxrwxrwx1 root root0 Jan 8 22:48 0:0:0:0 -> ../../../devices/pci:00/:00:1f.2/host0/target0:0:0/0:0:0:0/ lrwxrwxrwx1 root root0 Jan 8 22:48 1:0:0:0 -> ../../../devices/pci:00/:00: 1f.2/host1/target1:0:0/1:0:0:0/ And the output of # ls -l /sys/devices/pci\:00/\:00\:1f.2/host0/target0\:0\:0/0\:0\:0\:0/ total 0 lrwxrwxrwx1 root root0 Jan 8 22:48 bus -> ../../../../../../bus/scsi/ --w---1 root root 4096 Jan 8 22:48 delete -r--r--r--1 root root 4096 Jan 8 22:48 device_blocked -r--r--r--1 root root 4096 Jan 8 22:48 iocounterbits -r--r--r--1 root root 4096 Jan 8 22:48 iodone_cnt -r--r--r--1 root root 4096 Jan 8 22:48 ioerr_cnt -r--r--r--1 root root 4096 Jan 8 22:48 iorequest_cnt -r--r--r--1 root root 4096 Jan 8 22:48 modalias -r--r--r--1 root root 4096 Jan 8 22:48 model drwxr-xr-x2 root root0 Jan 8 22:28 power/ -rw-r--r--1 root root 4096 Jan 8 22:48 queue_depth -r--r--r--1 root root 4096 Jan 8 22:48 queue_type --w---1 root root 4096 Jan 8 22:48 rescan -r--r--r--1 root root 4096 Jan 8 22:48 rev lrwxrwxrwx1 root root0 Jan 8 22:48 scsi_device:0:0:0:0 -> ../../../../../../class/scsi_device/0:0:0:0/ -r--r--r--1 root root 4096 Jan 8 22:48 scsi_level -rw-r--r--1 root root 4096 Jan 8 22:48 state lrwxrwxrwx1 root root0 Jan 8 22:48 subsystem -> ../../../../../../bus/scsi/ -rw-r--r--1 root root 4096 Jan 8 22:48 timeout -r--r--r--1 root root 4096 Jan 8 22:48 type -rw-r--r--1 root root 4096 Jan 8 22:48 uevent -r--r--r--1 root root 4096 Jan 8 22:48 vendor NOTE: there is no "dev" entry for this device, so there's apparently no mapped inode in /dev. I have been running a home server for about 10 years (it started out as a Pentium 120). Back then, "distributions" weren't really all that fancy. This server has undergone many hardware and software upgrades, but only ever the minimum to make it work at each time. Currently, it's running kernel 2.6.22, but /dev/ has inodes from the 2.2 or 2.4 days, and rc scripts are wh
