Date: Mon, 22 Mar 1999 20:03:28 -0300 (EST) From: Carlos Carvalho <carlos@fisica.ufpr.br> To: AIC7xxx@FreeBSD.ORG Subject: Re: SOFTWARE-RAID-TIPS (was: Adaptec 7890 and RAID portIII RAID controller Linux Support) Message-ID: <14070.52288.42062.291696@hoggar.fisica.ufpr.br> In-Reply-To: <36F69BA8.364DA923@redhat.com> References: <Pine.LNX.4.04.9902241451370.23862-100000@maxwax.doghouse.com> <36D582F5.AC7405E3@redhat.com> <14069.31640.589330.961337@hoggar.fisica.ufpr.br> <36F69BA8.364DA923@redhat.com>
next in thread | previous in thread | raw e-mail | index | archive | help
Is everybody getting duplicate msgs from the list as well? Doug Ledford (dledford@redhat.com) wrote on 22 March 1999 14:36: >Large multi-user machines with lots of shell accounts are an >exception to the rule I think, and very well might warrant a >different setup. I think this is the key... >First, breaking up >partitions is primarily a holdover from the early days of 100MB >disks like someone else mentioned. I see little reason to perpetuate >it. The issue of quotas was brought up. That's a moot point. With >quotas you can control on a per filesystem basis, but for /usr, >/var, and / (excluding /tmp) the space you want to give someone is >0. Furthermore, they shouldn't have write permissions in those areas >anyway, so the quota is totally irrelevant. Except for /var/spool/texmf for tex fonts, /var/spool/samba, /var/lock... find also shows /var/lib/emacs/lock :-( Sure it's possible to use symlinks to get around this. But the problem isn't /, /var or swap, which are small. It boils down to the following: you need two large filesystems, one where only root can write, and another where users can write. This one must have quotas and be mounted nosuid,nodev. So they must be separate filesystems. Therefore you end up with two large partitions on each disk, which you say is bad for seek time. I don't see a way around this. >> >I *strongly* recommend that the >> >/boot partition be at least 100MByte in size and that you actually >> >install a minimal installation on the /boot partition >> >> This is a minor point, but I don't think this is useful with the >> current versions of the code. > >Correct. But then again, I've been working with the latest code and on >occassion I've had to coerce it back into functioning after having two drives >marked bad when I really knew they weren't. This is new info. If this happens I agree. Can you give examples of situations where this may occur? All I've had is a bad SCSI bus that produced timeouts every two minutes, causing the aic driver to do a reset. Once the reset hung the machine, and on reboot the raid excluded one of the drives. But this was correct, since it was the drive that timed out and didn't answer to the reset. >However, it's also useful when >testing since I keep a complete kernel tree there and can recompile >with fixes if need be without the RAID being alive. I find it easier compiling in another machine :-) To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe aic7xxx" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?14070.52288.42062.291696>