Hard Disk Hardware SSD Smartctl – How to Check Life Left in SSD

In general you can just ignore fragmentation altogether. More so for SSD which do not suffer from seek times like HDD. Defragmenting a SSD will do nothing except waste write cycles.

Although there may be extreme cases where fragmentation has a noticable effect, such as a sparse file written to in random order (as some BitTorrent clients do), or when the disk runs out of free space, when the last file that was written to will be split up in thousands of fragments as there was no other consecutive space available to fit the needs.

But that's the exception. It doesn't happen usually. Most filesystems are very good at avoiding fragmentation, and the Linux kernel is good at avoiding ill effects caused by fragmentation. Once more than one process read/write files concurrently, the disk will have to be everywhere at once anyway.

There aren't too many defragmentation solutions for Linux. XFS has xfs_fsr which works great, so if you absolutely want to use defragmentation, XFS is a good choice.

You can check file fragmentation using filefrag or hdparm:

# filefrag debian-6.0.6-amd64-netinst.iso 
debian-6.0.6-amd64-netinst.iso: 4 extents found

# hdparm --fibmap debian-6.0.6-amd64-netinst.iso

debian-6.0.6-amd64-netinst.iso:
 filesystem blocksize 4096, begins at LBA 0; assuming 512 byte sectors.
 byte_offset  begin_LBA    end_LBA    sectors
           0    3003928    3072407      68480
    35061760    2872856    2938391      65536
    68616192    2171576    2302647     131072
   135725056   56259072   56338047      78976

If that doesn't give you hundreds or thousands of extents (fragments), it's nothing to worry about.

A generic defragmentation method is to make a copy of the file and then replace the original with it, such as:

cp -a yourfile yourfile.defrag
mv yourfile.defrag yourfile

Your filesystem should have a good amount of free space as otherwise the probability is high that the new file will just be as fragmented as the old one. (Check if the new file is better than the old one before replacing).

But as I said, there is usually no need to do this unless a file got a really bad case of fragmentation somehow.

From the smartctl man page:

The Attribute table printed out by smartctl also shows the "TYPE" of the Attribute. Attributes are one of two possible types: Pre-failure or Old age. Pre-failure Attributes are ones which, if less than or equal to their threshold values, indicate pending disk failure. Old age, or usage Attributes, are ones which indicate end-of-product life from old-age or normal aging and wearout, if the Attribute value is less than or equal to the threshold. Please note: the fact that an Attribute is of type 'Pre-fail' does not mean that your disk is about to fail! It only has this meaning if the Attribute´s current Normalized value is less than or equal to the threshold value.

If the Attribute´s current Normalized value is less than or equal to the threshold value, then the "WHEN_FAILED" column will display "FAILING_NOW". If not, but the worst recorded value is less than or equal to the threshold value, then this column will display "In_the_past". If the "WHEN_FAILED" column has no entry (indicated by a dash: ´-´) then this Attribute is OK now (not failing) and has also never failed in the past.

So according to the smartctl output section you have posted, your drive actually looks in good shape. However, that doesn't necessarily mean that there is not another problem.

Unfortunately the Unhandled sense code message does mean that something went wrong, but the kernel doesn't know what. You could try looking at the rest of the smartctl output to see if there is any thing wrong. There should be a part tha summarises the drive's overall health. You can get it on its own with the -H option.

If the drive supports self testing, you can start one with:

smartctl -t long /dev/sda

This starts one in the background, so you will have to keep checking for results. If the drive is not mounted, you can add the -C option enable captive mode which should take less time. A short test is also possible, but less thorough.

It is also a good idea to check physical connectors etc to make sure nothing as come loose - its an easy fix if it has.

Update

Wikipedia has a good reference for smart attributes. Note that the 'Better' column refers to the raw values in rightmost column of the output and not the normalised value at the start. Here is the part on 'Current Pending Sector' mentioned by frostschutz:

Count of "unstable" sectors (waiting to be remapped, because of unrecoverable read errors). If an unstable sector is subsequently read successfully, the sector is remapped and this value is decreased. Read errors on a sector will not remap the sector immediately (since the correct value cannot be read and so the value to remap is not known, and also it might become readable later); instead, the drive firmware remembers that the sector needs to be remapped, and will remap it the next time it's written. However some drives will not immediately remap such sectors when written; instead the drive will first attempt to write to the problem sector and if the write operation is successful then the sector will be marked good (in this case, the "Reallocation Event Count" (0xC4) will not be increased). This is a serious shortcoming, for if such a drive contains marginal sectors that consistently fail only after some time has passed following a successful write operation, then the drive will never remap these problem sectors.