Hi,
Quote:
Originally Posted by mlpa
There is a post with several optimizations on SSD.
Hope it helps.
|
Quote:
Originally Posted by mlpa
Hi, this is my fstab:
Quote:
/dev/sda6 swap swap defaults 0 0
/dev/sda5 / ext4 defaults,discard,noatime,nodiratime 1 1
/dev/sda2 /media/Windows ntfs-3g discard,umask=000 1 0
#/dev/cdrom /mnt/cdrom auto noauto,owner,ro 0 0
/dev/fd0 /mnt/floppy auto noauto,owner 0 0
devpts /dev/pts devpts gid=5,mode=620 0 0
proc /proc proc defaults 0 0
tmpfs /dev/shm tmpfs defaults 0 0
none /tmp tmpfs defaults 0 0
none /var/log tmpfs defaults 0 0
none /var/tmp tmpfs defaults 0 0
|
<snip> |
You do not need 'nodiratime' in your 'fstab' since it is part of 'noatime'.
Another point for 'swap' is to use and placing in '/etc/rc.d/rc.local' : 'echo 1 >/proc/sys/vm/swappiness' to limit swap. Default swappiness in Slackware is '60'. Even with today's large memory footprint, I like to keep a swap.
As the memory gets >=8GB then consider locating high read/write operations in memory or if you prefer a physical HDD at the cost of time.
You can also maximize performance by using and placing in '/etc/rc.d/rc.local'; 'echo 50 > /proc/sys/vm/vfs_cache_pressure'. Slackware default for '/proc/sys/vm/vfs_cache_pressure' is '100'.
Note: Plus be sure to use & where X=a,b.c..: 'tune2fs -o discard /dev/sdX' if you do not use 'discard' in 'fstab'.
If you have 'SSD' & 'HDD' in the system then you can use 'noop'
scheduler and can be placed in '/etc/rc.d/rc.local': 'echo noop > /sys/block/sdX/queue/scheduler' ( where 'X' is a,b,c,d,e....)
Slackware default is [cfg] scheduler. You can verify this by 'cat /sys/block/sdX/queue/scheduler' that will show the contents for the scheduler in use will be in [cfg] brackets (where 'X' is a,b,c,d,e....).
You will see other available schedulers from the output of 'cat /sys/block/sda/queue/scheduler'.
If you are worried that udev may assign different '/dev/' node to drive(s) because of kernel updates,system upgrade, etc. You should take the means to assign 'noop' to the correct device and place this in '/etc/rc.d/rc.local';
Code:
This code snippet from ArchWiki;
SSD=(device ID's of all 'SSD': see note below)
declare -i i=0
while [ "${SSD[$i]}" != "" ]; do
NODE=`ls -l /dev/disk/by-id/${SSD[$i]} | awk '{ print $NF }' | sed -e 's/[/\.]//g'`
echo noop > /sys/block/$NODE/queue/scheduler
i=i+1
done
Code:
Note Information revised from ArchWiki;
This provides the links listed with targets information to place in bash array 'SSD= ( ) parentheses in above 'SSD= ( );
ls -l /dev/disk/by-id
lrwxrwxrwx 1 root root 9 2012-01-25 10:01 ata-INTEL_SSDSA2M040G2GC_CVGB0320007N040NGN -> ../../sda
Place 'ata-INTEL_SSDSA2M040G2GC_CVGB0320007N040NGN'
into the bash array 'SSD= (ata-INTEL_SSDSA2M040G2GC_CVGB0320007N040NGN)'
You can place all system target ID for 'SSD' in the bash array. Each ID should be space separated.
Caution Note: You should only switch the
scheduler to 'noop' for the 'SSD(s)' in the system. You should keep the 'cfg' scheduler for all other physical 'HHD' in the system. Some say to use 'deadline' but for a 'SSD' device that has no mechanical heads or spinning disks actions to introduce delay then no advantage for '
deadline' over '
noop' which is 'FIFO' queue.
Sometimes you may need to completely reset 'SSD' cells to factory state. 'TRIM' can degrade performance over time on some 'SSD', even ones that support native 'TRIM'. I suggest to get 'SSD' utilities from the drive manufacture. Manufactures usually provide utilities along with firmware upgrades but not always.
Partition Schemes for 'SSD' are always debated. Personally I think that the 'longevity' of the SSD can be extended by placing active partitions like '/var' on a physical HDD rather than on a 'SSD'. '/tmp' can be treated in the same way.
Nothing saying you cannot setup highly active partitions on a 'SSD' when the 'SSD' is optimized properly. 'SSD' longevity is increasing for newer devices. For me a 'SSD' that lasts for 5-8 years is longer than the system usage lifetime for my hardware.
Everyone should select the type of 'SSD' selected, be it synchronous 'SLC' ($$$)or asynchronous 'MLC'($). Each has advantages and disadvantages. Some manufactures are keeping the costs down by using asynchronous 'MLC' with a known good processor controller(i.e.; SandForce is widely used). Maximized performance can be had by synchronous 'SLC' and known good controller 'SandForce'. But you will pay for those advantages on a SandForce synchronous 'SLC' based 'SSD'.
Densities are getting better for 'MLC' at a much lower cost for consumer grade 'SSD'. So unless you have the mission critical performance needs that are provided by a SandForce synchronous 'SLC' based 'SSD' at a much greater cost then my suggestion is to select a premium grade SandForce asynchronous 'MLC' based 'SSD' device at a lower cost. I like '
Patriot SSD' while others prefer '
OCZ SSD'.
I buy computer systems all the time as the need fits. Just purchased another refurbished Dell Laptop at a great cost savings. My old Dell Laptop(5 years old) is still functional (LQ machine) and will continue to be used but for other duties. Placed a
Patriot PyroSE 60GB drive in the new Dell Laptop. Still doing a lot of tweaking for this system with Slackware64 -current. Most of this 'SSD' information is based on the tweaking of the 'SSD' in the New & Old Dell laptops. So much information out there on 'SSD' usage. Some FUD, while some factual and useful from LQ, manufactures & wikis'.
Note: Be very careful with mixing old & new 'SSD' advice & information. I will revise this as I continue benchmarking and tweaking the New Dell Laptop w/
Patriot PyroSE SSD. Also will place revisions in
So you want to be a Slacker! What do I do next?
Buyer be-aware!
But: "No man ever yet became great by imitation." -Samuel Johnson
HTH!
/var /home and /tmp in HDD
.
