Trash empty and rm -rf very slow with Apple SSD

Discussion in 'macOS' started by Vindii, Jun 18, 2014.

  1. Vindii macrumors newbie

    Joined:
    Jun 18, 2014
    #1
    I have a Mid 2009 MBP with an original factory Apple SSD TS128A, running Mavericks.

    Terminal's 'rm -rf' and emptying trash is taking a super long time, and I am at a complete loss as to why.

    Secure empty trash is disabled

    (XCode is just an example, it has about 20,000 files and is about 5 gigabytes)
    I ran "time sudo rm -rf /Applications/Xcode6-Beta2.app/" and the result was 12 minutes. Using trash to delete results in a similar time.

    I asked my friend with a Macbook Air to delete his old Xcode6 beta as well, it took him 30 seconds, so it is taking me 24 times longer.

    Troubleshooting steps I have taken already:

    • Reboot
    • Copy a fresh directory and delete that
    • Run disk utility repair permissions and verify disk (no problems)
    • Checked TRIM support (it is disabled, I suspect the drive has garbage collection?)
    • Tried to enable TRIM using TRIM enabler (it didn't work)
    • Checked and double checked secure empty trash is disabled
    • Used GSmartControl to look at the SMART status of the SSD, it seems fine, but it's hard to tell

    I am completely at a loss as to what to try next. I suspect this is some weird configuration problem that has resulted from upgrading the OS over the years since Leopard, or that the SSD is on it's way out.

    The performance otherwise seems fine, the machine boots in about 15 seconds and Apps open fine, I used Blackmagic Drive Speed Test to benchmark and get about 90MB/sec write and 120MB/sec read, which I believe is normal for this setup. Writing large numbers of new files might be slow, unpacking XCode again takes about 10 minutes and at times goes only 1-2MB per second.

    Halp? <3
     
  2. ScoobyMcDoo macrumors 65816

    Joined:
    Nov 26, 2007
    Location:
    Austin, TX
    #2
    I have no idea why file deletion performance would be poor, but other performance is ok as you claim. I thought I would share my performance metrics with you for comparison. This is from a mid 2010 MBP with a samsung 840 512GB SSD. Write: 256, Read 269.
     
  3. pmau macrumors 65816

    Joined:
    Nov 9, 2010
    #3
    I understand your issue and have seen it myself, but I have not figured out why.
    However I do not believe it's hardware.

    Here's a few thoughts about the difference between behavior of different MacBooks.

    1) fseventsd

    There's a daemon running in the background that records all FS activity to have a sequence point for backups.

    Question you should ask yourself:
    a) Do I use TimeMaschine
    b) Do I use local TimeMaschine backups
    c) How many entries are in /.fsevents.

    use:
    sudo ls -la /.fseventsd/


    2) Spotlight indexing

    Spotlight removes stuff from its index during deletion.
    Check if something goes wrong while deleting, i.e high cpu usage of mds.

    use:
    sudo fs_usage -filesys

    To see what happens.


    3) Do you use Dropbox

    I have seen cases where dropbox freaks out and monitors file changes outside of its dropbox folder.

    Check for Dropbox process activity.


    I would like to hear back from you. I have ONE MacBook with a Samsung SSD that misbehaves, but I have not figured out why.

    Keep in mind that deleting requires Catalog updates on each removal HFS+ which includes Journaling. Perhaps you could backup and restore your mac to defragment your HFS catalog.
     
  4. Vindii thread starter macrumors newbie

    Joined:
    Jun 18, 2014
    #4
    After some further investigation, I think I've identified the culprit as Time Machine.

    I was going to mention it in my original post, but I disconnected my network drive so I assumed it wasn't an issue. Nope, that made it much worse.

    Following the advice of user pmau I looked at processes consuming CPU during the delete operation, and mtmd was comsuming the vast majority.

    A little googling around identified this as a process responsible for creating Time Machine local backups while the actual time machine backup destination is disconnected.

    Disabling time machine changed the delete time from 12 minutes to about 1 minute, which I think is normal.

    To be extra super sure, I decided to install Yosemite on a separate partition, installed XCode and deleted it, and sure enough 1 minute.

    Now, I had no idea Time Machine could result in such a massive performance difference. I decided to test with Time Machine enabled and the backup destination connected, which resulted in a deletion time of 2 minutes, only half the speed, which is an acceptable penalty in my opinion.

    So I believe the central issue in this case was Time Machine creating local backups of anything I delete, which still seems oddly bad considering I deleted another item with 2000 files and 8 gigabytes in 3 seconds, and another item with 15,000 files and 1 gigabyte in 1 second. I'm not sure what causes XCode in specific to be so bad, perhaps it has a heap of symbolic link craziness, but it seems uniquely bad compared to other types of file collections.

    I'm satisfied nothing is "wrong", just performance is much worse than I expected in some small corner cases.
     
  5. Weaselboy Moderator

    Weaselboy

    Staff Member

    Joined:
    Jan 23, 2005
    Location:
    California
    #5
    Interesting find...

    Yes with TM on anything you delete does not really go away it just gets moved to a hidden /.MobileBackups folder where TM will finally delete it when your disk reaches 80% full. You can see it in action if you turn TM off then back on this folder will be zero. Then empty some trash and you will see the folder grow by the size of the trash dump. Odd system for sure.

    This Terminal command will show you the size of the hidden folder.

    Code:
    sudo du -hs /.MobileBackups
     

Share This Page