Take the 2-minute tour ×
Unix & Linux Stack Exchange is a question and answer site for users of Linux, FreeBSD and other Un*x-like operating systems.. It's 100% free, no registration required.

This page demonstrates that defragmentation is beneficial for SSDs. I suppose this type of defragmentation has to be trim-aware, so as to preserve the life time of the disk. How can I do that on linux?

EDIT: Comments pointed out that this article's content is questionable.

share|improve this question
7  
The numbers seem ridiculous to me. Invented by people who want to sell something. The question is not: "How can you 'optimize' a file system state for worst performace?" The question is: "What is the difference in real life?" –  Hauke Laging May 27 '13 at 17:59
3  
+1 I totally agree with @Hauke. Also note that this article was published back in 2008. The technology has evolved quite a bit since then. Frankly I never experienced any noticeable speedup after defragging spinning disks. I'm even more suspicious of defragmenting SSDs, the general consensus seems to be not to do it –  djf May 27 '13 at 21:02
1  
Keep in mind that "this page" is actually an ad for apacer (they wrote it) and that the "defragmentaion software" they bundle may well be something that just compensates for limitations with their hardware. SSD firmware does complicated stuff with TRIM, wear leveling and virtual addressing the space, I believe, so a drive that doesn't do that very well may benefit from software the manufacturer wrote to compensate. Then they dress it up and market it. I'd look for specific recommendations from your manufacturer, not Apacer. –  TAFKA 'goldilocks' Sep 11 '13 at 13:28
add comment

6 Answers

up vote 7 down vote accepted

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.

share|improve this answer
add comment

For ext4 the defragger is called e4defrag. (It's now part of the official e2fsprogs).

There's also an fstrim command which should work on both ext4 and (I'd think) xfs. It sends discard requests for unused space on the filesystem. It could be particularly useful if your filesystem was not mounted with -o discard (i.e. sending discards for deleted files immediately).

None of this gets set up automatically. Unless you're very unusual, you don't need e4defrag.

The TRIM stuff is more relevant. It got turned off by default because the performance story at the time was really unclear (i.e. enabling it sometimes saw large slowdowns). Sorry, this is linux w/ new hardware :). I tend to enable the discard mount option at install time, and I haven't seen horrible hangs when deleting files. (Crucial m500 SSD).

If you read SSD reviews, most of them work best if you don't keep them 100% full :). It's not compulsory, but one way to reserve the space (e.g. 10%) and prevent it being used is simply not to allocate the entire device when you partition it.

share|improve this answer
    
+1 for -o discard. Which is in man mount, if anyone's interested. –  TAFKA 'goldilocks' Sep 11 '13 at 13:31
add comment

Others have mentioned that defragementation might not have an effect on SSD. (I realize this is an old question, but I'd like to add context.)

I'd like to advance a stronger version of the same argument: the concept of defragmentation doesn't make any sense for SSD at all. The SSD does not write sequential logical blocks to sequential blocks in flash; in order to maximize throughput, the SSD controller will spread blocks across multiple NAND chips (kind of like a mini-RAID).

See: http://www.anandtech.com/show/2829/5

The SSD controller figures out where to write blocks for best speed and also to wear each flash cell evenly. Therefore, even logical blocks that appear (to the OS) to be in sequential order are actually stored in a completely different order on NAND -- and this is a good thing. The idea of defragmenting something that is supposed to be fragmented makes no sense.

share|improve this answer
add comment

The author of the article is selling snakeoil. While it is true that you will see a decrease in performance on an SSD if you do fully random small block ( 4k ) IO, this never happens in practice, even on Windows filesystems that are notorious for badly fragmenting themselves. The effect of fragmentation on an SSD is something on the order of 100-1000 times less than an HDD. A seek introduced even every 64k has negligible impact on throughput on an SSD. When you consider Linux filesystems don't fragment badly enough in practice to need defragmenting even on an HDD, and the fact that the writes introduced by any attempt to defrag reduce the life of the disk, it clearly should be avoided.

If you insist on defragging ext[234], you can do so with the old e2defrag program.

share|improve this answer
    
Google found a pretty graph. Negligible impact might be the wrong word for the trend, but the figures there for 64k random IO are matching hard drive sequential IO (150MB/s), which backs up your answer. –  sourcejedi May 29 '13 at 20:07
add comment

Fragmentation is bad for SSDs because it causes write amplification (SSDs need to copy entire erase blocks for much smaller writes; recent low-quality SSDs can go up to 2MB erase blocks). Defragmentation isn't a terribly good idea either, since it just churns through cells to make the next write slightly faster (your link does make that point: just because fragmentation is bad, doesn't mean defragmenting is better).

Instead, you should focus on using a filesystem that doesn't cause fragmentation. XFS/ext4/Btrfs preallocate entire extents. Log-structured filesystems (nilfs2, f2fs) are good too. If you set it up with the right erase block size, bcache will also behave like a log-structured filesystem.

share|improve this answer
add comment

The tool you are looking for is fstrim. It can be scheduled daily, weekly or during night if you do not turn off your laptop/server:

cat /etc/cron.weekly/01-fstrim
#!/bin/sh
fstrim /
fstrim /home

chmod +x /etc/cron.weekly/01-fstrim

Try to run the script now, it should not print any error message. If you changed LUKS configuration, you might need restart before doing that.

http://lukas.zapletalovi.com/2013/11/how-to-trim-your-ssd-in-fedora-19.html

share|improve this answer
add comment

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.