HFS+ journalized vs. ZFS

Thanks for the link StorageMojo, though it would be nice you took my pape in context, I wasn’t comparing HFS+ to ZFS, but the way typical users store data. And why they would want to use ZFS.

Motive: Why Would Apple Care? Motive has always been the real problem. Even other defenders of ZFS had to stretch for a reason. Journaled HFS+ isn’t perfect, but it is competitive with NTFS and the other common filesystems out there. My original thought was “here is this great free product so why wouldn’t you use it.”

I sat down and started to research HFS+ and a few links in I found

ZFS thread or Menace part I and ZFS threat or Menace part II, both links go back to StorageMojo strange he did a major flip flop, they are chock full of facts as to why ZFS is awesome. How it was tested, what limits it has, (not many), scalability. Sounds like you were pretty sold on the idea of ZFS. Then I get to the end of part II, and see.

Maybe I’m easily impressed, but this seems wicked great.

Sounds like you are wickedly impressed J to me. Okay now lets see what you said about features you want to see.

StorageMojo.com Conclusion Is v.1.0 of ZFS everything we could wish for? No V.1.0 product is, but the Sun engineers are off to a great start. Specifically, some things that I hope to see soon:

• Cluster support so ZFS can be used on a highly available infrastructure
  


• Double parity RAID-Z for the truly paranoid among us
  


• Ported to Linux, FreeBSD, Mac OS X
  

Now that ZFS is shipping and work is proceeding on the features you asked for almost, as if you were reading off their score card.

#1, cluster support is being worked on.
#2. Double parity is complete and in Beta testing Solaris Express now has it.
#3. What did you ask for? Ported to Mac OSX, apple seems to have heard your request, and FreeBSD is well on the way to porting ZFS as well. Linux/FUSE project is working on it too.

Now since you chose to link to my ZFS for home page, you must really think highly of and think wow it could work for home as well.

Okay now lets take a look at what HFS+j has and doesn’t have, when compared to ZFS.

As you have talked about ZFS can take snapshots of entire filesystems. And HFS+ seems to be limited to viewing single files, and it will let your restore them to a previous version. Now if you dismiss this argument, lets see how ZFS takes the next step.

You missed a very important feature ZFS not sure you missed it or understand the power of it. This power will change the way that users who deal with large files like movie editors and artists that work with large files, especially if they are working in a group on the same files.

Lets look at where I’m doing my work.

bash-3.00# zfs list pool
NAME                   USED  AVAIL  REFER  MOUNTPOINT
pool                  1.81G  31.3G  1.63G  /pool

30GB of space.

bash-3.00# zfs create pool/my_movie
bash-3.00# zfs set compression=on pool/my_movie

okay we have a nice filesystem with compression enabled, now lets create a nice large file.

bash-3.00# dd if=/dev/urandom count=12800000 bs=128k of=big_movie_file
0+12800000 records in
0+12800000 records out
bash-3.00# ls -lh big_movie_file
-rw-r--r--   1 root     root         12G Sep 15 21:07 big_movie_file
bash-3.00#

okay a 12GB file makes a good example file, typical of what a uncompressed movie would be. But ours is random data so not very compressible, if this was a real uncomplressed file it would be compressed on the fly.

NAME                   USED  AVAIL  REFER  MOUNTPOINT
pool/my_movie         12.4G  18.9G  12.4G  /pool/my_movie

there is my filesystem, and we have 18.9GB of disk space left, lets take a snapshot. So we can go back to this later if we decide we don’t like our change and we can show our boss what we started with and where we are now.

bash-3.00# zfs snapshot pool/my_movie@first_version

now lets make a change to it, this command creates a 12M file and then puts it into our 12GB file a little bit into it.

bash-3.00# dd if=/dev/urandom count=12800 bs=128k of=change
0+12800 records in
0+12800 records out
bash-3.00# dd if=change oseek=1000 conv=notrunc of=big_movie_file

now as our luck would have it, the boss hires 3 new video editors, buzz, woody, and potato and he wants me to give them each there own copy of the move to work on. A little unix fu, accomplishes the task quite quicky.

#for i in buzz woody potato ; do zfs clone pool/my_movie@first_version pool/movie${i}cut ; done

Now we have our 4 copies of the movie

bash-3.00# zfs list -o name -r pool
NAME
pool/moviebuzzcut
pool/moviepotatocut
pool/moviewoodycut
pool/my_movie
pool/my_movie@first_version

well our new editors have been busy, here we change potatos version, if you are a unix guy may notice that we are changing a section of the file that overlaps what the first guy did, but his version is fully in tact.

bash-3.00# cd /pool/moviepotatocut/
bash-3.00# ls
big_movie_file
bash-3.00# dd if=/pool/my_movie/change oseek=950 conv=notrunc of=big_movie_file
26000+0 records in
26000+0 records out

Woody makes two changes at different places in his copy of the file.

bash-3.00# cd /pool/moviewoodycut/
bash-3.00# dd if=/pool/my_movie/change oseek=650 conv=notrunc of=big_movie_file    26000+0 records in
26000+0 records out
bash-3.00# dd if=/pool/my_movie/change oseek=23000 conv=notrunc of=big_movie_file
26000+0 records in
26000+0 records out

Okay your thinking what is the big deal of all this, well two things, did you notice how much space our filesystem started out holding? 30GB, and our movie started out at 12GB but we now have 4 copies of the movie and a snapshot? So over 48GB files on a 30GB drive, no its not compression. Because we used random data. How much diskspace did our 48GB of non compressible movie use including changes. Just 14.3GB see when you are working on a clone as we did above, we only store the changes.

bash-3.00# zfs list pool
NAME                   USED  AVAIL  REFER  MOUNTPOINT
pool                  14.3G  18.8G  1.63G  /pool
bash-3.00#

The last surprise is that all this was done in just 23 minutes including typing all of this.

total 25995979 -rw-r--r--   1 root     root         12G Sep 15 21:30 big_movie_file

Okay if you aren’t convinced that ZFS is the filesystem you should be waiting to use, one last fact an actual comparison to hfs+, Sun does not ship with a fsck utility and it doesn’t need one. HFS+ on the other hand does, and if you Google, you will find this page OSX FAQ the “How To Run fsck To Examine A Non-boot Volume In Mac OS X.” This says People frequently ask about how to use fsck on HFS+. Hmm what would you trust move a filesystem that doesn’t get corrupted and need to be fsck’d or one that does? And from the man page.

Note the warning in the manpage however:

-r Rebuild the catalog file on the specified file system.

This option currently will only work if there is enough

contiguous space on the specified file system for a new

catalog file and if there is no damage to the leaf nodes in

the existing catalog file.

Seems like the HFS+ journaling, can suffer from corrupt files and meta information. ZFS is not if you use built in raid solution, such as mirroring or raidz.

Seems like ZFS wins to me.