Mac OS "Journaled" or not on SSD?

[MacUser2525]

Then, RamDisk for Caches:

diskutil erasevolume HFS+ RamDisk `hdiutil attach -nomount ram://2000000`;
sudo rm -Rf ~/Library/Caches;
mkdir /Volumes/RamDisk/Caches;
ln -s /Volumes/RamDisk/Caches ~/Library/Caches;
sudo rm -Rf /Library/Caches;
sudo mkdir /Volumes/RamDisk/LibraryCaches;
sudo ln -s /Volumes/RamDisk/LibraryCaches /Library/Caches;

Still burning 8 GB for day while sitting idle. Lots of work with fs_util. Up to 9375 days while sitting idle till write exhaustion. I don't sit idle, so I didn't like that I was still burning through 1% of my disk's life every 100 days not doing anything.

sudo launchctl unload -w /System/Library/LaunchDaemons/com.apple.systemstats.daily.plist

Unloaded similarly all other systemstat* daemons in ../LaunchDaemons and ../LaunchAgents.

Unloaded, killed, and renamed the Quicklook daemon so it would not come back to writing useless "quicklook files" (I don't need it that bad):
cd /System/Library/Frameworks/QuickLook.framework/Resources/quicklookd.app/Contents/MacOS
sudo mv quicklookd quicklookd.disabled
sudo mv qlmanage qlmanage.disabled

Unloaded residual Symantec daemons.

Finally, USED DISKUTIL WITH THE MOUSE+[option key] to turned journalling OFF! (I did this off line by booting with Alt-R).

Disk at idle is now down to 13.2 MB per hour, i.e. 300 MB per day! At that rate, the disk will last 684 years. I like both machines I am running on (MBP and MacMini), each now has maximum RAM (16 GB and 8 GB) and I intend to keep them operation at least 10 years. Running out of SSD life half way in between is now one less thing to worry about.

Bottom line is that journalling is worth at least 5 GB per day of disk writes, exhausting the multilevel cell technology in the consumer SSDs at an excessive rate.

I am going back to search for an Antivirus replacement that doesn't burn disk writes excessively.

With regards to journaling, I doubt I would ever need it on the macmini. I could have a brain farht and let the MBP run out of battery, so I will think about that.

If your that determined about it no sense in having the last access time being written either. A file containing this will disable that as well.

MacUser2525:~$ cat /Library/LaunchDaemons/com.nullvision.noatime.plist
<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE plist PUBLIC "-//Apple//DTD PLIST 1.0//EN"
        "http://www.apple.com/DTDs/PropertyList-1.0.dtd">
<plist version="1.0">
    <dict>
        <key>Label</key>
        <string>com.nullvision.noatime</string>
        <key>ProgramArguments</key>
        <array>
            <string>mount</string>
            <string>-vuwo</string>
            <string>noatime</string>
            <string>/</string>
        </array>
        <key>RunAtLoad</key>
        <true/>
    </dict>
</plist>

 

[MacMan2014]

Agreed -- turned off atime, i.e. noatime early on

I followed someone's guide for turning OFF atime (access time) by running noatime plist daemon modificaiton as you stated above.

Definitely you want noatime. I think it is a useless filesystem attribute.

Note that the Finder still seems to have a "last opened" field. I'd like to kill that too -- I don't need to know that when searching for a file. I wonder how it is stored on the hard drive. That is another 8K of sector information written by the kernal.

 

[MacUser2525]

I followed someone's guide for turning OFF atime (access time) by running noatime plist daemon modificaiton as you stated above.

Definitely you want noatime. I think it is a useless filesystem attribute.

Note that the Finder still seems to have a "last opened" field. I'd like to kill that too -- I don't need to know that when searching for a file. I wonder how it is stored on the hard drive. That is another 8K of sector information written by the kernal.

Don't know if it is totally useless as it is part of the security idea of a unix system but for our use of that system it certainly is. Nobody gets access to my machine but me and if someone from outside does well it is game over anyways. Don't matter what files they accessed I would wipe and start over with no files transferred back from old install. I have all my files that are important to me on powered off backup drives.

 

[haravikk]

First, I killed Symantec Antivirus. Whatever version I was running was a pig -- 200 GB per day! Now down to 10 GB per day. I'm looking for a replacement that doesn't write all over my SSD over and over again.

I used Intego VirusBarrier for a while, but I got fed up with them as their updates never seemed to actually improve anything, just change what it looked like and get rid of features I used. A lot of their features are also implemented in a very strange way (NetBarrier for example is a total mess, and essentially useless), and every so often you'd get an update that required a restart, which is just annoying as a well designed app shouldn't require it.

So I decided to stop throwing money their way and have been using Avast! Antivirus for Mac instead; it's free, seems to do the trick and is very lightweight.

Then, RamDisk for Caches

Personally I think it's overkill; the whole point of caches is to be able to reload data faster (less writes overall), so using a RAM disk means they'll be empty every time you restart, I've also found that RAM disks can get unmounted on sleep, and I've had others just unmount themselves seemingly at random.

I did used to use a RAM disk for /private/tmp, since for some reason OS X doesn't have a tmpfs equivalent, which I find kind of weird. You need to mount it with the union option which lets you set an existing directory as a target, that way the RAM disk takes over all subsequent writes, so it doesn't mess up your system.

But I stopped doing it as I don't think it was really making much of a difference personally. I do still use RAM disks for certain things though, such as macports' build folder as that's only needed temporarily and can be very write heavy when in use.


One optimisation I didn't see you mention was disabling access times for an SSD. Personally I do it for most volumes, as updating a timestamp for every file, every time it's opened, just isn't very useful in my experience, but it results in a ton of extra writes for no good reason. Granted they're not very big, but I haven't found a use case where I need it enabled, and you can generate a lot of extra writes with access times enabled.

To disable it you need to run:

mount -uwo noatime /

Replacing the slash for a path to a more specific volume if you prefer (in quotes if it has spaces). In my case I've set noatime on my root (startup) volume and my Time Machine volume.

Best thing to do is pop the command in a launch daemon and set it to start on mount. Personally I created a little script to run, so it'll only run the command if the target volume is mounted, and won't do anything if noatime is already set.


As to the original topic; I don't know if I'd disable journaling personally, as it helps prevent your file-system from getting into a corrupted state. Granted I'd prefer a file system that did copy-on-write instead, as it's more efficient and has other advantages as well, but Apple don't seem to be in a hurry to give us a new file-system.

 

[pmau]

A word about journalling on Filesystems

Journalling is very important to the FS to be able to recover even minor inconsistencies.

All file operations are causing multiple physical updates in the fs, not only the data that is written. By having a journal of the last N operations on the filesystem, the OS is able to replay them from a last known good starting point.

If zou disable the journal, fsck_hfs (or diskutil for that matter) has to guess what the current state of a file might be. This happens more often than you might think.

Just boot from an external drive and do a real fsck with catalog rewriting and you'll be surprised how many inconsistencies happen over time.

Journalling is a good thing. Don't disable it.

EDIT:

I should probably be more clear. With journalling, file attribute changes are written into the journal first and are written to the real OS only once (last update changes the attributes).

If you disable journalling, you make all attribute changes directly causing more I/O, not less.
The atime trick doesn't help much. Use sudo fs_usage -filesys to see how much is actually rewritten every few seconds anyways. Preferences, Caches, SQLite lockfiles, etc. The atime is the least of zour problem.

 

[k-hawinkler]

Yes, I am reopening an old thread.

I have bought new SSD's with 75 TB useful write lives.

I was originally a little shocked when installed in one machine, running Mavericks, after 3 days I had already written 730 GB. At that rate, my SSD would be done in 100 days just like Ann Boleyn. I had already turned trim on and a few other tweaks that have been described adequately on the internet.

So I started working. First, I killed Symantec Antivirus. Whatever version I was running was a pig -- 200 GB per day! Now down to 10 GB per day. I'm looking for a replacement that doesn't write all over my SSD over and over again.

Then, RamDisk for Caches:

diskutil erasevolume HFS+ RamDisk `hdiutil attach -nomount ram://2000000`;
sudo rm -Rf ~/Library/Caches;
mkdir /Volumes/RamDisk/Caches;
ln -s /Volumes/RamDisk/Caches ~/Library/Caches;
sudo rm -Rf /Library/Caches;
sudo mkdir /Volumes/RamDisk/LibraryCaches;
sudo ln -s /Volumes/RamDisk/LibraryCaches /Library/Caches;

Still burning 8 GB for day while sitting idle. Lots of work with fs_util. Up to 9375 days while sitting idle till write exhaustion. I don't sit idle, so I didn't like that I was still burning through 1% of my disk's life every 100 days not doing anything.

sudo launchctl unload -w /System/Library/LaunchDaemons/com.apple.systemstats.daily.plist

Unloaded similarly all other systemstat* daemons in ../LaunchDaemons and ../LaunchAgents.

Unloaded, killed, and renamed the Quicklook daemon so it would not come back to writing useless "quicklook files" (I don't need it that bad):
cd /System/Library/Frameworks/QuickLook.framework/Resources/quicklookd.app/Contents/MacOS
sudo mv quicklookd quicklookd.disabled
sudo mv qlmanage qlmanage.disabled

Unloaded residual Symantec daemons.

Finally, USED DISKUTIL WITH THE MOUSE+[option key] to turned journalling OFF! (I did this off line by booting with Alt-R).

Disk at idle is now down to 13.2 MB per hour, i.e. 300 MB per day! At that rate, the disk will last 684 years. I like both machines I am running on (MBP and MacMini), each now has maximum RAM (16 GB and 8 GB) and I intend to keep them operation at least 10 years. Running out of SSD life half way in between is now one less thing to worry about.

Bottom line is that journalling is worth at least 5 GB per day of disk writes, exhausting the multilevel cell technology in the consumer SSDs at an excessive rate.

I am going back to search for an Antivirus replacement that doesn't burn disk writes excessively.

With regards to journaling, I doubt I would ever need it on the macmini. I could have a brain farht and let the MBP run out of battery, so I will think about that.

Many thanks. How do you find out how many TByte were written to the SSD? TIA.