How to turn auto degramenting off?

Discussion in 'macOS' started by wonderbread57, Feb 3, 2009.

  1. wonderbread57 macrumors 6502

    Jun 11, 2008
    Word on the street is that OS X performs some sort of auto or on-the-fly defragmenting of files 20mb or less. How do you turn off this feature?

    I have an SSD drive and thus defragmenting of any kind is completely unnecessary as the drive random access time is minuscule. Additionally, the drive controller deliberately spreads bits around the drive to even out the use of cells of memory so the drive lasts longer. So, defragmenting is actually detrimental to SSD drives and works against their built in algorithms.
  2. PrinceOfEgypt macrumors member

    Jul 2, 2008
    AFAIK that is a feature of the HFS+ file system, not of "OS X" per se..

    I'm only guessing, I would imagine the HFS+ takes the SSD case into account? Apple sells laptops with SSDs, I can't imagine they wouldn't address this??
  3. ppc750fx macrumors 65816

    Aug 20, 2008
    Defragmenting isn't going to shorten your drive's lifespan by a meaningful amount, esp. given that modern SSDs have wear-leveling (as you described.) That goes double for SLC drives.

    Don't worry about it.
  4. saltyzoo macrumors 65816


    Oct 4, 2007
    There is no auto-defragger. The file system is designed to better avoid fragmenting files. It does not auto-defrag files.
  5. wonderbread57 thread starter macrumors 6502

    Jun 11, 2008
    I would assume the same. I only wonder though if there is some configuration that is set in OS X for SSD laptops that go out the door. Do I need to tend to these settings? Probably not, I'm guessing OS X detects this kind of thing at startup and applies whatever drive configs are appropriate.. although I am curious what those are.

    Just seems that defragmenting tells bits to line up, then wear-leveling says, no don't line up! then defragmenting says... I suppose this kind of thrashing would be noticeable right away but hasn't come up.

    Bottom line... There is no difference between the OS X that Apple ships for proucts configured with SSD vs. regular HD. Safe to say?
  6. PrinceOfEgypt macrumors member

    Jul 2, 2008
    I'm not a low level hardware engineer, but if I had to guess, I would imagine that the SSD drive does not let the file system know anything about the physical wear leveling. Logically, HFS might think that it is defragmenting the file (as in using contiguous inodes) but in reality the SSD controller is still spreading the data around the drive...

    again, this is a complete guess, but it makes sense to me. as far as your second question then the answer would be "exactly the same."
  7. ppc750fx macrumors 65816

    Aug 20, 2008
    That is incorrect. Files smaller than 20MB are defragmented on access.

    There's also hot file clustering and some other similar stuff going on that's not strictly defragmenting.

    The FS doesn't know (and doesn't need to know) that the SSD is doing wear-leveling.

    The reason I told you not to worry is that with modern technology, you're simply just not gonna hit the MTBF of a modern SSD. The technology's improved tremendously since it first became popular, and any modern SSD is (most likely) going to last for longer than you have the computer.

    Correct. There is no indication that the version of OS X shipped on SSD-based models is any different than that shipped on models configured with conventional storage.
  8. PrinceOfEgypt macrumors member

    Jul 2, 2008
    not to nitpick, but they are defragmented on access only if very specific scenarios are met. and Saltyzoo is partially right - the file system goes to a lot of trouble to avoid creating those scenarios.

    I think the bottom line (for the benefit of the OP) is to not worry about it. it will just work and work well.
  9. Amdahl macrumors 65816

    Jul 28, 2004
    I will also concur that this is nothing to worry about. There is probably no option to disable defrag on SSD, because the side effects aren't worth worrying about. OS X does not know about the wear-leveling, so they are not fighting each other.

    While HFS+ may have some features to help the OS figure out how to reduce fragmentation, HFS+ itself doesn't do anything about fragmentation. HFS+ is merely a data structure, not code. Avoiding fragmentation is entirely up to the OS allocation algorithms. You could create an evil-OSX that creates the most fragmentation possible, and the fact it was on HFS+ would make no difference.

    For instance, NT 4 had a horrible allocation algorithm on NTFS, while NT5/Win2K had an improved one. An NT 4 system would fragment like crazy; probably as bad as FAT did. (Partially why NT4 only ran well on SCSI systems that could issue multiple reads at once) Win2K/XP still can get pretty nasty, but it is not as bad. And on XP, auto-defrag and boot-optimize of the key OS files keeps performance from really dropping off a cliff. Win2K would get slow after a while, and even the built in Defrag app couldn't help it because it was in system files. PageDefrag from Mark Russinovich/SysInternals(now MS) helps out with that.
  10. MisterMe macrumors G4


    Jul 17, 2002
    My understanding is the exact opposite. HFS+ was introduced with MacOS 8.1. No version of MacOS 8 or MacOS 9 defragged automatically. Automatic defrag is a feature of MacOS X, not the filesystem. That said, HFS+ and HFS before it are very robust filesystems for which fragmentation displays little measurable effect on system performance.
  11. PrinceOfEgypt macrumors member

    Jul 2, 2008
    hmm, I think we are both right. according to the auto defgramentation was an HFS+ optimization introduced in Panther. it could very well be implemented in the file system drivers in OS X. Regardless, you are correct that it is an OS X only feature. Maybe I should have said that it is a feature that you get when you use HFS+ under MacOS X
  12. Amdahl macrumors 65816

    Jul 28, 2004
    Sorry to be bringing this thread back, but the recent articles by Ars Technica and observations of firmware bugs(update available) in Intel's X25-M SSD drive, show that fragmentation is an issue on SSDs. There is internal fragmentation, which is not visible to the OS, and 'normal' fragmentation, that we all know about.

    The internal fragmentation that was noticed on the X25-M turns out to have been due primarily to a bug in the firmware. Once updated, it self corrects. But the observation by users that different SSDs show different performance based on the read/write patterns means that 'normal' fragmentation is still an issue.


    Because typically SSDs that are considered 'slow,' are slow at random writes, whereas they are faster at sequential writes. This means if you have a fragmented file, writes to that file will run slower to the SSD than if the file was defragmented. (Yes, this means the wear leveling algorithms are working on blocks larger than a single sector or file system block.)

    In particular, this is very noticeable with Safari's Cache.db and SafeBrowsing.db files.

    So, selective defragmentation is still a good idea for SSD users, even as the products improve. This is because sequential writes can often be done in one erase cycle, while the same amount of data written randomly requires an read/erase/write cycle for each fragment.

    You can see my script for defragging Safari cache here:
  13. zeeklancer macrumors regular

    Jan 1, 2008
    I am sure that the 20 meg defrag feature spoken about works on the fly, thus not affecting the actual disk or using the disk, and would explain the 20 meg limit.

    So, you go to write a file, all of the file is stored in ram while the FS in this case HFS+ looks for a set of free contiguous blocks that is able to store the entire file. Once it finds one it writes. This happens all real fast and likely can not be turned off, and would be really pointless to turn off.

    Yes, the word defrag makes you think that it would actually write the file, then go back and defrag it later, but that would be the most crappy way to do anything and would be stupid. Apple is not stupid...


Share This Page