[PlanetCCRMA] Re: PlanetCCRMA digest, Vol 1 #1701 - 6 msgs

[Mark Shuford]

My response, all the way to bottom:

>Today's Topics:
>
>   2. best hard drive partition scheme (Rich E)
>   3. RE: best hard drive partition scheme (BJaY)
>
>--__--__--
>
>Message: 2
>Date: Sun, 30 Apr 2006 22:46:16 -0700
>From: "Rich E" <reakinator@gmail.com>
>To: planetccrma@ccrma.Stanford.EDU
>Subject: [PlanetCCRMA] best hard drive partition scheme
>
>Hello list,
>
>I've been searching around the net looking for current file sytem
>suggestions, but most everything seems to be from a few years ago
>(they talk about 2 gig harddrives...).  I was wondering what everyone
>running intensive audio software is using for their main file system. 
>Also, it is a little unclear to me when to use primary or extended
>partitions.
>
>In a couple articles reiserfs was mentioned to be superior to ext3,
>but I have to partition the hard drive manually to use it with fedora.
> I have an unformatted hard drive in this computer, should i set it up
>with reiserfs before I begin installation?
>
>Concerning swap partitions, is it unneccesary with 1gig ram?
>
>Also, I assume the boot partition should be the first on the disk,
>which probably has to be ext3.
>
>Any suggestions, corrections or links are much appreciated.
>Thanks,
>Richie
>
>
>--__--__--
>
>Message: 3
>From: "BJaY" <BJaY@safe-mail.net>
>To: "Rich E" <reakinator@gmail.com>, <planetccrma@ccrma.Stanford.EDU>
>Subject: RE: [PlanetCCRMA] best hard drive partition scheme
>Date: Mon, 1 May 2006 10:33:48 +0100
>
>I was just watching the streams of the zkm conference this weekend and there
>was a talk on kernel optomisations for digital audio. The conclusion was to
>use ext3. Reiserfs had previously thought of as good but no longer, because
>of the way it was implemented
>(http://www.ima.zkm.de/lac/download/LeeRevell/rlrevell-lac2006-slides.pdf
>page 4).
>
>I view swap partitions as a 'warning zone'. When you run out of memory, the
>hd light comes on and stays on, saying 'it's time to buy more RAM'. Memory
>is like disk space, you'll use it all and need more.
>
>
>  
>
---
I've not used reiser... no answer for you there. I'll defer...
Both reiser and ext3 are journaled fs'es. In general, performance may be 
a bit lower on these. If this is a major issue w/ you then you may want 
ext2.
Lots of tweaking can be done on all of these... so RTFM and YMMV. :)

---
In general: put the /boot partition on the first (physical) primary 
partition on the drive. This puts the 2nd stage boot loader at the first 
sectors of the disk and assures it to  be accessible from the BIOS/first 
stage boot-loader.
But, the boot loader can all go on the MBR and then you don't really 
have to worry about all of this. Or if your / (root) partition is not 
all that large (you've doled out other fs'es to other partitions) and 
there's no chance of the /boot directory being too far in (physically) 
on the disk, you can forgo the /boot partition altogether and just let 
it reside in the root fs.

Often I will have a relatively small first hard-drive in my system for 
/, /usr, and maybe swap. Then the /var and /home fs'es go on another 
hard-drive. And I'll have these on separate IDE channels. The idea is to 
keep your busy activity to hard-disks spread across drives and 
controllers. (Two IDE drives on one controller get in each others way 
(uhh.... I've not done SATA. I'll let someone else correct me on it if 
it's different...).)

On my CCRMA system I've got a third controller going to a remove-able 
drive caddy for my data. Independent stream for all the through-put I 
can get. Looking to stripe this with a hardware RAID-1 when/as/if 
needed. And the remove-able caddy lets me separate projects.

---
If you've got swap... I tripled (3x) performance on both my Linux and MS 
Win 2000 Pro boxes a few years ago by putting the swap (Linux) and swap 
part file (Win) (and Netscape/Internet Exploiter caches) on separate 
physical drives and controllers from the areas where I was reading and 
writing data and/or doing a lot of program loads. Both machines were 
rather low in RAM... you'll not get that dramatic an increase if you've 
already got RAM, RAM, RAM, RAM... (Lovely RAM! Wonderful RAM!)

It all depends on the mix of what your disk I/O consists of.

For high performance and low latency plenty of RAM is to be desired. The 
more buffer space you've got the I/O will be happier. But as to if you 
need to call swap bad... it depends on what you are swapping out to the 
disk as to if it is a read problem... and the swapping strategy used. 
Not a simple answer for this one, really.

But, for a low latency system -- our Holy Grail here -- swap: generally 
to be avoided.

---
Also, process/context switching to be avoided. Don't run more stuff than 
you need. Custom config your kernel to get rid of all the stuff you do 
not need. Shut down not currently used network interfaces (DON'T just 
shutdown networking -- if the loopback interface is down... well, lots 
of stuff will break bad) and in general eliminate sources of interrupts. 
The stuff you'll need all the time (e.g. alsa, your sound-card driver, 
SCSI drivers) compile into the kernel (non-module).

---
As always: It depends. (Never (well hardly ever) the flat out wrong 
answer any time in computers and networks.) But what I'm doing generally 
is straight recording w/o effects going OR non-real-time mix-down w/ 
lots of doo-dads. (As I'm sure is the case w/ most on this list.) Former 
case: I/O performance to keep up with you concurrent tracks and enough 
RAM to load (w/o swapping) your recorder app and plenty of buffer space. 
Latter case: Lot's of CPU and RAM... depends on how quick you wanna get 
it done.

As always: Buy the most of the best you can afford. :) [or is that :( ?]

Yeah... I usually type more than is really needed... but I wanted to 
throw out some general observations from all walks of computerdom on top 
the specific stuff.

Mark