Searching on Github, this seems to be it. Turns out, there's releases for Arch, Debian, etc. and it's even in the repositories. No need to add a ppa. https://github.com/graysky2/profile-sync-daemon

For Debian and co:

    $ apt-cache show profile-sync-daemon
    $ sudo apt-get install profile-sync-daemon

    bird	         11,38 GB   119,8 MB		
    kernel_task	          8,82 GB    23,0 MB
    launchd	          8,46 GB    77,7 MB	
    revisiond	          8,35 GB   105,8 MB	
    Tweetbot	          3,01 GB    50,2 MB	
    Safari	        879,6 MB     10,0 MB	
    mds_stores          726,2 MB    570,1 MB		
    systemstatsd        695,0 MB    775,0 MB
    nsurlstorag         685,3 MB      9,5 MB	
    Google Chrom        681,4 MB    303,5 MB		
    iTerm2	        653,7 MB      1,6 GB	
    cfprefsd	        509,1 MB     45,8 MB	
    Papers 3.4.7        465,9 MB    169,8 MB
    cloudd	        441,3 MB      9,7 MB
    ruby	        224,6 MB      1,7 MB	
    coreduetd	        217,5 MB		
    Reeder	        207,2 MB     28,5 MB 
    apsd	         65,7 MB     11	MB    
    Safari	         55,3 MB     12,6 MB	

See eg https://launchpad.net/openstack, https://launchpad.net/inkscape, https://launchpad.net/shutter etc

The OP is complaining about excessive write traffic, which wastes power, steals disk-time from other applications, and may wear out SSDs prematurely.

A large profile file does not imply excessive write traffic, so it's not clear from your report that Chrome is hitting the same problem at all. Definitely worth watching, but big-file != excessive-writes.

There's an edit at the end of the article:

> Currently in the middle of a Chrome Version 52.0.2743.116 m test. We have been able to see a pace of over 24GB/ day of writes on this machine...

24GB is higher than the 10-12 he was complaining about from Firefox, even.

    services.psd.enable = true;
    services.psd.users = ["your-user-name"];

[1] https://github.com/graysky2/profile-sync-daemon

overlaid 2.0G 128M 1.9G 7% /run/user/1000/codemac-firefox-3ckuo4v7.default

The reality is that even with fairly heavy use, most of them will far outlive the computers they're in. And their owners for that matter!

I purchased my current SSD in March 2015 - it's a Samsung 850 EVO 512GB. It's done 7332 Power_On_Hours, and 36486573259 Total_LBAs_Written, which works out as just under 17 TB written, or about 31.6 GB/day.

That kind of sounds like a lot. But let's put it in context. Even the previous generation of TLC NAND SSDs were recorded in endurance tests doing around 1 PETABYTE of writes before failing. The 850 EVO, with it's 3D V-NAND, should be capable of at least double that.

For arguments sake, lets assume it will last for 1 Petabyte. I've written 17TB in 1.5 years, or 11.3TB per year. At that rate, this drive is still going to last at least another 90 YEARS.

So is this really something to obsess over?

I'm not sure what the lifetime of a computer is. In my family, we are still occasionally running machines from circa 1995. They work fine. When should I stop using my MacBook? The only reason I'd stop is if it died in a way that can't be cheaply fixed.

Pretty sure it's not 21 years, c'mon...

Most of the SSD failed before a petabyte... and started encountering lots of errors before that (forget about the Samsung Pro series which is the only one that survived till its multi-petabyte end).

If a 250GB 840 EVO can get to 800TB without errors, then I'd expect a 500GB 850 EVO to reach 1 PB, easily.

A 500GB 850 EVO has newer-generation, more durable NAND endurance and twice the capacity to work with.

If you keep with 17 TB per one and half year your SSD should be OK for your for at least next 11 years.

Yes, but endurance tests almost invariably show that the warranty ratings are extremely conservative. The 1TB 850 PRO (which uses exactly the same NAND chips as the 850 EVO, just a different controller) has been endurance tested to more than 7 Petabytes. See: http://packet.company/blog/

The older generations typically had better endurance, the newer generations are more dense (cheaper to produce) but less durable.

That was true when comparing MLC flash to TLC. But the 850 EVO and PRO use 3D V-NAND, which has significantly more endurance than previous-generation TLC. This seems to be confirmed by endurance tests.

your SSD should be OK for your for at least next 11 years

The warranty runs out after 5 years, anyway. But that does not mean it will suddenly stop working on that date!

In all likelihood the drive will never get anywhere near any of these values - it'll be replaced with newer, better tech at some point. It may then get used for a backups or secondary storage, but in those scenarios the daily writes will drop enormously.

It's not "much" higher, actually, 3D MLC as implemented by Samsung is just "up to twice" better than the planar MLC given the same die area and capacity:

http://www.samsung.com/semiconductor/minisite/ssd/v-nand/tec...

"Samsung V-NAND provides up to twice the endurance of planar NAND."

But if the size of the cell drops, the number of P/E cycles drops. Samsung's endurance declarations are real and to be believed, they initially used bigger cells than some of their other chips (or competitors), but Samsung engineers know what they do, that "some tests" achieved "much more" can be either an accident or due to the errors in the test methodology (and I very much suspect the later, because it also allows the accidents to be taken as the "success"). At the time these SSDs appeared, Samsung declared twice less TBW than they do now, so now the declared endurance is surely not too pessimistic, but based on the real knowledge of what's inside.

However I also only close my browser once every couple of weeks as well. System updates etc.

But for 99% of the users, they want it.

Heck, anecdote for anecdote: the very first thing i do on new machines is to open up firefox, go to settings, set the browser to startup with my previous session's tabs.

    rsync [...] /dev/shm/.browser ~/.browser

    rsync [...] /dev/shm/.browser ~/.browser.new && ln -sf ~/.browser.new ~/browser

    PREVIOUS_BACKUP=$(cat ./prev_backup)
    NEW_BACKUP=$(date +%F_%T)

    rsync --link-dest=$PREVIOUS_BACKUP /path/source /path/dest/$NEW_BACKUP

    echo $NEW_BACKUP > ./prev_backup

And that's it.

Since it's the name is a time stamp. When you need to restore, just read ./prev_backup or just list the directory content, sort it and read the last entry.

I guess doing something like this on Windows is too much to hope for, but does anyone know how to do this sort of thing on the Mac?