Welcome to the MacNN Forums.

If this is your first visit, be sure to check out the FAQ by clicking the link above. You may have to register before you can post: click the register link above to proceed. To start viewing messages, select the forum that you want to visit from the selection below.

You are here: MacNN Forums > Software - Troubleshooting and Discussion > Mac OS X > The return of ZFS

The return of ZFS
Thread Tools
Mac Elite
Join Date: May 2001
Location: Up north
Status: Offline
Reply With Quote
Jan 11, 2012, 07:04 PM
 
ZFS is back on the Mac. TensComplement is about to release their ZFS filesystem for OS X. They seem to be aiming ZFS at the average consumer.

I'm pretty stoked as I've been using the old zfs-119 beta that Apple put out several years ago on an antiquated G5. I can finally move things over to my Xeon.

Some of the advantages of ZFS include:
  • RAID-Z is similar in practice to RAID-5 but without the write-hole problem (consistent data even after suffering a power-loss, without batteries).
  • Checksums on all data written to the file-system even if the pool is not using a multi-drive setup. If there is redundancy (RAID-Z, mirrored devices, or single devices with write-twice enabled) then bad blocks of data can be healed. If there is no redundancy, at least you know that your data is succumbing to bit-rot, many filesystems are silent about this.
  • Instantaneous copy-on-write snapshots. The overhead is practically non-existant in terms of performance. The metadata for the snapshot is also minimal.
  • Expandable storage pools by way of virtual devices: ZFS filesystems are hosted on a pool, a pool is made up of virtual devices. A virtual device can be a single device, or a collection of devices (such as RAID-Z or mirrored configurations). Virtual devices can be added, on the fly, to a pool, thus expanding its capacity, and the capacity of the filesystems hosted on that pool.
  • Options to enable compression and deduplication.
     
Clinically Insane
Join Date: Jun 2001
Location: planning a comeback !
Status: Offline
Reply With Quote
Jan 11, 2012, 07:45 PM
 
I'm not so optimistic.

Do you trust some small development company with all your data ?

Apple (for whatever reasons) decided against an implementation. 3rd party support . implementation is just not robust enough for me to pull the plunge.

Just think of all the things that can go wrong, from OS X updates to non-existatn tools to fix and repair the filesystem.

-t
     
Eug
Clinically Insane
Join Date: Dec 2000
Location: Caught in a web of deceit.
Status: Offline
Reply With Quote
Jan 11, 2012, 09:21 PM
 
Ditto.

I'm definitely not gonna be a guinea pig here. Maybe if it works well though Apple will buy them out and incorporate it into 10.9.
     
Clinically Insane
Join Date: Mar 2001
Location: yes
Status: Offline
Reply With Quote
Jan 11, 2012, 10:54 PM
 
Besides, compression and dedup are only available in certain versions of ZFS - it all depends on what version this product is implementing.

I wouldn't trust my data with this either, not the way Apple operates. I don't want random OS X updates that include kernel updates to break this, and every implementation of ZFS I've come across has required kernel interaction.
     
Professional Poster
Join Date: Feb 2000
Location: Nashua NH, USA
Status: Offline
Reply With Quote
Jan 11, 2012, 11:06 PM
 
I'd wait for them to publish their source, 'cus theres no way the wrote that from scratch.
     
Clinically Insane
Join Date: Mar 2001
Location: yes
Status: Offline
Reply With Quote
Jan 11, 2012, 11:14 PM
 
Why not? They would just need some kernel extensions to bridge to the user land ZFS stuff, I believe. FreeBSD supports ZFS despite UFS still being used to boot the OS. I'm sure this doesn't allow booting OS X from ZFS, just creation of file systems on top of an HFS+ booted OS
     
Mac Elite
Join Date: May 2001
Location: Up north
Status: Offline
Reply With Quote
Jan 11, 2012, 11:21 PM
 
There was no official reason for why ZFS was abandoned by Apple, but many suspect it was over licensing issues. In any case I don't think anyone would argue that it was for technical reasons.

This version of ZFS supports compression and deduplication.

The guy behind Ten's Complement is Don Brady, a former Apple filesystem and OS engineer. He was previously working on Apple's internal ZFS implementation before it was cancelled. If someone is going to create a 3rd-party FS for Mac OS X, he's the guy to do it.

This is the Ars Technica article that alerted me to the company in the first place. It also talks about Don Brady, the technical details of ZFS, and its history with Apple.
     
Eug
Clinically Insane
Join Date: Dec 2000
Location: Caught in a web of deceit.
Status: Offline
Reply With Quote
Jan 11, 2012, 11:30 PM
 
Originally Posted by 11011001 View Post
There was no official reason for why ZFS was abandoned by Apple, but many suspect it was over licensing issues. In any case I don't think anyone would argue that it was for technical reasons.
We don't know, but why not both licensing and technical reasons?

I don't know enough about the technical side of ZFS to comment. However, even though I know everyone raves about ZFS, I have to wonder if there weren't some OS X idiosyncrasies that made ZFS adoption harder. One comment has been made that ZFS was more focused on the enterprise server space, and that widespread adoption at the single user level for an established OS like OS X was potentially a different kettle of fish.
     
Clinically Insane
Join Date: Mar 2001
Location: yes
Status: Offline
Reply With Quote
Jan 11, 2012, 11:33 PM
 
I don't suspect it was due to licensing issues, that theory has never held up to me. I think it was political/control reasons given the Oracle takeover.
     
Clinically Insane
Join Date: Mar 2001
Location: yes
Status: Offline
Reply With Quote
Jan 12, 2012, 12:30 AM
 
Originally Posted by Eug View Post
We don't know, but why not both licensing and technical reasons?

I don't know enough about the technical side of ZFS to comment. However, even though I know everyone raves about ZFS, I have to wonder if there weren't some OS X idiosyncrasies that made ZFS adoption harder. One comment has been made that ZFS was more focused on the enterprise server space, and that widespread adoption at the single user level for an established OS like OS X was potentially a different kettle of fish.
ZFS likes RAM, but this is used primarily for distributing its checksums across multiple disks AFAIK. The question to me is more so how Apple can engineer their machines to have more than one disk, because not depending on a single SATA drive for either reliability or overall capacity to me is the golden egg.

Everybody is going rah rah over SSDs, rightfully so, but I think there will always be a need for cheap storage/capacity, so to me it doesn't make a tremendous amount of sense to dive into ZFS without also diving into a strategy to go beyond just single disk systems.

A low capacity SSD would make a great read or write buffer. All you'd need is, say, a 10 gig SSD for this, plus SATA drives for permanent storage. That would be awesome.

Like I said, a new file system may change how Apple designs their machines from the ground up.
     
P
Moderator
Join Date: Apr 2000
Location: Gothenburg, Sweden
Status: Offline
Reply With Quote
Jan 12, 2012, 02:41 AM
 
One of the ZFS engineers at Sun confirmed that it was a licensing issue - basically that Apple wanted to relicense it from Sun under different terms, and they couldn't come to an agreement - but wouldn't elaborate. The Oracle merger may have been the reason that the talks broke down, as it was in the same era. I'm out traveling, but I'll see if I can find that link when I get home.

Note that this version does not support booting from ZFS.
The new Mac Pro has up to 30 MB of cache inside the processor itself. That's more than the HD in my first Mac. Somehow I'm still running out of space.
     
Clinically Insane
Join Date: Oct 2000
Location: Los Angeles
Status: Offline
Reply With Quote
Jan 12, 2012, 02:56 AM
 
The interesting thing about the project is that it's being led by a former Apple employee, one of the HFS Extended engineers. This guy knows this field, but obviously he can only do so much without Apple's blessing.

It's really too bad if a licensing snag caused Apple to walk away from ZFS. Based on the spec sheets, it seems light years ahead of every mainstream filesystem architecture, and it seems like a perfectly ideal successor to HFS Extended.

"The natural progress of things is for liberty to yield and government to gain ground." TJ
     
Moderator
Join Date: May 2001
Location: Hilbert space
Status: Offline
Reply With Quote
Jan 12, 2012, 04:34 AM
 
@Eug
It had nothing to do with OS X's underlying architecture.

I've also heard it was a licensing thing. It really sucks and I think it has thrown Apple's internal efforts (which I'm sure there are) a few years back.

If you look at the implementation of Spotlight, Time Machine and Versions, this really screams for a new file system which not just solves the reliability issues I'm having, but also makes it easier and to implement more efficient search, backup and versioning capabilities. But given the focus on iOS and the move away from file systems (on the user end), I wonder how much effort is put into a »new FS skunkworks project«.
I don't suffer from insanity, I enjoy every minute of it.
     
Addicted to MacNN
Join Date: Mar 2004
Location: UK
Status: Offline
Reply With Quote
Jan 12, 2012, 04:51 AM
 
I also half-heard, half-assumed it was a licensing thing. I was very excited when ZFS was supposed to be on the way (Was it the Leopard betas?), pity it never got there. I might have to play with this new version. Nothing mission critical though.
I have plenty of more important things to do, if only I could bring myself to do them....
     
P
Moderator
Join Date: Apr 2000
Location: Gothenburg, Sweden
Status: Offline
Reply With Quote
Jan 12, 2012, 05:03 AM
 
Originally Posted by Waragainstsleep View Post
I also half-heard, half-assumed it was a licensing thing. I was very excited when ZFS was supposed to be on the way (Was it the Leopard betas?), pity it never got there.
Leopard has ZFS readonly support. Snow Leopard server was supposed to have readwrite ZFS support (but not root&boot, IIRC) - even announced on the product page - but that feature was pulled.
The new Mac Pro has up to 30 MB of cache inside the processor itself. That's more than the HD in my first Mac. Somehow I'm still running out of space.
     
Posting Junkie
Join Date: Oct 2005
Location: Houston, TX
Status: Offline
Reply With Quote
Jan 12, 2012, 05:18 PM
 
Originally Posted by 11011001 View Post
[*]Instantaneous copy-on-write snapshots. The overhead is practically non-existant in terms of performance. The metadata for the snapshot is also minimal.
They're atomic and relatively quick, but they're not instantaneous. A new snapshot takes 2-3 seconds on a small pool (~1TB).

Originally Posted by 11011001 View Post
[*]Options to enable compression and deduplication.
The deduplication is functional but not very pleasant, especially during large deletes.
     
Clinically Insane
Join Date: Mar 2001
Location: yes
Status: Offline
Reply With Quote
Jan 12, 2012, 05:29 PM
 
I also wonder how dedup would benefit a typical Mac user. Isn't it best for copies of the same data, duplicate libraries, manually created backups, and similar stuff that you'd be more likely to find on a server?
     
Posting Junkie
Join Date: Oct 2005
Location: Houston, TX
Status: Offline
Reply With Quote
Jan 12, 2012, 07:06 PM
 
I doubt it would be useful. The voluminous data that most users have on a single machine isn't repetitive in ways that dedup or compression helps with.

Time Machine with snapshots would be awesome, since it could keep making them even when your backup device wasn't connected (mobile users).

The checksumming/background scrub would be good for early disk failure detection.

ZIL with a small (~5GB) high performance (~80k IOPS) SSD would be great. I doubt an L2ARC would be very useful for average desktop users.
     
Clinically Insane
Join Date: Mar 2001
Location: yes
Status: Offline
Reply With Quote
Jan 12, 2012, 07:22 PM
 
Originally Posted by mduell View Post
I doubt it would be useful. The voluminous data that most users have on a single machine isn't repetitive in ways that dedup or compression helps with.
Agreed. One thing not in the list though is ZFS encryption. Encryption could be the basis of a complete Filevault replacement.

Time Machine with snapshots would be awesome, since it could keep making them even when your backup device wasn't connected (mobile users).
That and it would happen so seamlessly you wouldn't even know it was doing its thing. My TM backups take a few minutes or so now, and sometimes bog things down (understandably so, given the I/O needed to do these).

The checksumming/background scrub would be good for early disk failure detection.
Wouldn't multiple disks be needed for that?

ZIL with a small (~5GB) high performance (~80k IOPS) SSD would be great. I doubt an L2ARC would be very useful for average desktop users.
Doesn't video production need a lot of read buffering? I mean local video via iMovie or Final Cut, with internet video the bottleneck is probably not disk.
     
Posting Junkie
Join Date: Oct 2005
Location: Houston, TX
Status: Offline
Reply With Quote
Jan 12, 2012, 11:12 PM
 
Originally Posted by besson3c View Post
Agreed. One thing not in the list though is ZFS encryption. Encryption could be the basis of a complete Filevault replacement.
Encryption was added in zpool v30.

Originally Posted by besson3c View Post
Wouldn't multiple disks be needed for that?
No, the checksum for each block is stored. It's error detection, not error correction.

Originally Posted by besson3c View Post
Doesn't video production need a lot of read buffering? I mean local video via iMovie or Final Cut, with internet video the bottleneck is probably not disk.
Possibly, but if you're doing it at the scale where you need more read buffering than you have RAM, you're going to need a pretty large (expensive) L2ARC.
     
Clinically Insane
Join Date: Mar 2001
Location: yes
Status: Offline
Reply With Quote
Jan 12, 2012, 11:17 PM
 
Originally Posted by mduell View Post
Encryption was added in zpool v30.
Yeah, it is a pretty recent addition.

No, the checksum for each block is stored. It's error detection, not error correction.
But how are correct checksums confirmed/verified?

Possibly, but if you're doing it at the scale where you need more read buffering than you have RAM, you're going to need a pretty large (expensive) L2ARC.
True, although RAM is used for write buffering too, right?

I'm not disagreeing with your basic premise, I'm just sort of thinking outloud whether it would make sense to build in an L2ARC cache into a Mac Pro or something. Then again, I don't think Apple gives a rat's ass about the Mac Pro anymore.
     
Moderator
Join Date: May 2001
Location: Hilbert space
Status: Offline
Reply With Quote
Jan 13, 2012, 04:23 AM
 
So I'm seriously considering to move at least one of my backup drives to ZFS. It's almost full, so most of the time, Time Machine needs to remove a backup before adding the new one. After about a week's use, I get inconsistencies in the HFS+ structure, so I'm hoping a move to ZFS will fix this.
I don't suffer from insanity, I enjoy every minute of it.
     
Professional Poster
Join Date: Jan 2001
Location: Australia, the greatest country in the world, (Australians keep telling me).
Status: Offline
Reply With Quote
Jan 13, 2012, 04:37 AM
 
If HFS case sensitive causes problems with some apps, I hate think what a third party FS would do.

I will stick with the majority Mac FS.
     
Moderator
Join Date: May 2001
Location: Hilbert space
Status: Offline
Reply With Quote
Jan 13, 2012, 06:59 AM
 
@moonmonkey
I think this impression is a left-over from the early days of OS X. Unless you're running Symantec software (then something is wrong with you anyway ), I haven't noticed any issues.
I don't suffer from insanity, I enjoy every minute of it.
     
Clinically Insane
Join Date: Mar 2001
Location: yes
Status: Offline
Reply With Quote
Jan 13, 2012, 07:22 AM
 
Originally Posted by moonmonkey View Post
If HFS case sensitive causes problems with some apps, I hate think what a third party FS would do.

I will stick with the majority Mac FS.
Does that mean you'll skip using Samba, NFS, or AFP network volumes too?

The problem isn't necessarily a foreign file system, in my mind it's how it will work alongside OS X as OS X is updated, and whether there will be much to gain with a single disk.
     
Posting Junkie
Join Date: Oct 2005
Location: Houston, TX
Status: Offline
Reply With Quote
Jan 13, 2012, 12:29 PM
 
Originally Posted by besson3c View Post
But how are correct checksums confirmed/verified?
Data and checksum are written at write time. During the periodic (or on demand) scrub, data is read, checksummed, and checked against the stored checksum.
If data is corrupt and stored checksum is fine, new checksum and stored checksum won't match.
If data is fine and stored checksum is corrupt, new checksum and stored checksum won't match.
If data is corrupt and stored checksum is corrupt, new checksum and stored checksum very very likely won't match.

There's no recovery in a single disk or striped pool, but as soon as one block (data or checksum) is corrupted, you know within a short period of time and can replace the drive.

Originally Posted by besson3c View Post
True, although RAM is used for write buffering too, right?
No, the only write caches are the ZIL(s) and a drive's onboard cache. RAM is only used for read buffering with the (L1)ARC.

Originally Posted by besson3c View Post
I'm not disagreeing with your basic premise, I'm just sort of thinking outloud whether it would make sense to build in an L2ARC cache into a Mac Pro or something. Then again, I don't think Apple gives a rat's ass about the Mac Pro anymore.
In some situation where you were constrained to slow (5400-7200rpm) disks, a few hundred gig SSD would be great. But if you can afford a Mac Pro and a $1000 L2ARC SSD, you can probably afford some decent disks.

There is a niche out there for a photog with 3x2TB where a 120 GB SSD does wonders of their working set of RAWs from a single project. It's just not as broadly useful as the write caching ZIL. Above I said 5GB but even a really fast 1GB would be great for average users, although write endurance concerns may push the size up.
     
Clinically Insane
Join Date: Mar 2001
Location: yes
Status: Offline
Reply With Quote
Jan 13, 2012, 12:41 PM
 
Originally Posted by mduell View Post
Data and checksum are written at write time. During the periodic (or on demand) scrub, data is read, checksummed, and checked against the stored checksum.
If data is corrupt and stored checksum is fine, new checksum and stored checksum won't match.
If data is fine and stored checksum is corrupt, new checksum and stored checksum won't match.
If data is corrupt and stored checksum is corrupt, new checksum and stored checksum very very likely won't match.
I know, but what good is comparing checksums on a single disk when that disk can be failing? To me the whole copy on write thing gives you that reliability when the checksums can be compared across disks, so that if one disk is failing, the other disks can indicate that the integrity of the failing disk is off. With failing hardware you have failing integrity - you can't have absolute integrity with a single disk, right?
     
Posting Junkie
Join Date: Oct 2005
Location: Houston, TX
Status: Offline
Reply With Quote
Jan 13, 2012, 02:35 PM
 
Originally Posted by besson3c View Post
I know, but what good is comparing checksums on a single disk when that disk can be failing? To me the whole copy on write thing gives you that reliability when the checksums can be compared across disks, so that if one disk is failing, the other disks can indicate that the integrity of the failing disk is off. With failing hardware you have failing integrity - you can't have absolute integrity with a single disk, right?
To detect the failure of disks, specifically bit rot. You don't need multiple disks to detect it, since the chances of corrupted data matching a corrupted checksum are astronomical.
     
Clinically Insane
Join Date: Mar 2001
Location: yes
Status: Offline
Reply With Quote
Jan 13, 2012, 02:41 PM
 
Originally Posted by mduell View Post
To detect the failure of disks, specifically bit rot. You don't need multiple disks to detect it, since the chances of corrupted data matching a corrupted checksum are astronomical.
I see your point with bit rot. For some reason I thought we were talking about something approaching reliable integrity.

How many copies of checksums are kept on a single disk?
     
Posting Junkie
Join Date: Oct 2005
Location: Houston, TX
Status: Offline
Reply With Quote
Jan 13, 2012, 04:53 PM
 
Originally Posted by besson3c View Post
I see your point with bit rot. For some reason I thought we were talking about something approaching reliable integrity.

How many copies of checksums are kept on a single disk?
One per copy* of the data, stored in the block pointer. Block pointers are also checksummed, which is saved in their pointer. All the way up to the root node for a complete Merkle tree.

* You can have ZFS store multiple copies of the data on a single disk, and in that case each would have the checksum for each block stored in the block pointer.
     
Clinically Insane
Join Date: Mar 2001
Location: yes
Status: Offline
Reply With Quote
Jan 14, 2012, 02:35 PM
 
Originally Posted by mduell View Post
One per copy* of the data, stored in the block pointer. Block pointers are also checksummed, which is saved in their pointer. All the way up to the root node for a complete Merkle tree.

* You can have ZFS store multiple copies of the data on a single disk, and in that case each would have the checksum for each block stored in the block pointer.

So if there is one checksum per copy of data on a single disk, how would ZFS detect bit rot? What would those checksums be compared against? Checksum against actual copy of data? With this, bit rot detection but no self healing?

Are you referring to partitioning the single disk with your asterisk point here?

If we're on the same page here my ideal Apple ZFS implementation would still involve two disks for self healing. I'm assuming self healing would work with a mirror?
     
Posting Junkie
Join Date: Oct 2005
Location: Houston, TX
Status: Offline
Reply With Quote
Jan 15, 2012, 12:34 AM
 
Originally Posted by besson3c View Post
So if there is one checksum per copy of data on a single disk, how would ZFS detect bit rot? What would those checksums be compared against? Checksum against actual copy of data? With this, bit rot detection but no self healing?
The data is read, checksummed, and compared to the stored checksum on disk. If either (or both) the data or the stored checksum were corrupted on write or on read the checksums won't match. This alone provides corruption/bit rot detection. Self healing can be accomplished in a number of ways, below.

Originally Posted by besson3c View Post
Are you referring to partitioning the single disk with your asterisk point here?
Partitioning a drive before being used in a ZFS vdev is a bad idea since then ZFS can't/won't turn on write caching. You want to expose whole real drives to ZFS.

ZFS has the option of storing each block multiple times with the copies option. The pool has a settable default number of copies which you can override on a per filesystem basis. So your pool could be copies=1, but your documents filesystem can be copies=2 or copies=3. Since filesystems are so flexible (can expand to fill the entire pool unless you put a limit on them) in ZFS compared to legacy filesystems, using this sort of setup isn't a hassle.

Originally Posted by besson3c View Post
If we're on the same page here my ideal Apple ZFS implementation would still involve two disks for self healing. I'm assuming self healing would work with a mirror?
Self healing obviously works with mirror or zraid(123) vdevs. It can also work with single drive vdevs (even if you only have one single drive vdev in your entire pool) using copies>1 on the pool or filesystem. If you use copies=2 on a pool containing >1 single drive vdevs (which are effectively striped/aggregated for the pool), ZFS will put the copies on different drives.
     
Clinically Insane
Join Date: Mar 2001
Location: yes
Status: Offline
Reply With Quote
Jan 15, 2012, 01:21 AM
 
Cool!

Yeah, I knew that partitioning a drive wasn't a recommended thing with ZFS, I would have been surprised if you were referring to that. I wasn't aware of the copies zpool option. Do you know what zpool version this was added to? It's possible that I don't have this with my Solaris 10 system maybe? Or, I could just be blind and/or ignorant (or both

So, with copies = 2 you'd basically have three checksums to work from (actual file, copy 1, copy 2), and the self healing would work by using the checksum reported by 2 of the 3 sources, right?

These copies are snapshot copies, right? Therefore, it wouldn't take a whole lot of disk space for an OS X ZFS implementation to keep, say, 2 copies in key folders such as ~/Documents, ~/Desktop, etc.? What's kind of cool to think about is how these snapshots could be stored in iCloud, a network disk, whatever, so you could facilitate self healing on a single disk.

Add this to my list of ways a new file system like ZFS would be a complete game changer for Apple, assuming I have these details more or less accurate. If my iCloud/USB drive/network share snapshot copies idea is feasible, this would facilitate self healing on single disk systems.
     
Posting Junkie
Join Date: Oct 2005
Location: Houston, TX
Status: Offline
Reply With Quote
Jan 17, 2012, 12:23 AM
 
Originally Posted by besson3c View Post
Yeah, I knew that partitioning a drive wasn't a recommended thing with ZFS, I would have been surprised if you were referring to that. I wasn't aware of the copies zpool option. Do you know what zpool version this was added to? It's possible that I don't have this with my Solaris 10 system maybe? Or, I could just be blind and/or ignorant (or both
copies was very early, like v4-6ish.

Originally Posted by besson3c View Post
So, with copies = 2 you'd basically have three checksums to work from (actual file, copy 1, copy 2), and the self healing would work by using the checksum reported by 2 of the 3 sources, right?

These copies are snapshot copies, right? Therefore, it wouldn't take a whole lot of disk space for an OS X ZFS implementation to keep, say, 2 copies in key folders such as ~/Documents, ~/Desktop, etc.? What's kind of cool to think about is how these snapshots could be stored in iCloud, a network disk, whatever, so you could facilitate self healing on a single disk.

Add this to my list of ways a new file system like ZFS would be a complete game changer for Apple, assuming I have these details more or less accurate. If my iCloud/USB drive/network share snapshot copies idea is feasible, this would facilitate self healing on single disk systems.
No. We're talking about blocks, not files; a file can be one or more blocks. Blocks are variable size up to 128KB. For each block, a hash (I forget the size, 8-32 bytes) is also stored; it's just a checksum, not full parity data. With copies=2 the block data is written to two different places on disk and the hash is also stored in 2 different locations. The self healing is during the scrub where it reads the first copy of the data and hash, compares them, and later reads the second copy of the data and the second copy of the hash, and compares them. If the first copy doesn't match the first hash, but the second copy does match the second hash, it deletes the first copy and makes third copy from the second somewhere else on disk.

This is completely unlike snapshots. A snapshot is a reference to a list of blocks as they were when you took the snapshot. Using copies=2 halves the size of the pool/file system you're using it on.

The big deal about the checksum and routine periodic scrubs is that it detects corruption and automatically fixes it or lets you know so you can manually recover from a backup.
     
Moderator
Join Date: May 2001
Location: Hilbert space
Status: Offline
Reply With Quote
Jan 25, 2012, 04:14 AM
 
JFYI ZETO Silver edition is available now. I've purchased it and played with it a bit. The drive on which I keep my Aperture vault is now formatted in ZFS. Aperture hasn't complained (I opted for case-sensitivity) and tonight I will do a scrub just for good measure.

If ZFS runs stably, I will convert one Time Machine drive to ZFS.
I don't suffer from insanity, I enjoy every minute of it.
     
Clinically Insane
Join Date: Mar 2001
Location: yes
Status: Offline
Reply With Quote
Jan 25, 2012, 04:16 AM
 
Oreo: are you using this via a NAS, or just via local USB drives?
     
Moderator
Join Date: May 2001
Location: Hilbert space
Status: Offline
Reply With Quote
Jan 25, 2012, 04:43 AM
 
Just a local USB drive for now. It's definitely a test balloon. Also my other backup drives are just single USB/FireWire drives. When I was upgrading my backup strategy, I thought about getting a NAS, a Drobo or something like that, but I decided it was better to simply keep one Time Machine drive at home, one Time Machine drive at work and an additional drive as a dedicated Aperture vault. I also keep active work projects on my Dropbox (I'm a scientists, so none of this stuff is sensitive or particularly interesting to the layperson).

I wish I could test it in more complex setups, but I don't have a spare machine.

The reason to migrate my backups to ZFS is simple: I no longer trust HFS+, after a week's worth of backups, I find lots of inconsistencies on one of my backup drives (the one which is almost full).
I don't suffer from insanity, I enjoy every minute of it.
     
Clinically Insane
Join Date: Mar 2001
Location: yes
Status: Offline
Reply With Quote
Jan 25, 2012, 04:48 AM
 
Originally Posted by OreoCookie View Post
Just a local USB drive for now. It's definitely a test balloon. Also my other backup drives are just single USB/FireWire drives. When I was upgrading my backup strategy, I thought about getting a NAS, a Drobo or something like that, but I decided it was better to simply keep one Time Machine drive at home, one Time Machine drive at work and an additional drive as a dedicated Aperture vault. I also keep active work projects on my Dropbox (I'm a scientists, so none of this stuff is sensitive or particularly interesting to the layperson).

I wish I could test it in more complex setups, but I don't have a spare machine.

The reason to migrate my backups to ZFS is simple: I no longer trust HFS+, after a week's worth of backups, I find lots of inconsistencies on one of my backup drives (the one which is almost full).

Ahhh, just asking because I've been entertaining getting some SSDs and putting the bulk of data on a local ZFS NAS, but I've been unsure as to what sort of problems I'd invite with OS X's Samba or NFS implementation.
     
Moderator
Join Date: May 2001
Location: Hilbert space
Status: Offline
Reply With Quote
Jan 25, 2012, 05:25 AM
 
Well, in the medium term, I expect to upgrade my MacBook Pro with an SSD and move the hard drive to the optical bay. Then I could opt to use ZFS on my hard drive and HFS+ on the SSD. But I'll wait a little longer and see how stable ZETO is. (I don't expect any problems, though.)
I don't suffer from insanity, I enjoy every minute of it.
     
Clinically Insane
Join Date: Mar 2001
Location: yes
Status: Offline
Reply With Quote
Jan 25, 2012, 06:09 AM
 
Originally Posted by OreoCookie View Post
Well, in the medium term, I expect to upgrade my MacBook Pro with an SSD and move the hard drive to the optical bay. Then I could opt to use ZFS on my hard drive and HFS+ on the SSD. But I'll wait a little longer and see how stable ZETO is. (I don't expect any problems, though.)
You might get some additional performance and reliability with ZFS on your SATA drive, and you'd have a cooler incremental backup system I think too. I'd be happy to help you write a shell script that would do ZFS snapshots at regular intervals if you haven't done something like this before. You'd have to give up on the cool Time Machine space GUI for accessing this data (unless somebody figures out a way to replace the TM backup job with ZFS snapshots), but accessing your snapshots would be as easy as a

cd [your_pool]/.zfs/snapshot

you could either get the Finder to show files/directories beginning with dots, or just:

ln -s [your_pool]/.zfs/snapshot ~/snapshots

to provide easy access to your snapshot directory. It's actually a little trippy to consider that while the files in this directory look and appear like any other file, they don't consume the space of regular files, so you can have snapshots going back months and months without really putting a huge dent in your HD space.

You'd have to roll your own script to create and turn over old snapshots though, like I said. I'm happy to post mine, if you'd like. ZFS snapshots f-ing rule.
     
P
Moderator
Join Date: Apr 2000
Location: Gothenburg, Sweden
Status: Offline
Reply With Quote
Jan 25, 2012, 06:37 AM
 
Originally Posted by OreoCookie View Post
If ZFS runs stably, I will convert one Time Machine drive to ZFS.
Please let us know how this works - I'm interested in trying the same thing.
The new Mac Pro has up to 30 MB of cache inside the processor itself. That's more than the HD in my first Mac. Somehow I'm still running out of space.
     
Moderator
Join Date: May 2001
Location: Hilbert space
Status: Offline
Reply With Quote
Jan 25, 2012, 07:03 AM
 
Thanks, besson, I definitely intended to use snapshots. Probably I'll start with manual snapshots first and then work my way up.
I don't suffer from insanity, I enjoy every minute of it.
     
Addicted to MacNN
Join Date: Mar 2004
Location: UK
Status: Offline
Reply With Quote
Jan 31, 2012, 07:11 PM
 
Guessing the Zevo site is taking a hammering, it all seems to have gone down.
I have plenty of more important things to do, if only I could bring myself to do them....
     
Mac Elite
Join Date: May 2000
Location: I've moved so many times; I forgot.
Status: Offline
Reply With Quote
Jan 31, 2012, 07:54 PM
 
Originally Posted by besson3c View Post
You might get some additional performance and reliability with ZFS on your SATA drive, and you'd have a cooler incremental backup system I think too. I'd be happy to help you write a shell script that would do ZFS snapshots at regular intervals if you haven't done something like this before. You'd have to give up on the cool Time Machine space GUI for accessing this data (unless somebody figures out a way to replace the TM backup job with ZFS snapshots)
The folks at Zevo already thought of that...

ZEVO - ZFS for OS X - Ars Technica OpenForum
From xoa: "ZEVO implements a "Snapshot Depot" system as well that will allow you to browse automatically created snapshots using the TM interface."
"My friend, there are two kinds of people in this world:
those with loaded guns, and those who dig. You dig."

-Clint in "The Good, the Bad and the Ugly"
     
Clinically Insane
Join Date: Mar 2001
Location: yes
Status: Offline
Reply With Quote
Jan 31, 2012, 08:07 PM
 
That's badass!
     
Moderator
Join Date: May 2001
Location: Hilbert space
Status: Offline
Reply With Quote
Feb 1, 2012, 05:15 AM
 
Awesome! If it remains stable, I'll probably switch to ZFS for main storage on my internal drive
I don't suffer from insanity, I enjoy every minute of it.
     
Clinically Insane
Join Date: Mar 2001
Location: yes
Status: Offline
Reply With Quote
Feb 1, 2012, 07:34 AM
 
A reader in that thread says that ARC is working, so if you have gobs of free RAM you'll have a nice read buffer. Check out these benchmarks this guy ran using xbench:

HFS+ Filesystm
Code:
Results 29.41
System Info
Xbench Version 1.3
System Version 10.7.2 (11C74)
Physical RAM 8192 MB
Model Macmini5,1

Drive Type Seagate FreeAgent GoFlex
Disk Test 29.41

Sequential 41.76
Uncached Write 51.67 31.72 MB/sec [4K blocks]
Uncached Write 45.79 25.91 MB/sec [256K blocks]
Uncached Read 24.88 7.28 MB/sec [4K blocks]
Uncached Read 69.47 34.92 MB/sec [256K blocks]

Random 22.69
Uncached Write 7.13 0.75 MB/sec [4K blocks]
Uncached Write 84.34 27.00 MB/sec [256K blocks]
Uncached Read 73.21 0.52 MB/sec [4K blocks]
Uncached Read 95.39 17.70 MB/sec [256K blocks]



ZFS Filesystem
Code:
Results 2781.25
System Info
Xbench Version 1.3
System Version 10.7.2 (11C74)
Physical RAM 8192 MB
Model Macmini5,1

Drive Type maczfs
Disk Test 2781.25

Sequential 1666.77
Uncached Write 513.86 315.50 MB/sec [4K blocks]
Uncached Write 10003.03 5659.71 MB/sec [256K blocks]
Uncached Read 3525.80 1031.84 MB/sec [4K blocks]
Uncached Read 14243.69 7158.77 MB/sec [256K blocks]

Random 8393.68
Uncached Write 3505.71 371.12 MB/sec [4K blocks]
Uncached Write 6753.34 2161.99 MB/sec [256K blocks]
Uncached Read 65005.29 460.65 MB/sec [4K blocks]
Uncached Read 35917.28 6664.71 MB/sec [256K]
     
Clinically Insane
Join Date: Mar 2001
Location: yes
Status: Offline
Reply With Quote
Feb 1, 2012, 07:36 AM
 
What edition of ZEVO are you guys running? It looks like the only differences between the editions is the provided GUI, and you can do the same stuff via the CLI, but it may be that the Snapshot Depot only works with Gold?
     
P
Moderator
Join Date: Apr 2000
Location: Gothenburg, Sweden
Status: Offline
Reply With Quote
Feb 1, 2012, 09:24 AM
 
This is looking very good. Let me see if I've got this straight:

* I can upgrade the backup drive to ZFS and just point Time Machine to it, right? The advantage then would be the reliability and performance of ZFS over HFS+. I don't think Time Machine will make use of snapshots, but it gets away from HFS+ hack to support hardlinks.
* If I upgrade the main (non-boot) HDD in the Mac to ZFS and partition the SSD to get a small (~30 GB) cache partition, I should be able to add that to the same pool as the HDD and in effect get an SSD cache. Anyone tried this?
* Any tools available to convert an existing drive from HFS+ to ZFS (he said, expecting the answer no). Cloning with CCC should work, I expect?
The new Mac Pro has up to 30 MB of cache inside the processor itself. That's more than the HD in my first Mac. Somehow I'm still running out of space.
     
Clinically Insane
Join Date: Mar 2001
Location: yes
Status: Offline
Reply With Quote
Feb 1, 2012, 09:51 AM
 
Originally Posted by P View Post
This is looking very good. Let me see if I've got this straight:

* I can upgrade the backup drive to ZFS and just point Time Machine to it, right? The advantage then would be the reliability and performance of ZFS over HFS+. I don't think Time Machine will make use of snapshots, but it gets away from HFS+ hack to support hardlinks.
As I understand it, you'd disable TM backups so that new backups are not being made by the TM system, let ZFS do them instead, and you'd point Time Machine at the snapshot repos being maintained by ZFS so that you can browse through your TM backups via the space interface.

* If I upgrade the main (non-boot) HDD in the Mac to ZFS and partition the SSD to get a small (~30 GB) cache partition, I should be able to add that to the same pool as the HDD and in effect get an SSD cache. Anyone tried this?
Not a good idea. It is recommended that your pools consist of entire, non-partitioned disks.

* Any tools available to convert an existing drive from HFS+ to ZFS (he said, expecting the answer no). Cloning with CCC should work, I expect?
There is no conversion necessary, just a straight up copy to the ZFS volume should work however you want to do that.
     
 
Thread Tools
Forum Links
Forum Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts
BB code is On
Smilies are On
[IMG] code is On
HTML code is Off
Trackbacks are On
Pingbacks are On
Refbacks are On
Top
Privacy Policy
All times are GMT -4. The time now is 08:11 PM.
All contents of these forums © 1995-2014 MacNN. All rights reserved.
Branding + Design: www.gesamtbild.com
vBulletin v.3.8.8 © 2000-2014, Jelsoft Enterprises Ltd., Content Relevant URLs by vBSEO 3.3.2