<?xml version="1.0" encoding="utf-8"?><rss version="2.0"
	xmlns:content="http://purl.org/rss/1.0/modules/content/"
	xmlns:dc="http://purl.org/dc/elements/1.1/"
	xmlns:atom="http://www.w3.org/2005/Atom"
	>
<channel>
	<title>Comments on: Why ZFS Matters to Mac Users</title>
	<atom:link href="http://mtrr.org/blog/?feed=rss2&#038;p=83" rel="self" type="application/rss+xml" />
	<link>http://mtrr.org/blog/?p=83</link>
	<description>Notes on physics, computers, and physics with computers.</description>
	<pubDate>Mon, 06 Sep 2010 01:03:31 +0000</pubDate>
	<generator>http://wordpress.org/?v=2.5.1</generator>
		<item>
		<title>By: stan</title>
		<link>http://mtrr.org/blog/?p=83#comment-3030</link>
		<dc:creator>stan</dc:creator>
		<pubDate>Sat, 23 Dec 2006 15:32:21 +0000</pubDate>
		<guid isPermaLink="false">http://mtrr.org/blog/?p=83#comment-3030</guid>
		<description>I will admit that my interest in ZFS compression is higher than perhaps warranted due to recent experiences.  We have a large number of data files which easily compress (3x) that are individually rarely used, but need to be available to our analysis programs.  Squashfs over loopback was the only option available to me, and it was pretty awkward, and essentially read-only.  

I also tend to carry around lots of reference files on my laptop where compression would be handy, rather than having to zip and unzip things constantly.</description>
		<content:encoded><![CDATA[<p>I will admit that my interest in ZFS compression is higher than perhaps warranted due to recent experiences.  We have a large number of data files which easily compress (3x) that are individually rarely used, but need to be available to our analysis programs.  Squashfs over loopback was the only option available to me, and it was pretty awkward, and essentially read-only.  </p>
<p>I also tend to carry around lots of reference files on my laptop where compression would be handy, rather than having to zip and unzip things constantly.</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: Ford Prefect</title>
		<link>http://mtrr.org/blog/?p=83#comment-3028</link>
		<dc:creator>Ford Prefect</dc:creator>
		<pubDate>Sat, 23 Dec 2006 13:06:08 +0000</pubDate>
		<guid isPermaLink="false">http://mtrr.org/blog/?p=83#comment-3028</guid>
		<description>You should have left out the paragraph about how long it takes to rebuild a failed disk in RAID 5/Z mode. First, it is very assumptive. Next, there couldn't be anything less concerning. From my own experience with failing disks in a Linux Software RAID 5, it takes about 45 minutes to rebuild a 240 GB array (ie, disk capacity 120 GB). While it is at work, you can do everything with the system, like watching a movie or just have it running in a productive state. Who cares if it runs 30 or 60 minutes?

Anyway, it's a nice summary about ZFS' features from the end user's point of view!</description>
		<content:encoded><![CDATA[<p>You should have left out the paragraph about how long it takes to rebuild a failed disk in RAID 5/Z mode. First, it is very assumptive. Next, there couldn&#8217;t be anything less concerning. From my own experience with failing disks in a Linux Software RAID 5, it takes about 45 minutes to rebuild a 240 GB array (ie, disk capacity 120 GB). While it is at work, you can do everything with the system, like watching a movie or just have it running in a productive state. Who cares if it runs 30 or 60 minutes?</p>
<p>Anyway, it&#8217;s a nice summary about ZFS&#8217; features from the end user&#8217;s point of view!</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: Matt Povey</title>
		<link>http://mtrr.org/blog/?p=83#comment-3027</link>
		<dc:creator>Matt Povey</dc:creator>
		<pubDate>Sat, 23 Dec 2006 10:54:45 +0000</pubDate>
		<guid isPermaLink="false">http://mtrr.org/blog/?p=83#comment-3027</guid>
		<description>Just a quick point regarding compression. NTFS has had similar (though not as flexible) support for FS level compression since its inception. You generally find however that very few people actually use it. 

There are many good reasons for this but here are the biggies:

1) The majority of space consuming formats are already compressed (MPEG etc.). These are Macs we're talking about remember.
2) Many of those formats in turn require relatively high performance (50Mbps for SD video editing - 25Mbps for DV - far more for HD). Compression can compromise that performance
3) Hard drive capacities have grown so fast as to render compression pointless
4) It's a serious nightmare for admins who have to try to track both the compressed and putative uncompressed quantities of data that they store in order to plan storage requirements going forward
5) Adding to admins woes is the loss of compression on their backup tapes (working in a media environment, I turn tape compression off anyway as it can actually increase the size of stored data!)
6) ZFS compression would be great for USB sticks etc. Except that noone puts NTFS on USB sticks and neither will they put ZFS on them unles they're only going to share with Mac\Solaris users.

File system compression sounds nice but in practice it's window dressing. ZFS is a massive step forward for MacOS but compression is just frippery.</description>
		<content:encoded><![CDATA[<p>Just a quick point regarding compression. NTFS has had similar (though not as flexible) support for FS level compression since its inception. You generally find however that very few people actually use it. </p>
<p>There are many good reasons for this but here are the biggies:</p>
<p>1) The majority of space consuming formats are already compressed (MPEG etc.). These are Macs we&#8217;re talking about remember.<br />
2) Many of those formats in turn require relatively high performance (50Mbps for SD video editing - 25Mbps for DV - far more for HD). Compression can compromise that performance<br />
3) Hard drive capacities have grown so fast as to render compression pointless<br />
4) It&#8217;s a serious nightmare for admins who have to try to track both the compressed and putative uncompressed quantities of data that they store in order to plan storage requirements going forward<br />
5) Adding to admins woes is the loss of compression on their backup tapes (working in a media environment, I turn tape compression off anyway as it can actually increase the size of stored data!)<br />
6) ZFS compression would be great for USB sticks etc. Except that noone puts NTFS on USB sticks and neither will they put ZFS on them unles they&#8217;re only going to share with Mac\Solaris users.</p>
<p>File system compression sounds nice but in practice it&#8217;s window dressing. ZFS is a massive step forward for MacOS but compression is just frippery.</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: Hakime</title>
		<link>http://mtrr.org/blog/?p=83#comment-3025</link>
		<dc:creator>Hakime</dc:creator>
		<pubDate>Sat, 23 Dec 2006 00:15:07 +0000</pubDate>
		<guid isPermaLink="false">http://mtrr.org/blog/?p=83#comment-3025</guid>
		<description>ZFS is already largely implemented in Leopard. And to answer to your question, yes,  the commands zpool and zfs already works. Actually pratically everything works at the command line level. Look here for a demo:

http://themachackers.com/2006/12/19/zfs-on-mac-os-x-105-a-closer-look/</description>
		<content:encoded><![CDATA[<p>ZFS is already largely implemented in Leopard. And to answer to your question, yes,  the commands zpool and zfs already works. Actually pratically everything works at the command line level. Look here for a demo:</p>
<p><a href="http://themachackers.com/2006/12/19/zfs-on-mac-os-x-105-a-closer-look/" rel="nofollow">http://themachackers.com/2006/12/19/zfs-on-mac-os-x-105-a-closer-look/</a></p>
]]></content:encoded>
	</item>
	<item>
		<title>By: saha</title>
		<link>http://mtrr.org/blog/?p=83#comment-3024</link>
		<dc:creator>saha</dc:creator>
		<pubDate>Fri, 22 Dec 2006 18:46:17 +0000</pubDate>
		<guid isPermaLink="false">http://mtrr.org/blog/?p=83#comment-3024</guid>
		<description>I wish Apple updated the filesystem for Mac OSX. I know that HFS + with journaling and meta-data searching were added later to keep up with necessary features of a modern filesystem, but I feel HFS + is showing signs of age. I was hoping when Apple first developed Mac OSX it had used the UFS system and then made a separate HFS+ partition for people who wanted to use a Mac OS9 on the PowerPC based Macs, but that didn't happen. Perhaps for the best at the time. Wilfredo Sánchez Vega wrote a whitepaper on the reasoning for HFS + at the time.

http://www.wsanchez.net/papers/USENIX_2000/

So now with the Intel Macs and no need for Mac OS 9 support, Apple could have told all their developers that all Universal apps must be able to run on UFS or case sensitive HFS+. That way should Apple decide to adopt ZFS it should be a painless transition. Holding on to HFS + with the Intel Macs for this long will hamper any transition into a future filesystem (incompatibilities dragging legacy habits of HFS+). This will prepare Adobe and Microsoft to write their new Universal versions to be able to accept any type of filesystem and not rely on the resource fork of HFS

That's my 2 cents.</description>
		<content:encoded><![CDATA[<p>I wish Apple updated the filesystem for Mac OSX. I know that HFS + with journaling and meta-data searching were added later to keep up with necessary features of a modern filesystem, but I feel HFS + is showing signs of age. I was hoping when Apple first developed Mac OSX it had used the UFS system and then made a separate HFS+ partition for people who wanted to use a Mac OS9 on the PowerPC based Macs, but that didn&#8217;t happen. Perhaps for the best at the time. Wilfredo Sánchez Vega wrote a whitepaper on the reasoning for HFS + at the time.</p>
<p><a href="http://www.wsanchez.net/papers/USENIX_2000/" rel="nofollow">http://www.wsanchez.net/papers/USENIX_2000/</a></p>
<p>So now with the Intel Macs and no need for Mac OS 9 support, Apple could have told all their developers that all Universal apps must be able to run on UFS or case sensitive HFS+. That way should Apple decide to adopt ZFS it should be a painless transition. Holding on to HFS + with the Intel Macs for this long will hamper any transition into a future filesystem (incompatibilities dragging legacy habits of HFS+). This will prepare Adobe and Microsoft to write their new Universal versions to be able to accept any type of filesystem and not rely on the resource fork of HFS</p>
<p>That&#8217;s my 2 cents.</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: Brian</title>
		<link>http://mtrr.org/blog/?p=83#comment-3023</link>
		<dc:creator>Brian</dc:creator>
		<pubDate>Fri, 22 Dec 2006 18:38:04 +0000</pubDate>
		<guid isPermaLink="false">http://mtrr.org/blog/?p=83#comment-3023</guid>
		<description>I think some of the folks here are missing the point of the "grow your filesystem" feature. ZFS really throws some of the assumptions that we make about how filesystems work out the window.

For example, home directories or even application folders can be treated as separate volumes. So if you want to compress &#38; encrypt all user data or write protect specific applications, you can do that without clumsy bolt-ons like FileVault.

Also consider the possibilities for backup... since ZFS natively supports replication &#38; snapshots, the OS could automatically sync your volumes with things like firewire disks, other computers or even handheld devices (sync your home folder with your laptop or PDA) or even an online solution like .Mac.</description>
		<content:encoded><![CDATA[<p>I think some of the folks here are missing the point of the &#8220;grow your filesystem&#8221; feature. ZFS really throws some of the assumptions that we make about how filesystems work out the window.</p>
<p>For example, home directories or even application folders can be treated as separate volumes. So if you want to compress &amp; encrypt all user data or write protect specific applications, you can do that without clumsy bolt-ons like FileVault.</p>
<p>Also consider the possibilities for backup&#8230; since ZFS natively supports replication &amp; snapshots, the OS could automatically sync your volumes with things like firewire disks, other computers or even handheld devices (sync your home folder with your laptop or PDA) or even an online solution like .Mac.</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: huevo87</title>
		<link>http://mtrr.org/blog/?p=83#comment-3022</link>
		<dc:creator>huevo87</dc:creator>
		<pubDate>Fri, 22 Dec 2006 18:28:56 +0000</pubDate>
		<guid isPermaLink="false">http://mtrr.org/blog/?p=83#comment-3022</guid>
		<description>Actually ZFS is not necessarily FASTER at restoring a disk in your pool if one fails and you swap it in for a new one. In the new one it will have to recompute all the parity of the missing information from the remaining disks. The problem arises when the disks were very full. The way ZFS stores data, using a shadow page tree, means that it will have to traverse the shadow page tree in it's entirity, meaning that it will usually take longer than a RAID 4, for example. However, if the disks are only half full, then ZFS will be faster, because it will not recompute unnecessary parity blocks.</description>
		<content:encoded><![CDATA[<p>Actually ZFS is not necessarily FASTER at restoring a disk in your pool if one fails and you swap it in for a new one. In the new one it will have to recompute all the parity of the missing information from the remaining disks. The problem arises when the disks were very full. The way ZFS stores data, using a shadow page tree, means that it will have to traverse the shadow page tree in it&#8217;s entirity, meaning that it will usually take longer than a RAID 4, for example. However, if the disks are only half full, then ZFS will be faster, because it will not recompute unnecessary parity blocks.</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: stan</title>
		<link>http://mtrr.org/blog/?p=83#comment-3021</link>
		<dc:creator>stan</dc:creator>
		<pubDate>Fri, 22 Dec 2006 17:23:23 +0000</pubDate>
		<guid isPermaLink="false">http://mtrr.org/blog/?p=83#comment-3021</guid>
		<description>The disadvantage to bolting on snapshots to HFS+ is that it likely is not as fast or as space-efficient as ZFS, which limits how much you can use it.  

Judgement on the matter will have to wait until we learn more about how Time Machine is implemented, though.</description>
		<content:encoded><![CDATA[<p>The disadvantage to bolting on snapshots to HFS+ is that it likely is not as fast or as space-efficient as ZFS, which limits how much you can use it.  </p>
<p>Judgement on the matter will have to wait until we learn more about how Time Machine is implemented, though.</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: Denver Computer Consulting</title>
		<link>http://mtrr.org/blog/?p=83#comment-3020</link>
		<dc:creator>Denver Computer Consulting</dc:creator>
		<pubDate>Fri, 22 Dec 2006 17:21:30 +0000</pubDate>
		<guid isPermaLink="false">http://mtrr.org/blog/?p=83#comment-3020</guid>
		<description>Thanks for posting such an interesting article about ZFS. I don't think a lot of Mac users realize the power they have right under their noses.</description>
		<content:encoded><![CDATA[<p>Thanks for posting such an interesting article about ZFS. I don&#8217;t think a lot of Mac users realize the power they have right under their noses.</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: C. Shamis</title>
		<link>http://mtrr.org/blog/?p=83#comment-3019</link>
		<dc:creator>C. Shamis</dc:creator>
		<pubDate>Fri, 22 Dec 2006 17:06:28 +0000</pubDate>
		<guid isPermaLink="false">http://mtrr.org/blog/?p=83#comment-3019</guid>
		<description>&#62;People with iBooks, MacBooks, Powerbooks, Mac Minis, and iMacs all have generally the same storage setup: a single hard disk with capacity ranging from 40-500 GB. A lot of the magic of ZFS does not become manifest until you have several disks, ...
 
This is true, and it's good you mention it up front; because I don't think the "single hard disk" model is likely to change in the immediate future.  In two or three years from now it may be the norm to have multiple HD's in your laptop...  but two to three years from now, ZFS will be in place... So what's the hurry?

&#62;Apple’s much discussed Time Machine feature in OS X 10.5 is a great example of the interface possibilies when you have snapshots available. However, Time Machine does not appear to require ZFS, which means that Apple had to bolt snapshots onto HFS+, a complex and awkward task.
 
Not really for somebody who understands the technology of file systems, and modern data-storage techniques.  It's really not any harder than "bolting-on" file-level encryption or compression.  --Furthermore, it's already been done, so why do I care how difficult it was?  I don't have to know HOW something was done in order to use it... (Isn't that the whole point of owning a Mac in the first place?)  :)
 

&#62;Automatically growing filesystems. Once you add your disks to the storage pool, all of their space is available 
 
Okay, this is REALLY COOL!  No doubt about it.  However, adding additional drives isn't exactly an everyday occurrence.  Sure, it *WILL* be nice one day, when... adding a hard-drive is like adding memory, you simply stick it in, and turn it on and the computer uses it... That will be *WAY* cool... but... It just isn't something that happens that often...  Besides, the complexity of adding storage to an existing file system can usually be mitigated by "nesting" the file system anyway.  --Just move the files around and change the mount point.  The OS doesn't care if the "Whatever" directory is on hard drive X or hard drive Y.
 
Oh sure... we humans may "care" which drive certain data is on, (Databases on one drive, Multimedia on another, etc...) but with ZFS you'll have to cede that control anyway.  This new "grow the file system" feature of ZFS isn't going to let you decide what drive you put stuff... When you add a drive, ZFS will decide how to break out the data.  (Just like the RAM in your computer, you don't get to decide what programs run on which memory stick; well it will be the same thing with your hard-drive...)  --I'm just saying... be prepared for that...</description>
		<content:encoded><![CDATA[<p>&gt;People with iBooks, MacBooks, Powerbooks, Mac Minis, and iMacs all have generally the same storage setup: a single hard disk with capacity ranging from 40-500 GB. A lot of the magic of ZFS does not become manifest until you have several disks, &#8230;</p>
<p>This is true, and it&#8217;s good you mention it up front; because I don&#8217;t think the &#8220;single hard disk&#8221; model is likely to change in the immediate future.  In two or three years from now it may be the norm to have multiple HD&#8217;s in your laptop&#8230;  but two to three years from now, ZFS will be in place&#8230; So what&#8217;s the hurry?</p>
<p>&gt;Apple’s much discussed Time Machine feature in OS X 10.5 is a great example of the interface possibilies when you have snapshots available. However, Time Machine does not appear to require ZFS, which means that Apple had to bolt snapshots onto HFS+, a complex and awkward task.</p>
<p>Not really for somebody who understands the technology of file systems, and modern data-storage techniques.  It&#8217;s really not any harder than &#8220;bolting-on&#8221; file-level encryption or compression.  &#8211;Furthermore, it&#8217;s already been done, so why do I care how difficult it was?  I don&#8217;t have to know HOW something was done in order to use it&#8230; (Isn&#8217;t that the whole point of owning a Mac in the first place?)  <img src='http://mtrr.org/blog/wp-includes/images/smilies/icon_smile.gif' alt=':)' class='wp-smiley' /> </p>
<p>&gt;Automatically growing filesystems. Once you add your disks to the storage pool, all of their space is available </p>
<p>Okay, this is REALLY COOL!  No doubt about it.  However, adding additional drives isn&#8217;t exactly an everyday occurrence.  Sure, it *WILL* be nice one day, when&#8230; adding a hard-drive is like adding memory, you simply stick it in, and turn it on and the computer uses it&#8230; That will be *WAY* cool&#8230; but&#8230; It just isn&#8217;t something that happens that often&#8230;  Besides, the complexity of adding storage to an existing file system can usually be mitigated by &#8220;nesting&#8221; the file system anyway.  &#8211;Just move the files around and change the mount point.  The OS doesn&#8217;t care if the &#8220;Whatever&#8221; directory is on hard drive X or hard drive Y.</p>
<p>Oh sure&#8230; we humans may &#8220;care&#8221; which drive certain data is on, (Databases on one drive, Multimedia on another, etc&#8230;) but with ZFS you&#8217;ll have to cede that control anyway.  This new &#8220;grow the file system&#8221; feature of ZFS isn&#8217;t going to let you decide what drive you put stuff&#8230; When you add a drive, ZFS will decide how to break out the data.  (Just like the RAM in your computer, you don&#8217;t get to decide what programs run on which memory stick; well it will be the same thing with your hard-drive&#8230;)  &#8211;I&#8217;m just saying&#8230; be prepared for that&#8230;</p>
]]></content:encoded>
	</item>
</channel>
</rss>
