Fixing Extremely Slow rsync on OS X

Last night I moved out my photo collection from my MacBook Pro’s internal SSD to a neat little Samsung T1 USB3 SSD. And since Time Machine still can’t handle backing up external drives correctly (it removes the external drive’s contents from the backup when it is not connected), I created a small script to do the backup using the good old rsync.

Backup of the T1 goes to a dedicated AFP share on my FreeBSD server (shared using Netatalk). An Elgato Thunderbolt 2 Dock provides gigabit Ethernet connectivity for the MacBook Pro. I usually see file transfer rates in the 60MB/s – 110 MB/s range from this setup. So the 3MB/s average what rsync produced here was a bit shocking.

And the transfer rate jumped up to the usual range when I downloaded something from the Internet! And went down to 3 megs when the download finished…

It seems that the nine year old version of rsync included in OS X Yosemite can’t handle the OS’s network power management features correctly. When another app wakes up the net to full speed, it works fine, but rsync alone can’t do that.

The solution is embarrassingly simple: install rsync from the ports collection. Did that, updated my script, and presto, I suddenly get transfer speeds in the 50MB/s – 80MB/s range…

  ☕ ☕ ☕

Did this post help you? Consider buying me a coffee if so.

Keeping OS X Display Brightness Unchanged

In the previous installment in my monitor calibration series, I mentioned the need to keep monitor brightness unchanged after calibration – as any change to it invalidates the profile.

But what if I press the brightness control buttons on the Retina MacBook Pro (or on any other MacBook)? Should I immediately re-calibrate and re-profile? Well, there’s a slick trick.

MacBookBrightnessControl2MacBook display brightness is changed by default in whole unit steps using the brightness keys. But holding down Shift + Option while pressing the keys will change it to 1/4 unit steps – the same amount ColorEyes Display Pro (and other software) uses when controlling the display.

What I usually do after calibration and profiling is: increase the brightness by 1/4 unit, take note of the (previous) value, and immediately decrease it back to where the software set it. This way I could return the display to the calibrated state even if I had to change, or accidentally changed its brightness.

Another enemy of keeping the calibration intact is the display dimming preference of OS X – which tells the machine to slightly dim the display while running off of batteries. It might be useful for users not requiring color accuracy and consistency, but turn it off for calibrated displays (by default it’s on).

DisplayDimming2

In the next installment I’ll examine the differences between hardware and software calibration.

hdiutil Requires sudo for Read/Write

Another unwelcome surprise from Apple: in some recent OS X update (I don’t know exactly which one as I ran into the problem this morning) they changed how hdiutil behaves when mounting sparsebundles in read/write mode (it is used in my build scripts as a step toward generating the final setup DMG): it now requires sudo-ing when you use the -readwrite flag.

The problem is that sudo by default prompts for a password and silently fails when used from a script. The solution is to remove that password requirement. This is carried out by adding a line to the /etc/sudoers file:

%admin ALL=(ALL) NOPASSWD: /usr/bin/hdiutil

This innocent one-line edit requires lots of command-line gymnastics, however. Permissions on the sudoers file is 440 by default, and the sudo command fails to work with anything other that that.

So you have to boot your Mac in single user mode to do the edit (by holding down Command+S at startup). Then you have to mount the root file system in read-write mode and change the permissions on the file:

mount -o update /
cd /etc
chmod 640 sudoers
vim sudoers

Add the line to the end of the file, save it and restore the file’s permissions:

chmod 440 sudoers

You can now reboot, and sudo hdiutil will not ask for a password any more! So it can be safely used from within build scripts.

  ☕ ☕ ☕

Did this post help you? Consider buying me a coffee if so.

Hibernate File Issue with MacBook 2012 Update

Seems that the list of annoyances I have to deal with after each and every OS X update just grown a bit. Besides the usual

chflags nohidden ~/Library

command that unhides the Library folder, now I have to do some extra work to reclaim the space normally occupied by the hibernate file (/var/vm/sleepimage). I do not use hibernation on my notebooks. I shut them down when I finished. I prefer to start with clean state on every boot, but equally I’m not fond of wasting 17 gigabytes of expensive SSD space on a file that I never use.

In the past you could turn off hibernation with

sudo pmset -a hibernatemode 0
sudo rm /var/vm/sleepimage

But after today’s release of “Update 2.0 for all Mac notebooks introduced in June 2012”, I had to do some extra work. The issue is: regardless of the state of the hibernatemode switch, the hibernate file (stored in /var/vm/sleepimage) is recreated on every boot. Bummer.

Fortunately you can also set the location of the file, so all I had to do is to send it into a black hole:

sudo pmset -a hibernatefile /dev/null

Everything works fine with this setup, but I fear that the next update could bring some more surprises…

Backing up Lightroom with ChronoSync

ChornoSync is what I use on my Mac for backing up user data – including my images. Although I don’t use Lightroom nowadays as much as I used to, backing up the database is important. There’s one gotcha, however. Preview images are stored in something called a bundle. A bundle is a directory that OS X handles as a single entity. For the catalog named Something.lrcat the preview bundle is named Something Previews.lrdata. So if one single preview image is changed, OS X thinks that the bundle is changed and ChronoSync happily copies the entire multi-hundred-megabyte conglomerate, not just the changed (or new) previews.

There’s a simple solution to this issue, shown on the image below.

Check the Dissect packages checkbox on the Options tab, and the Previews bundle will be treated as a regular directory, and ChronoSync will just synchronize newly added or changed previews.

  ☕ ☕ ☕

Did this post help you? Consider buying me a coffee if so.

Solved: C1 Crashes with Images on an AFP Share

I originally posted the following on the Phase One forums.

I almost pulled all my hair because of this issue, so I thought the solution could be helpful for others (especially FreeNAS users).

The problem:

I recently moved to storing all my RAW files on a central server in the studio to be able to access them from my Macs as well as a Windows notebook (which I use on the field during trips). The server is a beefy machine, with dual gigabit Ethernet connections and an 8 disk super fast ZFS array. It runs FreeBSD 9.0 with Netatalk 2.2.1 for file sharing towards Mac clients and Samba 3.6.3 for Windows file sharing. It could serve files faster than the local SSD disk in my Mac… Basically this is the same software stack you get when you use FreeNAS.

From Windows 7 running the 64-bit version of C1 everything was fine, but when I worked on my files from a Mac then C1 crashed every 5-15 minutes bringing down even the Mac (I had to pull the plug several times because even shutdown didn’t work). Frankly I was unable to work at all with C1 from Macs (running OS X 10.7.3).

The server’s log was full with the following error message:

afpd[6065]: sys_getextattr_size: error: Result too large

The solution:

After hours of debugging the solution is really simple: you have to add the “ea:ad” parameter to the shared volume’s config line in AppleVolumes.default.
The line for my Photos share is the following:

/tank/Photos ea:ad options:upriv dperm:0700 fperm:0600

No more error messages, and C1 6.3.5 shines! I’m a happy user now :D