Date: Wed, 07 Oct 1998 22:49:35 -0700 From: Mike Smith <mike@smith.net.au> To: asami@FreeBSD.ORG (Satoshi Asami) Cc: current@FreeBSD.ORG Subject: Re: CDROM as system disk Message-ID: <199810080549.WAA01315@dingo.cdrom.com> In-Reply-To: Your message of "Wed, 07 Oct 1998 16:38:39 PDT." <199810072338.QAA11608@silvia.hip.berkeley.edu>
next in thread | previous in thread | raw e-mail | index | archive | help
> Guys, thanks for the pointers to various projects and products. I've > saved them all and will post it here if I find something interesting. > > * You want to discover that CDROM drives have a similar MTBF under > * constant use? They'd slower, have lower data density, and if anything, > * will fail more rapidly. > > Eek. Exactly. Killing one in two days as reported by another poster surprised me a bit too, but it's not unrealistic. > * I've played with it off and on. You really don't want to do it for a > * production environment unless you never touch the system disk in normal > * operation. > > Well, the system disk doesn't hold much more than just basic system > utilities. In our case, /, /usr and /usr/local which contains apache > and gridpix servers. What's the minimal system binary footprint? How much memory do you have in the machines? > * The basic issue is that you still need some writable storage, and as > * long as that's local, you still have local disks. > > We do have a lot of local disks. We just don't want to boot from SCSI > disks. :) Because they're all ccd'd together? How often do you reboot the systems? Do you swap to the SCSI disks? > * > (Incidentally, nologin seems to belong to /var/run in all senses of the > * > word; does anyone know why it's in /etc at all?) > * > * Hysterical raisins. > > I take it that nobody will object if I move it to /var/run? Only everyone that expects it to be in /etc, along with everyones' scripts and all the ports (eg. sshd). > * You have a reliability problem that you need to address. To start > * with, you need to work out whether the problem is actually inherent in > * the disks you're using, or whether it's environmental. > > I believe it's environmental. Most of the failures we've seen are to > internal disks, not necessarily of the same brand (even some SCSI > disks). The machine room is kept cool year-round but there isn't much > air flow inside PCs I guess. Have you checked the disks for overheating? Tried sending one or more to a data-recovery shop that claims to be able to pronounce on the cause of death? > * Then you need to follow through; if its environmental (eg. heat, > * humidity, etc.), fix it. If it really is the disks, consider using > * better disks. Plenty of systems up 24/7 have disks 5 years old or more. > * Consider using removable disk sleds and keeping some spares around. > > It is kind of hard to fix without getting new PC cases. I'd like our > solution to be generic as possible too. If your current environment kills disks, you need to fix it or remove all your disks. Focus on solving the problem. 8) > * Dumping disks and going with CDROMs isn't going to help you > * reliability-wise at all, and it'll hurt you in lots of other ways. > > It seems the knocks on CD-ROM drives are that they are not meant for > heavy use and could fail if subjected to continuous start/stops. > Maybe it will work better if I go with an MFS root and copy regularly > used stuff onto it, making the CD-ROM used only for rarely-used > commands. Actually, given that the working set of binaries is very > small, wouldn't they be in the cache anyway? You'd still get disk accesses. You could go with an MFS_ROOT kernel on a bootable CDROM, make the MFS_ROOT filesystem adequately large, mount the CDROM, copy the system off it, unmount it. You'd still have to stash your local configs somewhere. This would limit CDROM access to once per boot, which would give you a much better life expectancy. -- \\ Sometimes you're ahead, \\ Mike Smith \\ sometimes you're behind. \\ mike@smith.net.au \\ The race is long, and in the \\ msmith@freebsd.org \\ end it's only with yourself. \\ msmith@cdrom.com To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199810080549.WAA01315>