| 1 |
Bernhard Auzinger, mused, then expounded: |
| 2 |
> Hi, |
| 3 |
> |
| 4 |
> as I have four hdd's in my computer, I was wondering if it does make sense to |
| 5 |
> source out some partitions/directories to a second hdd. |
| 6 |
> |
| 7 |
|
| 8 |
There is no simple answer. It really depends upon a lot of factors - controllers, |
| 9 |
drives, file system, memory, system bus... |
| 10 |
|
| 11 |
> At the moment I have separate partitions for /var, /tmp and /usr/portage (I |
| 12 |
> feel portage is a lot faster since I've done this) on the same hdd. |
| 13 |
> |
| 14 |
> My question is if it makes sence to move these partitions to another harddisk? |
| 15 |
> |
| 16 |
|
| 17 |
Spreading them across drives could result in faster access if the controllers |
| 18 |
the drives are atached to allow overlapping commands. IDE doesn't do this and |
| 19 |
can only have one drive active on the bus. |
| 20 |
|
| 21 |
Also, some things - /var/tmp/portage, need fast read/write access while /usr/portage |
| 22 |
is a large number of small files (things like Open Office, gcc, firefox being |
| 23 |
exceptions) and mainly read only access. In many cases /tmp is mainly an initial |
| 24 |
write, then mostly read only access once the file get built. |
| 25 |
|
| 26 |
Also, it depends on where on the drive the partition resides. Swap is usually best |
| 27 |
around one third to one half into the drive if the drive is 60% or more full. Less |
| 28 |
access time as the head idles arounf the swap area. |
| 29 |
|
| 30 |
And as drives fill up, they will slow down as file seek times increase. Additionally, |
| 31 |
different file systems will respond to the types of files differently - lots of |
| 32 |
small files, large streaming media files, indexed databases, all require considering |
| 33 |
the intended use. |
| 34 |
|
| 35 |
In desktop use, I've watched the typical file i/o and can say it tended to stay |
| 36 |
below 4 or 5 MB/s peak for most things. And I've seen raid 5 rebuilds sustain |
| 37 |
225 MB/s on the same system. |
| 38 |
|
| 39 |
So, sure move the r/w tasks off disks competing with other r/w tasks and leave the |
| 40 |
read only tasks on the man system disk. You'll see a small improvement, but in the |
| 41 |
larger scheme of things, outside of uncompressing the kernel, open office, firefox, |
| 42 |
or gcc, it won't matter much more than 1% or 2% improvement. |
| 43 |
|
| 44 |
Bob |
| 45 |
- |
| 46 |
-- |
| 47 |
gentoo-amd64@g.o mailing list |
Archives