Enable time machine backup to network drive (DNS 323)

July 19, 2010 6 comments

First, enable Time Machine to use network drives:

defaults write com.apple.systempreferences TMShowUnsupportedNetworkVolumes 1

Follow instructions here:
http://www.horto.ca/?p=12

I created a “sparse bundle disk image” which I saved as chimera.sparsebundle with the following options:

Volume Name: “Time Machine Backups”
Filesystem: MAC OS Extended  (Case Sensitive Journaled).
Encryption : None
Partition : Single Partition GUID
Initial Size: 1 GB.
Later I resized it to my final backup disk size : 500 GB

However, for Snow Leopard, following changes apply:

(a) Name of the sparsebundle is <computer_name>.sparsebundle. eg.

[anirbans@chimera:/Users/anirbans]$ hostname
chimera

so the file name should be chimera.sparsebundle

(b) The sparse bundle image must contain a plist file: com.apple.TimeMachine.MachineID.plist

DO NOT mount the image to create the file. If your sparsebundle file is in /Volume /Backups then,

#> cd /Volumes/Backups/chimera.sparsebundle
#> vi com.apple.TimeMachine.MachineID.plist

Or

Right click the sparsebundle image and select “Show Package Contents”. In the finder window that opens, create the file using any text editor.

Contents of the file should be something like this:

<?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>VerificationDate</key>
<date>;2010-07-18T00:33:28Z</date>
<key>VerificationExtendedSkip</key>
<false/>
<key>VerificationState</key>
<integer>1</integer>
<key>com.apple.backupd.BackupMachineAddress</key>
<string>XX:XX:XX:XX:XX:XX</string>
<key>com.apple.backupd.HostUUID</key>
<string>XXXXXXXX-XXXX-XXXX-XXXX-XXXXXXXXXXXX</string>
</dict>
</plist>

Get the UUID from apple menu -> About this Mac -> More Info . In the hardware tab, see Hardware UUID on the bottom right pane.
The Machine Address is the MAC address of “en0” interface.

For Snow Leopard 10.6.3 and 10.6.4 (as of this writing, 10.6.4 is the latest version of Mac OS X Snow Leopard), Apple changed the way Time Machine treats the sparse bundle files for backups. It automatically resizes the file to occupy the entire space in the hard drive partition. If you do a grep over /var/log/system.log, you’d see the following lines:

Resizing backup disk image from 476.8 GB to 1831.7 GB

As of writing this blog, there has been numerous discussions and feature enhancement posted by various people to have an option to either limit the amount of space Time Machine can use for backups or have an option to disable Time Machine from resizing the sparse image file. No “official” resolution exists as of writing.

See :

http://discussions.apple.com/thread.jspa?threadID=2383738&start=30&tstart=120
http://discussions.apple.com/thread.jspa?threadID=2510587&tstart=0

You might think that you can hack around this problem by revoking write permissions on Info.plist file present inside the sparsebundle disk image:


# chmod a-w Info.plist
# ls -l
-rwxrwxrwx    1 anirbans anihome       499 Jul 18 13:02 Info.bckup
-r-xr-xr-x    1 anirbans anihome       499 Jul 18 13:02 Info.plist
drwxrwxrwx    2 anirbans anihome      4096 Jul 18 13:03 bands
-rwxrwxrwx    1 anirbans anihome       532 Jul 18 12:02 com.apple.TimeMachine.MachineID.plist
-rwxrwxrwx    1 anirbans anihome         0 Jul 18 13:00 token

However, you need to change the ownership of the file to some user other than the one Time Machine uses to log in to your NAS. Otherwise, Time Machine intelligently reinstates the write permissions for the file.

In my case, Time Machine uses the user name anirbans to log in. Hence, I changed the ownership of the file to root and revoked write permissions for all others.


# chown root Info.plist
# chgrp root Info.plist
# chmod o-w Info.plist
# ls -l
-rwxrwxrwx 1 anirbans anihome 499 Jul 18 13:02 Info.bckup
-rwxrwxr-x 1 root root 499 Jul 18 13:02 Info.plist
drwxrwxrwx 3 anirbans anihome 4096 Jul 19 18:35 bands
-rwxrwxrwx 1 anirbans anihome 532 Jul 19 18:35 com.apple.TimeMachine.MachineID.plist
-rwxrwxrwx 1 anirbans anihome 0 Jul 18 13:00 token

Check the logs:

Jul 18 20:05:26 chimera com.apple.backupd[2788]: Resizing backup disk image from 476.8 GB to 1831.7 GB
Jul 18 20:05:45 chimera com.apple.backupd[2788]: Could not resize backup disk image (DIHLResizeImage returned 13)
Jul 18 20:05:48 chimera com.apple.backupd[2788]: QUICKCHECK ONLY; FILESYSTEM CLEAN
Jul 18 20:05:50 chimera com.apple.backupd[2788]: Disk image /Volumes/FileServerVolume-1/chimera.sparsebundle mounted at: /Volumes/Time Machine Backups
Jul 18 20:05:50 chimera com.apple.backupd[2788]: Backing up to: /Volumes/Time Machine Backups/Backups.backupdb
Jul 18 20:05:52 chimera com.apple.backupd[2788]: Backup content size: 112.4 GB excluded items size: 7.8 GB for volume My Mac Disk
Jul 18 20:05:52 chimera com.apple.backupd[2788]: No pre-backup thinning needed: 125.43 GB requested (including padding), 476.10 GB available

As you can see, Time Machine uses just the amount of disk space allocated for the sparse bundle.

Notes:

  1. As a side note, the following does not work:
    defaults write /Library/Preferences/com.apple.TimeMachine MaxSize nnn
  2. Locking the file using something like this:
    SetFile -a L Info.plist
    might work. But somehow it did not work for me and I did not spend any time digging on it.
  3. I did enable AFP (http://en.wikipedia.org/wiki/Apple_Filing_Protocol) in my DNS323, so it backs up over AFP. Instructions on how to enable AFP is here: http://wiki.dns323.info/howto:appletalk
Categories: Miscellaneous

Linux Git repo

July 19, 2010 Leave a comment


#git clone git://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux-2.6.git linux-2.6

Git repository quick howto:

http://landley.net/writing/git-quick.html

http://linux.yyz.us/git-howto.html

Categories: Linux/Linux kernel

Find the offsets of data structures easily

July 19, 2010 Leave a comment

From Kaz Kylheku’s post in LKML:

http://lkml.org/lkml/2009/11/20/449

Categories: Linux/Linux kernel

Dump gcc built-in #defs

July 19, 2010 Leave a comment

This is very useful if you have say two different compilers compiling the same piece of code and you want to execute some special code only for one of the compilers. Do this:

#> gcc -E -dD -
ctrl-D

This will dump all the inbuilt #defs. For example, if gcc was cross compiled for mips target, you’d have something like this somewhere in that dump:

...
# 1 "<built-in>"
#define __mips__ 1
# 1 "<built-in>"
#define _mips 1
# 1 "<built-in>"
#define mips 1
# 1 "<built-in>"
#define __mips64 1
# 1 "<built-in>"
...

and if your compiler was compiled with target intel, you’d see this:


...
# 1 "<built-in>"
#define __i386 1
# 1 "<built-in>"
#define __i386__ 1
# 1 "<built-in>"
#define i386 1
# 1 "<built-in>"
...

So in your code, you can do this:


# ifdef __mips__
/* mips specific code */
#endif

etc.

Cool eh?

Categories: Miscellaneous

signal handlers are executed in the context of their own private stack frame

July 19, 2010 Leave a comment

See arch specific setup_frame() function in the kernel. For mips, it installs the signal trampoline, the user context (the registers) and the siginfo (when appropriate). The trampoline is just a syscall trap to the kernel to call sigreturn(). The address of the trampoline is set in the RA register, the arguments (signr, siginfo and the signal context) in registers 4, 5 and 6 respectively, pc points to the sighandler, reg# 29 (stack ptr) points to the allocated stack frame and off you go! On completion of the handler, the user land code returns to the address pointed to by RA register which has the trampoline. This it traps to the kernel in sysexit() syscall and this syscall then restores the user context through the saved register set, saved earlier in reg# 6.

Categories: Linux/Linux kernel

malloc() does not necessarily unmap free’d pages

July 19, 2010 Leave a comment

Glibc’s malloc uses a combination of brk() and mmap() (where available) system calls depending upon the size of the chunk being allocated and some other factors like holes in the address space. a brk() only increases the data segment of a process in turn increasing the address space of that process. When you free() it, libc only marks this chunk as un-available but it still remains mapped. If malloc() uses mmap(), a free would so a munmap() and then later on accessing a freed memory will result in a seg-fault.

There’s a comment in glibc’s mmap.c that says:

Define HAVE_MMAP as true to optionally make malloc() use mmap() to
allocate very large blocks.  These will be returned to the
operating system immediately after a free(). Also, if mmap
is available, it is used as a backup strategy in cases where
MORECORE fails to provide space from system.

This malloc is best tuned to work with mmap for large requests.
If you do not have mmap, operations involving very large chunks (1MB
or so) may be slower than you'd like.


The default mmap() threshold is 128*1024 bytes (or 128 KB). This value can be changed using mallopt() glibc call:
http://www.gnu.org/s/libc/manual/html_node/Malloc-Tunable-Parameters.html

Enhanced by Zemanta