RE: [SLE] hdh is a free 10GB (NTFS) looking for something to do
Relocating /opt is a good option to free up space on hdb. However this will not give you any performance boost (per se). Relocating /swap however will not free up much room on hdb, but it will give you a performance boost in paging. If you are looking more along the lines of a performance boost, you may want to look into setting up a RAID array. If you have the ability to setup a RAID 0 striped disk array, then you could look into doing that; a RAID 0 array will give you parallel transfer. This could increase your read and write transfer rates. Of course, this all depends on whether or not your motherboard supports RAID. If your mobo does not support RAID you could purchase a RAID controller card to do so.
The Wednesday 2003-12-03 at 14:22 -0500, Pacheco Jason NPRI wrote:
As a matter of fact, it does: loading X is faster, because kde and gnome are in /opt and the rest in /usr. This is documented by SuSE: |> SuSE Linux Administration Guide |> ============================== |> Partitioning for Experts |> Optimizations |> Parallel Use of Multiple Disks |> ------------------------------ |> To demonstate the advantages, consider what happens if SuSE @nohyphen |> root enters the following in /usr/src: |> |> root@earth :/usr/src/> tar xzf package.tgz -C /usr/lib |> |> package.tgz will be untarred into /usr/lib/package. To do so, the shell |> launches tar and gzip (located in /bin, so on /dev/sda) then |> package.tgz in /usr/src is read (on /dev/sdb). Last, the extracted data |> is written to /usr/lib (on /dev/sdc). With parallel disks, positioning |> as well as read and write of the disks' internal buffers can be |> activated at the same time. |> |> This is only one example. There are many more. If this example were a |> frequent processing requirement and if there are many disks (with the |> same speed), as a rule of thumb, /usr and /usr/lib should physically be |> placed on different disks. Here /usr/lib should have approximately |> seventy percent of the capacity of /usr. /, due to its access, should |> be placed on the disk containing /usr/lib.
Of course - but with the memory sizes available nowdays, the advantage is less.
Even software raid 0 is good. Some say "as good as", because most cards are not really a full hardware solution. -- Cheers, Carlos Robinson
The Wednesday 2003-12-03 at 14:22 -0500, Pacheco Jason NPRI wrote:
As a matter of fact, it does: loading X is faster, because kde and gnome are in /opt and the rest in /usr. This is documented by SuSE: |> SuSE Linux Administration Guide |> ============================== |> Partitioning for Experts |> Optimizations |> Parallel Use of Multiple Disks |> ------------------------------ |> To demonstate the advantages, consider what happens if SuSE @nohyphen |> root enters the following in /usr/src: |> |> root@earth :/usr/src/> tar xzf package.tgz -C /usr/lib |> |> package.tgz will be untarred into /usr/lib/package. To do so, the shell |> launches tar and gzip (located in /bin, so on /dev/sda) then |> package.tgz in /usr/src is read (on /dev/sdb). Last, the extracted data |> is written to /usr/lib (on /dev/sdc). With parallel disks, positioning |> as well as read and write of the disks' internal buffers can be |> activated at the same time. |> |> This is only one example. There are many more. If this example were a |> frequent processing requirement and if there are many disks (with the |> same speed), as a rule of thumb, /usr and /usr/lib should physically be |> placed on different disks. Here /usr/lib should have approximately |> seventy percent of the capacity of /usr. /, due to its access, should |> be placed on the disk containing /usr/lib.
Of course - but with the memory sizes available nowdays, the advantage is less.
Even software raid 0 is good. Some say "as good as", because most cards are not really a full hardware solution. -- Cheers, Carlos Robinson
participants (2)
-
Carlos E. R. -
Pacheco Jason NPRI