Just as there was a world before the influence of the iMac’s design, and a world before everywhere you looked you could see people wearing the distinctive white iPod headphones, so too there is a world before the iPhone, and it ends today.
(Hmmm… Just watched a Doctor Who episode much like that 🙂
One of my workmates’ laptops started freaking out today, apparently hosing her iPod (ie no more songs). I suggested trying iPodRip, which managed to recover all her tracks. Failing that the next option I was going to suggest was PodSalvage.
After a recent transfer of our server, ownership (and thus access) of newly created files was being assigned to the creator. Old files could still be accessed by members of the group. It seems the solution to this was to use Workgroup Administrator to change the AFP sharepoint so that it used “Inherit permissions from parent” rather than the “Standard POSIX behaviour” (which in standard UNIX style is probably more secure but less useful 🙂
Fortunately this seemed to work so I didn’t have to enable and implement appropriate ACL’s 🙂
CPU load for scrubbing the filesystem isn’t going to appeal to users who already complain about Spotlight indexing
It chews up much more disk space.
FATZAP object headers chew up 128K each. Theres one of these for every chunk of metadata that doesn’t fit in a microzap block. Think resource forks, even if they’re empty. With 600,000 files or so it’s likely to chew up around 15Gb of space.
Metadata attributes can only have up to 50 character names
It’s case sensitive
You currently can’t remove drives from a ZFS storage pool
ZFS filenames are 255 bytes. HFS Plus supports up to 255 UTF-16 characters
Of course if you happen to have a server with tons of storage, it might be appropriate as it does some very cool things such as guaranteeing data integrity, snapshots (which chew up disk space as they preserve all the blocks from the time the snapshot is taken).
Meanwhile Apple has now stated that ZFS will only be available as a read-only option from the commandline.