my deepest regrets on not having what it takes to submit this to the pclos magazine but for what its worth I believe the friends will enjoy it in its basic rough and ready format
SSD's are the new kool kids on the block, promising lightening fast boot times, data transfer rates that would make any computer nerd drool and power saving arcitecture that all laptop and netbook owners can appreciate. But of course with any new computer hardware they also require some special care. Because of the limited write erase write life of the memory chips used in its components and the particular way the ssd controller needs to write and erase data to those memory chips we will be tweaking our os to accommodate those special needs. With the cost of the solid state drives being rather spendy compared to a standard platter drive you would of course want to get the most life out of your new ssd. They are special devices with special needs, one of which is the need to be partitioned properly. There are also the special considerations involved with temp files, swap partitions, third party software cache's, particular filesystem formats, special filesystem schedulers that can help get the most out of the ssd and the potentially disasterous firmware upgrades. There are also different kinds of ssd drives avalivable, from the smallest and fastest SLC (single layer chip) drives to the slower but much larger capacity MLC (multi layer chip) drives. With any new and shiny hardware though linux soon has (in my opinion) the best answers. Although it may take a little extra time, based on my personel expirence and research, they are extremly fast, efficient, and worth the extra money and effort spent to set up properly. It is my intention to help my fellow PCLinuxOSers to not only set up their new ssd easily with PCLinuxOS but have a fair understanding of the who, what, why, where and when's involved with the ssd. They then can make informed decisions as to what tweaks they will want to use in their individual setup.
NOTE:
I have tried to make this writeup as factual as I can but something (singular) may be in error. I apologise if this is the case, please pm me with the correction. I will contemplate it deeply, pm you back with my reply, thanks or correction and post whatever may prove true. As a fellow pclos user I am an individual (nice easy word for weirdo) with my own particular viewpoint on life (which is most likely way off the chart as far as your particular viewpoint is concerned) and thats what makes linux users different (nice easy word for “not easily herded”). We are not afraid to voice those view's. its what makes each and every one of us unique (nice easy word for dangerous to the system) and special (nice easy word for broke the mold). So if I offend anyone please pm me with a quaint little nastygram and I will consider it with an open (source) mind.
As with anything linux your hardware, software and mental capacity may vary,
loudog.
OOOOOOOOOOOOOOOOOOOOOOOO
DISK PARTITIONING AND FILESYSTEMS
The first consideration is to partition the drive, preparing it for the PCLinuxOS install. As of the writing of this article, (may 2012) the default disk partitioning program on the pclos live cd (diskdrake) partitions the hd with the standard partitioning tables. those work great for a platter based drive (although I noticed in some of OP's forum posts his platter drives are partitioned at the 2048 boundry smarty pants anyway) but for the special needs of the ssd we will use a different partitioning program. I am hoping that future live cd's will address this issue.
Gparted is an open source partititioning tool that runs off a live cd (bootable cd), is easilly downloaded off the internet ( GParted – Download ) and aligns the partitions properly by default so the partitions align exactly with the ssd's memory page blocks. A page is typically 4kb in size with 128 pages grouped together to form a block of data that totals 512kb. This is important because if individual page writes cross the block boundry on the ssd, this will cause extra overhead for the ssd controller (writing and eraseing partialy written blocks instead of whole ones) and can reduce the life of the drive.
If you are savvy enough in the the shell, you can partition the drive during a live cd session. If you dont know what this means then my suggestion is to not try it until you know you can do it properly. Or if your like me, not afraid to do it again and again and again until you get it right, then by all means give it a whirl. If all else fails to give the desired results, gparted can fix anything to do with partitioning.
To use the gparted cd, boot into it, create your root, swap (if any) and your home partitions. It is fairly easy to figure out with the GUI being straightforward and user friendly. I suggest using the ext4 file systen to format them. The ext4 file system is the most widely used in linux for the SSD because it supports the enabling of TRIM and is probably your best choice for the root (/) and home (/home) partition formats (more on TRIM later). Create each partition in order. You may not want a swap partition on the SSD as this has the potential to write and rewrite many times, also as in the case of lots of ram you may not even need a swap partition. I suggest creating a small one just in case, maybe a couple of gigs. You can always delete it later and add it to the root partition, or use that handy gparted disc to add it to the home partition, or create that small, secret, spy next door type, encrypted, hidden, storage space to hide your skeletons in (oh you know you secretly always wanted one anyway). (more on skeletons, ahhh, I mean SWAP later). If your not sure, you may want to skip ahead to the swap section and read it before making a decision at this time. for the case of simplicity, this article will deal with only 1 drive in the system. In my case I created a small swap partition but instructed pclos to never use it unless we were out of RAM or we want to enable hibernation.
If you decide to do the partitioning from the live cd, open a terminal su to root and execute the following command: 'fdisk -cu (device)' , press n for new partition, p for primary and enter a start sector of 2,048. 2048 equates to 1Mb and will cater to all variations of SSD page sizes and filesystem block sizes. If you have started this approach then we assume you know how to finish it as we did advise to the contrary.
So whichever way you decided to go, finish partitioning your drive, format it and install your favorite flavor of PCLinuxOS. Note: for the standard KDE install I make a 12 gb root (/) partition. For full monty (I love that one, everything and the kitchen sink) I make a 20 gb root (/) partition. Check your particular flavor of PCLinuxOS for root (/) partition size recomendations.
Now lets check that the partition tables are in fact properly alligned. Open a terminal and type: su,
Enter the root password and at the prompt type in this command:
fdisk -l (return) (actually enter on the keyboard unless you are using a sun or mac keyboard which have an enter and a return key, one key creates a newline and the other one enters commands for execution) uuuhhh not to get off topic though-
You should see something similar to this:
[root@localhost ~]# fdisk -l
Disk /dev/sda: 60.0 GB, 60022480896 bytes
255 heads, 63 sectors/track, 7297 cylinders, total 117231408 sectors
Units = sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes
Disk identifier: 0x00047095
Device Boot Start End Blocks Id System
/dev/sda1 2048 26494975 13246464 83 Linux
/dev/sda2 26494976 31576063 2540544 82 Linux swap / Solaris
/dev/sda3 31576064 117229567 42826752 83 Linux
[root@localhost ~]
Notice in the lower section under /dev/sda1, the beginning sector has a start point of 2048. This is what we are looking for. The other thing to look for is the sector sizes of 512 bytes. If your partitioning does not reflect the 2048 as your start point my guess is that you would see something simillar to this:
[root@localhost ~]# fdisk -l
Disk /dev/sda: 164.7 GB, 164696555520 bytes
255 heads, 63 sectors/track, 20023 cylinders, total 321672960 sectors
Units = sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes
Disk identifier: 0xaa2eaa2e
Device Boot Start End Blocks Id System
/dev/sda1 * 63 25189919 12594928+ 83 Linux
/dev/sda2 25189920 321669494 148239787+ 5 Extended
/dev/sda5 25189983 33367004 4088511 82 Linux swap / Solaris
/dev/sda6 33367068 321669494 144151213+ 83 Linux
[root@localhost ~]#
Which is from a default platter hd partition alignment (notice the start sector is at 63). If this is the case unfourtunatly the ssd should be repartitioned properly before we move to the next step.
TRIM
So assuming all things are going according to Hoyle and your partitions are alligned correctly, then lets begin the modifications shall we? First we want to enable TRIM as it does not come enabled by default. Contrary to popular belief TRIM is not an acronym (each letter representing a particular word), it is an actual ATA command (you recognise S-ATA, P-ATA dont you) and like all other ATA commands it is written in uppercase letters. the TRIM command informs the ssd controller which sectors are invalid and no longer needed by the os. The controller then erases the invalid data stored on the ssd's page blocks as soon as it is not busy reading and writing for higher priority requests.
When new information is written to empty pages in the block there is no lag time because of the need to erase the block first before the write process can begin but if the ssd controller keeps just writing to empty pages eventually they will all have data written to them and thats when the problems begin. Now lets examine this erase write process a little more closely shall we. Although the controller can read-write information a page at a time, (and very very quickly mind you) it can only erase whole blocks at once (remember a page = 4kb, a block = 128 pages = 512 kb). So lets say 15 of the 128 pages of data in the block are no longer valid. The controller gets the TRIM command and before it can erase those 15 pages it must wait until all other higher priority data transfers are completed, then move the whole block of data into the cache where it will store it for a short while. While the data is in the cache the controller then erases the block from whence it came. Then the controller must re arrange the good data while in the cache (like ram on the computer), removing the stale data and prepare the remaining data for writing back to the pages/block. It can take some real time if a lot of blocks are riddled with pages of stale data. Tests prove that this condition can actually degrade the write time as much as 1000% in extreme cases. So if TRIM (cache, erase, remove, rearrange and rewrite) is done on an as needed basis there will always be lots of fresh empty pages to write to and let me tell you the controller can write very very fast on clean pages. The cleanup of the page blocks has been coined “garbage detail” in some circles.
We will also be instructing the system to ignore certain file writes and updates for the sake of unnessary read writes. We will be editing the /etc/fstab file to do this. So if you are ready lets get started and remember your particular needs may vary, edit as nessary
In a console su to root and execute the following command:
kwrite /etc/fstab
You should see kwrite start and display the contents of the /etc/fstab file. It should look similar to this:
# Entry for /dev/sda1 :
UUID=ff854db4-ac3d-4d37-9a0e-3670162f9222 / ext4 defaults 1 1
# Entry for /dev/sda6 :
UUID=46917512-b6c6-4abc-a13d-844a87907fe5 /home ext4 defaults 1 2
none /proc proc defaults 0 0
# Entry for /dev/sda5 :
UUID=782c8632-8e95-452a-bd36-64b2cec39b07 swap swap defaults 0 0
none /dev/pts devpts defaults 0 0
I am used to kwrite as a text editor and like it as all I need to do is click the save icon and the edits are saved (yes I am from the point and click lazy era) and I can also quickly save a copy of the file to my documents folder for later quick reference, just remember to create a newline at the end of the file before saving it (a newline can be created by simply hitting enter after the last line of text is finished) otherwise the os will display a warning message during startup, (you will see this if you use the verbose option in your kernel stanza). Anyway you can use nano, pico, femto, or any other text editor of your choice.
Here is some info on the modifications we will be implementing as you may need to modify your fstab file to reflect your particular needs or tastes.
NOATIME = NO ACCESS TIME or more correctly put Do not update inode access times on this file system.
This comment implies that the files access times will not be updated each time one is accessed. If you right click a file, then select properties you will be presented with a floura of information on that particular file, one of the things shown is when the last time the file was accesed. You may or may not require this information.
NODIRATIME = NO DIRECTORY ACCESS TIME or more correctly put: Do not update directory inode access times on this filesystem.
This comment implies the same thing as noatime except that the directories are specifically named. There was some debate about the noatime being a superset of nodiratime and the nodiratime comment was not needed as long as you had noatime specified. That debate was addressed in 2007 in which the kernel developer Ingo Molnar was actually using the noatime and the nodiratime together in his fstab file. Andrew Morton (kernel maintainer and developer) sent him an email correcting him on this point:
From: Andrew Morton
To: Ingo Molnar
Subject: Re: [PATCH 00/23] per device dirty throttling -v8
Date: Sun, 5 Aug 2007 00:29:34 -0700
On Sun, 5 Aug 2007 09:21:41 +0200 Ingo Molnar [email blocked] wrote:
> even on a noatime,nodiratime filesystem
noatime is a superset of nodiratime, btw.
So when the noatime comment is used, the nodiratime flag is actually ignored as noatime implies nodiratime in of itself being a superset, although many very recent sources I have looked into still suggest using both comments in the fstab file. Me? I will take Andrews word on this (unless someone can prove otherwise) but at the time I wrote this article I had still not edited out the nodiratime comment in my fstab file, ya ya ya lazy loudog I know.
.
Note: I am not sure how these comments that affect access time updates may affect a cron job that updates your files per time signitures and does a routine backup of your information but you may want to investigate that if you plan on regular backups using cron or other similar backup software.
DISCARD = TRIM The operating system informs the ssd controller which pages of data are considered no longer in use so the controller can safely wipe them clean, preparing them for a fresh clean write.
We want to add the following string (edit as needed) to the file just after the file type callout (in this case ext4)
/dev/sda/ext4 noatime,nodiratime,discard,errors=remount-ro 0 1
Save the changes, exit kwrite and reboot. Now in the terminal su to root and type in this command:
cat /etc/fstab
Your new fstab file should look similar to this:
[root@localhost ~]# cat /etc/fstab
# Entry for /dev/sdc1 :
UUID=d1c07a82-231e-4c59-83b0-3974621f168f / ext4 noatime,nodiratime,discard,errors=remount-ro 1 1
# Entry for /dev/sdc3 :
UUID=78ae2f65-de71-41bf-86da-58f644ad011e /home ext4 noatime,nodiratime,discard,errors=remount-ro 1 2
none /proc proc defaults 0 0
# Entry for /dev/sdc2 :
UUID=b1e16be8-d609-4de0-acaa-29180fed2416 swap swap defaults 0 0
none /dev/pts devpts defaults 0 0
Looks good. Now friends lets see if trim is actually working. In a terminal type in:
seq 1 1000 > testfile (step away from the comment button youcantoo) mmmm, inside joke.
What we have done is created a small file on the drive for testing purposes. Now we want to look and see where the file is sitting on the drive so in the terminal type in:
hdparm --fibmap testfile
You should see something similar to this:
testfile:
filesystem blocksize 4096, begins at LBA 2048; assuming 512 byte sectors.
byte_offset begin_LBA end_LBA sectors
0 4662176 4662183 8
We are concerned with the beginning sector number which in my case here is 4662176. What we want to do now is look at the actual numbers on the sdd's block. For the hdparm command to execute cleanly and show us what we want to see we need to flush out the buffer and we do this with a simple command:
# sync
Then we execute the command:
# hdparm --read -sector 4662176 /dev/sda
Remembering that the /sda reflects my hard drive's designation yours may be different. You should see something like this:
/dev/sda:
reading sector 4662176: succeeded
0a31 0a32 0a33 0a34 0a35 0a36 0a37 0a38
0a39 3031 310a 0a31 3231 310a 0a33 3431
310a 0a35 3631 310a 0a37 3831 310a 0a39
3032 320a 0a31 3232 320a 0a33 3432 320a
0a35 3632 320a 0a37 3832 320a 0a39 3033
330a 0a31 3233 330a 0a33 3433 330a 0a35
3633 330a 0a37 3833 330a 0a39 3034 340a
0a31 3234 340a 0a33 3434 340a 0a35 3634
340a 0a37 3834 340a 0a39 3035 350a 0a31
3235 350a 0a33 3435 350a 0a35 3635 350a
0a37 3835 350a 0a39 3036 360a 0a31 3236
360a 0a33 3436 360a 0a35 3636 360a 0a37
3836 360a 0a39 3037 370a 0a31 3237 370a
0a33 3437 370a 0a35 3637 370a 0a37 3837
370a 0a39 3038 380a 0a31 3238 380a 0a33
3438 380a 0a35 3638 380a 0a37 3838 380a
0a39 3039 390a 0a31 3239 390a 0a33 3439
390a 0a35 3639 390a 0a37 3839 390a 0a39
3031 0a30 3031 0a31 3031 0a32 3031 0a33
3031 0a34 3031 0a35 3031 0a36 3031 0a37
3031 0a38 3031 0a39 3131 0a30 3131 0a31
3131 0a32 3131 0a33 3131 0a34 3131 0a35
3131 0a36 3131 0a37 3131 0a38 3131 0a39
3231 0a30 3231 0a31 3231 0a32 3231 0a33
3231 0a34 3231 0a35 3231 0a36 3231 0a37
3231 0a38 3231 0a39 3331 0a30 3331 0a31
3331 0a32 3331 0a33 3331 0a34 3331 0a35
3331 0a36 3331 0a37 3331 0a38 3331 0a39
3431 0a30 3431 0a31 3431 0a32 3431 0a33
3431 0a34 3431 0a35 3431 0a36 3431 0a37
3431 0a38 3431 0a39 3531 0a30 3531 0a31
3531 0a32 3531 0a33 3531 0a34 3531 0a35
Great! Now lets remove the file, flush the buffer and re read the file. In the terminal type the following command:
# rm testfile
You will be asked to verify the removal of the file.
rm: remove regular file `testfile'? Y (type the y for yes then enter)
Flushing the buffer again
# sync (enter)
Re read the file with the command:
