Re: [gentoo-amd64] 2nd HDD for var, tmp, usr/portage, swap

[Beso]

the only thing that i've splitted is:
/boot on a 100Mb partition, and this thing has saved me a lot of pain when
something went wrong with the reiserfschecks when the pc ran out of energy
with ext2 unjournaled,
the /home partition, so that it could be used with different systems without
reconfiguring with reiserfs,
and a large file partition with xfs which has a very great large file
usage....
i personally don't really think that splitting other / subfolders may have a
great use on everyday use....

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


-- 
beso

d-_-b