Date: Mon, 7 Jun 2004 11:34:17 -0700 From: Kent Stewart <kstewart@owt.com> To: freebsd-questions@freebsd.org Cc: Geert Hendrickx <geert.hendrickx@ua.ac.be> Subject: Re: suggestions for optimal filesystem-layout over multiple harddrives? Message-ID: <200406071134.17742.kstewart@owt.com> In-Reply-To: <40C3F8E2.5010203@mac.com> References: <20040606233406.GA485@lori.mine.nu> <40C3F8E2.5010203@mac.com>
next in thread | previous in thread | raw e-mail | index | archive | help
On Sunday 06 June 2004 10:10 pm, Chuck Swiger wrote: > Geert Hendrickx wrote: > > using multiple harddisks can increase performance, since I/O can be > > done in parallel. But what would be an optimal filesystem-layout > > on, say, two disks of equal size? Swap should evidently be spread > > equally over the different drives. As for the filesystems, say I'd > > have a large /usr and /home, each on one harddrive, and smaller /, > > /var and /tmp which could reside on either disk. / and /usr would > > be mostly read-only. > > There is nothing wrong with the approach you are taking, and it will > indeed help balance load out between multiple spindles. That being > said, you have to know (by measuring) or at least predict what your > I/O access patterns are between the various filesystems in order to > gain full advantage. > > An easier way of balancing load between two or more drives involves > using RAID-0 striping, although the drives do not have to be equal in > size. Commodity ATA RAID controllers like Highpoint, Promise, & 3ware > are fairly cheap, or one could use software RAID like vinum. I was worried about buildworld speed and found I could optimize for that=20 very easy. You need 3 HDs on their own controller and create mount=20 points for /usr/src and /usr/obj on the 2nd and 3rd controller. Since=20 the HDs are so large, I also created a mount point for /usr/ports on=20 one of those other controllers. You only see 10-15% faster build times=20 when you do this and it is a question of how long you are going to run=20 your system before you are paid back for the time you spent worrying=20 about it. =46rom my days of benchmarking supercomputers, we found it was always easy= =20 to move files produced by users onto a different set of HDs than the=20 system was using. You separated the files the system wanted quick=20 access to from the files being produced by users. The programs we ran=20 generated a lot of data and disk caching was much more important than=20 location of the files. What becomes important with caching is whether=20 fast access to files you want to read is most important or data=20 integrity. If data integrity is not important because you are going to=20 restart the program and run it from scratch, then write behind caching=20 is easy to setup.=20 I haven't encountered any environment like that since I retired.=20 My /home/user accounts are all on /usr. Kent =2D-=20 Kent Stewart Richland, WA http://users.owt.com/kstewart/index.html
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?200406071134.17742.kstewart>