Welcome to the MacNN Forums.

besson3c · Feb 1, 2012, 10:58 AM

It's going to be interesting to see how this product affects the Mac world, politically...

If it gets rave reviews, people become completely comfortable with it, a ton of users start using it, could this result in Apple abandoning whatever they are working or not working on and buying this product out?

I maintain that the whole licensing issue was a myth, and that it was more political issues that resulted in Apple dropping their ZFS project. However, now with the whole Illumos group and several non-Oracle entities being involved with ZFS, maybe Apple will change their tune?

P · Feb 1, 2012, 01:05 PM

Originally Posted by besson3c

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.

And that's great if all I want is protection against accidental deletion (assuming that there is something making those snapshots automatically), but it doesn't save my bacon if the HDD dies - which is the main thing I want guarding against. I guess I could set up some sort of RAID1 using the builtin tools, but that's not really what I was after either.

Originally Posted by besson3c

Not a good idea. It is recommended that your pools consist of entire, non-partitioned disks.

Well that's not possible, because there are only two SATA ports on this iMac and ZEVO does not currently support booting from ZFS, so I need one drive to boot from. Does it make any difference that I only want the SSD as a cache?

Originally Posted by besson3c

There is no conversion necessary, just a straight up copy to the ZFS volume should work however you want to do that.

Just copying in the Finder or with cp will not work because of metadata. It will have to be a cloning app, and apparently CCC will not work with ZFS. I know I could fix this in the command line, but that's tricky and I'd hate to make a mistake.

P · Feb 1, 2012, 01:08 PM

Originally Posted by besson3c

I maintain that the whole licensing issue was a myth, and that it was more political issues that resulted in Apple dropping their ZFS project. However, now with the whole Illumos group and several non-Oracle entities being involved with ZFS, maybe Apple will change their tune?

It was not a myth. There may have been more to it than that, however - specifically the NetApp lawsuit, which has since been settled - but in general I think Apple was worried about submarine patents. As time passes and ZFS remains in the hands of the very flush Oracle (as opposed to the almost bankrupt Sun), this risk is likely to lessen.

besson3c · 01:29 PM

Originally Posted by P

And that's great if all I want is protection against accidental deletion (assuming that there is something making those snapshots automatically), but it doesn't save my bacon if the HDD dies - which is the main thing I want guarding against. I guess I could set up some sort of RAID1 using the builtin tools, but that's not really what I was after either.

Ahhh, well for that zfs send/receive works to backup to another machine running ZFS as well. Otherwise, rsync would also work. ZFS send/receive can work by taking an initial backup of your data, and then subsequent snapshots from that point on:

ZFS Replication - Mark's blog

Well that's not possible, because there are only two SATA ports on this iMac and ZEVO does not currently support booting from ZFS, so I need one drive to boot from. Does it make any difference that I only want the SSD as a cache?

Nope, partitions are still not recommended. This idea of yours also wouldn't work well since having a mirror of your L2ARC/ZIL is also recommended. Otherwise, if that drive were to fail you could face data loss of all uncommitted data. I'm still wrapping my head around how ZFS works on a single-disk setup, but I believe that it would simply be able to be proactive in altering you to bit rot. With cache data, I'm not sure what would happen if your SATA drive were to fail such that the cache could not flush?

Paging mduell...

At any rate, it's probably best to save this until a future date. You might like ZFS so much that you decide to build yourself a NAS or something

Just copying in the Finder or with cp will not work because of metadata. It will have to be a cloning app, and apparently CCC will not work with ZFS. I know I could fix this in the command line, but that's tricky and I'd hate to make a mistake.

Isn't all Finder metadata stored in xattr these days anyway?

Because you'd need to boot off of HFS, the metadata would still be saved on the HFS volume anyway, so I don't think this will be a concern regardless, unless the Finder doesn't track metadata with external/network volumes or whatever the ZFS pool would be presented as? Maybe ZEVO does some trickery to make the Finder think that the volume is an HFS volume where metadata should be tracked?

besson3c · Feb 1, 2012, 01:26 PM

Originally Posted by P

It was not a myth. There may have been more to it than that, however - specifically the NetApp lawsuit, which has since been settled - but in general I think Apple was worried about submarine patents. As time passes and ZFS remains in the hands of the very flush Oracle (as opposed to the almost bankrupt Sun), this risk is likely to lessen.

That's an interesting post, one I haven't come across before, but why would Sun in their right mind commit to supporting Apple's crap and whatever closed source stuff they decide to do, and perhaps more importantly, why would Apple even think of asking for this? Even if Apple were to have paid Sun through the roof, how would they be in any position to support something like, say, Apple's Filevault or something as non-Apple employees?

I guess the non-idemnification was for the possibility of submarine patents?

Waragainstsleep · Feb 1, 2012, 03:26 PM

I haven't read too much about this yet. I'm making my way through the thread on ars, but can someone answer the following:

1) Would this be worth using with my 15 bay Promise SATA-UW SCSI RAID? I'd have to get an Intel Xserve, Mac Pro or a hackintosh to run it from, but does it play nice with RAID hardware or does one negate some of the other?
2) Does the basic $20 option come with the full suite of CLI tools as people are speculating?
3) How are those benchmarks posted above so much improved on a single disk? Is it a single disk? I'm guessing from the reported speeds its a Thunderbolt disk but I thought they only just came out.

besson3c · Feb 1, 2012, 03:54 PM

Originally Posted by Waragainstsleep

I haven't read too much about this yet. I'm making my way through the thread on ars, but can someone answer the following:

1) Would this be worth using with my 15 bay Promise SATA-UW SCSI RAID? I'd have to get an Intel Xserve, Mac Pro or a hackintosh to run it from, but does it play nice with RAID hardware or does one negate some of the other?

You definitely do *not* want to be running hardware RAID along with ZFS, which is a software RAID replacement for RAID types that were traditionally done with hardware because they were unsafe to do with hardware.

2) Does the basic $20 option come with the full suite of CLI tools as people are speculating?

It sounds like you get the standard ZFS Sun/Oracle CLI tools that you get with any ZFS implementation no matter what ZEVO package you buy.

3) How are those benchmarks posted above so much improved on a single disk? Is it a single disk? I'm guessing from the reported speeds its a Thunderbolt disk but I thought they only just came out.

If they are to be believed it is because of read caching done with RAM. ZFS supports read and write caching with RAM and/or dedicated disks. ZFS will use both available RAM and dedicated ZIL (write cache) and L2ARC (read cache) disks, as available.

P · Feb 1, 2012, 05:05 PM

Originally Posted by besson3c

Nope, partitions are still not recommended. This idea of yours also wouldn't work well since having a mirror of your L2ARC/ZIL is also recommended. Otherwise, if that drive were to fail you could face data loss of all uncommitted data.

ZIL, yes. L2ARC is only a read cache, so there won't ever BE any uncommitted data on the drive.

Originally Posted by besson3c

I'm still wrapping my head around how ZFS works on a single-disk setup, but I believe that it would simply be able to be proactive in altering you to bit rot. With cache data, I'm not sure what would happen if your SATA drive were to fail such that the cache could not flush?

I get a new drive and restore from my backup. This is not a server - I don't need the last millisecond of work. Time Machine gets me the last hour, and complete HD crashes are rare enough that I don't need more.

What I'm after is a more reliable filesystem than HFS+, and an SSD cache. The SSD cache is because I've seen how great the tiny 4 GB read-only cache in a hybrid laptop drive is compared to a regular 2.5" drive. I do not fill the 120 gig SSD I have, so I could move stuff in and out to make my Mac faster, but I generally don't want to bother with it.

Originally Posted by besson3c

Isn't all Finder metadata stored in xattr these days anyway?

No, but that's not the point either. The Finder metadata will be fine. The problem is the owner/group data and the modbits, which get reset to me/my_private_group and whatever my umask sets them to when I copy them. That's not good - and even if I were to copy as root, it would change stuff. Cloning apps avoid that, but apparently they don't work with ZFS (yet).

Originally Posted by besson3c

Because you'd need to boot off of HFS, the metadata would still be saved on the HFS volume anyway, so I don't think this will be a concern regardless, unless the Finder doesn't track metadata with external/network volumes or whatever the ZFS pool would be presented as? Maybe ZEVO does some trickery to make the Finder think that the volume is an HFS volume where metadata should be tracked?

The setup is one 120 gig SSD with OS + apps, one 1 TB HDD with data and assorted accumulated gunk, and one 1 TB HDD which is the Time Machine backup. I'd like to convert both the backup and the regular HDD to ZFS, if possible, and that means that I somehow have to get the current data on the HDD onto a new filesystem. If I can't convert the fs on the HDD, I need a cloning solution.

Originally Posted by besson3c

That's an interesting post, one I haven't come across before, but why would Sun in their right mind commit to supporting Apple's crap and whatever closed source stuff they decide to do, and perhaps more importantly, why would Apple even think of asking for this?

A stack of shiny silver dollars, if that's what they wanted. Sun was hurting bad at that point.

Originally Posted by besson3c

Even if Apple were to have paid Sun through the roof, how would they be in any position to support something like, say, Apple's Filevault or something as non-Apple employees?

Give them a task and make sure to define the APIs clearly. Anyway, FileVault is a bad example, because that would just be Apple making an interface to ZFS encryption.

Originally Posted by besson3c

I guess the non-idemnification was for the possibility of submarine patents?

That and the then-ongoing NetApp lawsuit. I think that that was a big factor - the case was not settled, and there was a real chance that Apple would be added to the lawsuit had they added ZFS to OS X.

Waragainstsleep · Feb 1, 2012, 05:12 PM

So I should stick to HFS+ for my RAIDs then? Well thats good really since they are just going to be iTunes libraries for the most part and it saves me trying to find somewhere between a few hundred and a grand or so for an Intel Xserve.

besson3c · 06:06 PM

Originally Posted by P

ZIL, yes. L2ARC is only a read cache, so there won't ever BE any uncommitted data on the drive.

I get a new drive and restore from my backup. This is not a server - I don't need the last millisecond of work. Time Machine gets me the last hour, and complete HD crashes are rare enough that I don't need more.

What I'm after is a more reliable filesystem than HFS+, and an SSD cache. The SSD cache is because I've seen how great the tiny 4 GB read-only cache in a hybrid laptop drive is compared to a regular 2.5" drive. I do not fill the 120 gig SSD I have, so I could move stuff in and out to make my Mac faster, but I generally don't want to bother with it.

You're right that you wouldn't have to worry about data loss with the read cache, I should have been more precise and/or clear in my thinking.

However, it also isn't a given that you'd benefit from the L2ARC cache. First of all, it depends on how much RAM you have, how big the files are that are read, and how much reads you do.

You could try running iostat at regular intervals to see what sort of read activity and performance you are getting now and going from there, but generally speaking most people seem to benefit more from the write cache, which is perhaps why my mind went there immediately.

No, but that's not the point either. The Finder metadata will be fine. The problem is the owner/group data and the modbits, which get reset to me/my_private_group and whatever my umask sets them to when I copy them. That's not good - and even if I were to copy as root, it would change stuff. Cloning apps avoid that, but apparently they don't work with ZFS (yet).

Why wouldn't a cp -a or rsync -a work to preserve this info? You could also create tarballs...

The setup is one 120 gig SSD with OS + apps, one 1 TB HDD with data and assorted accumulated gunk, and one 1 TB HDD which is the Time Machine backup. I'd like to convert both the backup and the regular HDD to ZFS, if possible, and that means that I somehow have to get the current data on the HDD onto a new filesystem. If I can't convert the fs on the HDD, I need a cloning solution.

How about wiping the TM drive, copying everything there via one of the above methods, and copying it back to your drive using the same technique?

Give them a task and make sure to define the APIs clearly. Anyway, FileVault is a bad example, because that would just be Apple making an interface to ZFS encryption.

It would have to be Apple writing their own encryption, actually, the ZFS encryption is closed source.

That and the then-ongoing NetApp lawsuit. I think that that was a big factor - the case was not settled, and there was a real chance that Apple would be added to the lawsuit had they added ZFS to OS X.

I have to read more into all of this, I don't know anything about that lawsuit.

besson3c · Feb 1, 2012, 06:04 PM

Originally Posted by Waragainstsleep

So I should stick to HFS+ for my RAIDs then? Well thats good really since they are just going to be iTunes libraries for the most part and it saves me trying to find somewhere between a few hundred and a grand or so for an Intel Xserve.

It looks like when the Platinum edition of ZEVO comes out you'll be able to use ZFS, as the Platinum edition supports ZFS's RAIDZ. RAIDZ and RAIDZ2 are the ZFS equivalents of RAID5 and 6, respectfully...

I don't know why anybody would buy an XServe right now, but that's a whole other topic....

besson3c · Feb 1, 2012, 07:01 PM

P: I forgot to add that you can also zfs send/receive to an external drive on the same machine, so you could use it to backup/offload data for the migration.

P · Feb 1, 2012, 07:29 PM

Originally Posted by besson3c

You're right that you wouldn't have to worry about data loss with the read cache, I should have been more precise and/or clear in my thinking.

However, it also isn't a given that you'd benefit from the L2ARC cache. First of all, it depends on how much RAM you have, how big the files are that are read, and how much reads you do.

You could try running iostat at regular intervals to see what sort of read activity and performance you are getting now and going from there, but generally speaking most people seem to benefit more from the write cache, which is perhaps why my mind went there immediately.

It may be that L2ARC wouldn't help me a lot - or rather, that ARC would help enough given that I have 16 GB RAM and I honestly don't use all of it - but it would be nice to try. The effect of that tiny flash cache in a hybrid drive convinced me that there are some nice gains to be had there.

Originally Posted by besson3c

Why wouldn't a cp -a or rsync -a work to preserve this info? You could also create tarballs...

rsync would work, and is what I would do if I had to, but it's a finicky enough command that a GUI app would be useful. cp -a only acts to preserve files, not directories, for some reason. A set of tarballs are the ultimate fallback that will always work.

Originally Posted by besson3c

How about wiping the TM drive, copying everything there via one of the above methods, and copying it back to your drive using the same technique?

That would be the plan, yes. I'm just considering what the advantages would be of switching to ZFS (other than e-peen...) and how I should set it all up in the end. This stuff about not being able to use partitions is also troubling, because I have a boot camp partition that I'd like to keep.

Originally Posted by besson3c

It would have to be Apple writing their own encryption, actually, the ZFS encryption is closed source.

Shiny silver dollars...Anyway, not going to happen now.

Originally Posted by besson3c

I have to read more into all of this, I don't know anything about that lawsuit.

This piece is a decent enough place to start. Note that NetApp started suing other players in the ecosystem as well.

besson3c · Feb 1, 2012, 07:51 PM

To be clear, ZFS partitions *do* work AFAIK, they just aren't recommended. However, it might be that they aren't recommended for RAIDZ or ZFS mirrored sets, which would not be applicable to you.

mduell · 08:55 PM

Speaking of ZFS, we finished upgrading our off-site backup server from 1TB to 3TB drives today. Our data was never at risk because we had a spare in the pool which we would attach as a mirror of a in-service drive, wait for resilvering (about 8h) to complete, remove the in-service drive from the mirror, replace the in-service drive, add the new drive to the pool as a spare, wash, rinse repeat. Try that with a RAID controller that costs less than my house.

Nice to go from 88% capacity (16/18TB) to 28% capacity (16/57TB). FWIW the pool geometry is three 7 drive RAIDZ2s, yielding the capacity of 15 disks.

Originally Posted by besson3c

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:

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]

(emphasis mine)

This is just a symptom of what a shitty tool Xbench is; these are not actual writes to disk (ZIL or pool).

Originally Posted by P

* 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.

I don't know if Time Machine's directory hard link hack works with non-HFS+ filesystems. I'd stop TM and switch to snapshots.

Originally Posted by P

* 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?

Originally Posted by besson3c

Not a good idea. It is recommended that your pools consist of entire, non-partitioned disks.

The reasons for using whole disks with ZFS mostly don't apply here; from the Solaris Internals ZFS Best Practices Guide:

For production systems, use whole disks rather than slices for storage pools for the following reasons:

Allows ZFS to enable the disk's write cache for those disks that have write caches. If you are using a RAID array with a non-volatile write cache, then this is less of an issue and slices as vdevs should still gain the benefit of the array's write cache.
For JBOD attached storage, having an enabled disk cache, allows some synchronous writes to be issued as multiple disk writes followed by a single cache flush allowing the disk controller to optimize I/O scheduling. Separately, for systems that lacks proper support for SATA NCQ or SCSI TCQ, having an enabled write cache allows the host to issue single I/O operation asynchronously from physical I/O.
The recovery process of replacing a failed disk is more complex when disks contain both ZFS and UFS file systems on slices.
ZFS pools (and underlying disks) that also contain UFS file systems on slices cannot be easily migrated to other systems by using zpool import and export features.
In general, maintaining slices increases administration time and cost. Lower your administration costs by simplifying your storage pool configuration model.
Note: See the Additional Cautions section below prior to Nevada, build 117 bug id 6844090.

If you must use slices for ZFS storage pools, review the following:

Consider migrating the pools to whole disks after a transition period.
Use slices on small systems, such as laptops, where experts need access to both UFS and ZFS file systems.
However, take great care when reinstalling OSes in different slices so you don't accidentally clobber your ZFS pools.
Managing data on slices is more complex than managing data on whole disks.

For the L2ARC you don't care about write caching, the JBOD issues don't apply, the recovery concerns don't apply, the migration issues don't apply, and the administrative cost is low. For the ZIL all of the above non-applicability holds except for write caching, but you're still better off having it than not having it.

Originally Posted by besson3c

Nope, partitions are still not recommended. This idea of yours also wouldn't work well since having a mirror of your L2ARC/ZIL is also recommended. Otherwise, if that drive were to fail you could face data loss of all uncommitted data. I'm still wrapping my head around how ZFS works on a single-disk setup, but I believe that it would simply be able to be proactive in altering you to bit rot. With cache data, I'm not sure what would happen if your SATA drive were to fail such that the cache could not flush?

Paging mduell...

If the L2ARC fails, you lose nothing.
If the ZIL fails, you lose anything already committed to the ZIL but not to the pool. This is no worse than not using a ZIL.

Originally Posted by besson3c

It would have to be Apple writing their own encryption, actually, the ZFS encryption is closed source.

Only the Solaris implementation of ZFS encryption is closed source. The OpenSolaris, FreeBSD, etc implementations are open source.

Originally Posted by P

It may be that L2ARC wouldn't help me a lot - or rather, that ARC would help enough given that I have 16 GB RAM and I honestly don't use all of it - but it would be nice to try. The effect of that tiny flash cache in a hybrid drive convinced me that there are some nice gains to be had there.

It depends how much RAM you usually use; if it's 8GB, a 25GB L2ARC won't do much good but if it's >15GB, a 25GB L2ARC could be quite useful. However even a couple gigs of ZIL should be very useful.

besson3c · Feb 1, 2012, 09:03 PM

Originally Posted by mduell

Only the Solaris implementation of ZFS encryption is closed source. The OpenSolaris, FreeBSD, etc implementations are open source.

Well, OpenSolaris has been axed, encryption was added to ZFS pool v30 and FreeBSD 9 just released a week or two ago supports v28, so I doubt they have written their own encryption scheme. Are you sure that there is ZFS encryption in anything other than Solaris 11?

mduell · Feb 2, 2012, 12:22 AM

Originally Posted by besson3c

Well, OpenSolaris has been axed, encryption was added to ZFS pool v30 and FreeBSD 9 just released a week or two ago supports v28, so I doubt they have written their own encryption scheme. Are you sure that there is ZFS encryption in anything other than Solaris 11?

You're right, I hadn't been following the ZFS politics closely enough and I forgot how close to current it was added. No encryption in open ZFS implementations, everyone layers ZFS with Geli for full disk encryption.

P · Feb 2, 2012, 08:33 AM

Thank you mduell, this was enlightening.

So my read of this is that if I do use ZFS on a single slice, it will kill the disk cache. Correct? That basically means that I need to use L2ARC/ZIL or performance is likely to go down.

One of the linked threads above says that ZFS works with TM. My understanding - which might be incorrect, but I'll try it out - is that the hard links hack is in the filesystem layer, and that it was added to HFS for the explicit purpose of supporting TM in a way that would work transparently on a newer filesystem. TM on a ZFS drive (or for that matter a UFS drive) would thus simply have regular hard links. The question that remains is about directory hard links. UFS supports them (but only by root, and it is very much Not Recommended, and may even be disabled these days) and HFS+ does (with that infamous hack), but most file systems do not.

So the ZFS thing to do then would be to set up one pool on the internal HDD with a mirror on the external HDD and then set up regular snapshots. This would store the snapshots twice, but they're more efficient than TM anyway). ZEVO supports viewing the snapshots through Time Machine, but is there an interface for regular snapshots and thinning?

Hm. $20 is not a lot of money. I might just buy this and play with it.

besson3c · Feb 2, 2012, 10:26 AM

Originally Posted by P

One of the linked threads above says that ZFS works with TM. My understanding - which might be incorrect, but I'll try it out - is that the hard links hack is in the filesystem layer, and that it was added to HFS for the explicit purpose of supporting TM in a way that would work transparently on a newer filesystem. TM on a ZFS drive (or for that matter a UFS drive) would thus simply have regular hard links. The question that remains is about directory hard links. UFS supports them (but only by root, and it is very much Not Recommended, and may even be disabled these days) and HFS+ does (with that infamous hack), but most file systems do not.

Are you wondering whether your older TM backups will work? I'm a little confused as to what your overarching concern is here, given that in ZFS you won't want to continue using the TM hard link scheme over snapshots?

So the ZFS thing to do then would be to set up one pool on the internal HDD with a mirror on the external HDD and then set up regular snapshots. This would store the snapshots twice, but they're more efficient than TM anyway). ZEVO supports viewing the snapshots through Time Machine, but is there an interface for regular snapshots and thinning?

Hm. $20 is not a lot of money. I might just buy this and play with it.

This sounds like a good plan to me! Another piece of information that might be relevant to you is that you cannot grow your pools by adding new disks to them if they are RAIDZ, while you can do this with mirrors of any configuration. So, if you'd ever want to take those disks and move them elsewhere you'll be able to do a ZFS export, transplant your two disks, ZFS import, and you'll be back up and running without having to reconstruct your array.

One of the more popular drive configs is mirrored RAIDZ sets. A RAIDZ config needs a minimum of 3 drives, so a lot of people create two 3 drive RAIDZ sets and mirror them together, allowing you to grow the size of this pool by adding new drives in groups of 3. You can also skip RAIDZ and just grow your array by adding mirrors in groups of two.

This may be completely and utterly irrelevant to you, but I'm just saying this in case you might anticipate wanting to move to a NAS or some system with more drive bays while keeping your existing data and drives. In ZFS the holy grail is more drive bays, not single drives with a ton of capacity, so you can keep your 1TB drives for as long as they can be purchased and just keeping buying more and more rather than having to spend more on higher capacity drives. At some point in the future you can also up all of these drives to, say, 2TB drives as mduell has described without skipping a beat.

Again, sorry for the dump of extraneous info, but this might be useful to some who might be thinking of a growth strategy. You have to be a little calculated about this, because unfortunately you can't grow the capacity of a pool just by adding a single drive.

P · Feb 2, 2012, 11:11 AM

Originally Posted by besson3c

Are you wondering whether your older TM backups will work? I'm a little confused as to what your overarching concern is here, given that in ZFS you won't want to continue using the TM hard link scheme over snapshots?

My question is this: If I reformat the current backup drive and put ZFS on it, can I use it as a Time Machine target drive? This would be useful for two reasons:

1) "Toe in water" - get me a drive to play with and see if this ZFS thing is as good as they say.
2) Backups for other Macs - namely that MBA that has neither the RAM nor the drive bays to play with ZFS, and which will need to be backed up after any ZFS transition - and the boot drive. I could partition the external drive to leave an HFS+ partition, but apparently I should avoid that.

Originally Posted by besson3c

This sounds like a good plan to me!

Unfortunately ZFS mirrors requires the Gold edition, which is not released yet, so I guess I'll cool my heels for a little longer.

Originally Posted by besson3c

Another piece of information that might be relevant to you is that you cannot grow your pools by adding new disks to them if they are RAIDZ, while you can do this with mirrors of any configuration.
<clip>

This is interesting information, thank you. I'm not really planning on doing this, but it's useful to know.

besson3c · Feb 2, 2012, 11:17 AM

Originally Posted by P

My question is this: If I reformat the current backup drive and put ZFS on it, can I use it as a Time Machine target drive? This would be useful for two reasons:

1) "Toe in water" - get me a drive to play with and see if this ZFS thing is as good as they say.
2) Backups for other Macs - namely that MBA that has neither the RAM nor the drive bays to play with ZFS, and which will need to be backed up after any ZFS transition - and the boot drive. I could partition the external drive to leave an HFS+ partition, but apparently I should avoid that.

Ahhh...

AFAIK the TM backup scheme should work just fine. It isn't terribly unique or out-of-the-box in its approach, you can do the same thing in Linux and FreeBSD with the cpio command, so I don't see why it wouldn't work on ZFS as well.

besson3c · Feb 2, 2012, 11:19 AM

Sorry, missed this:

Unfortunately ZFS mirrors requires the Gold edition, which is not released yet, so I guess I'll cool my heels for a little longer.

You should be able to setup the mirror using the ZFS CLI utilities - just one simple command. It would probably be good to learn the CLI utilities anyway, they can provide a lot of useful info and configure a lot of useful features. They are actually very simple to use.

AFAIK the different ZEVO editions are about what the ZEVO GUI will make easy and what sorts of GUI level OS X interactions will be available.

P · Feb 2, 2012, 12:02 PM

Originally Posted by besson3c

You should be able to setup the mirror using the ZFS CLI utilities - just one simple command.

Nope. See that Ars thread, for instance, and multiple other posts around the web that Google found. Mirrors are not functional in the currently released Silver edition.

Also - can I expand one drive to a mirror with reformatting? If not I'm ending up in a chicken and egg scenario.

besson3c · Feb 2, 2012, 12:28 PM

Originally Posted by P

Nope. See that Ars thread, for instance, and multiple other posts around the web that Google found. Mirrors are not functional in the currently released Silver edition.

That's a drag!

Also - can I expand one drive to a mirror with reformatting? If not I'm ending up in a chicken and egg scenario.

You mean without reformatting? You can add a mirror to a single drive without reformatting, yes.

OreoCookie · Feb 2, 2012, 12:51 PM

Originally Posted by besson3c

That's a drag!

Yes, but I prefer that they activate functionality bit by bit rather than make us public beta testers who have paid for the privilege!

besson3c · Feb 2, 2012, 01:03 PM

To expand upon the reformatting bit, the only time you have to reformat (AFAIK) is when you wish to change the makeup of a RAIDZ pool.

besson3c · Feb 2, 2012, 01:03 PM

Originally Posted by OreoCookie

Yes, but I prefer that they activate functionality bit by bit rather than make us public beta testers who have paid for the privilege!

How is your testing going so far? What are your overall impressions?

OreoCookie · Feb 2, 2012, 01:32 PM

Originally Posted by besson3c

How is your testing going so far? What are your overall impressions?

So far, everything just works. Which, I think, is a good thing if you're using a new file system. I'm currently making plans to migrate my machine to a ssd + hdd setup, so then, I expect to reap the benefits of a faster file system (I'll format the hdd in ZFS, the SSD has to stay on HFS+ since OS X cannot boot off of ZFS).

besson3c · 02:31 PM

Thanks for the report Oreo, please keep these coming!

I'm undecided as to what to do.

I've been mulling over getting an SSD for quite some time, but I'm not sure I can make do with 80 gigs of space or whatever, and I'm not sure I'm comfortable with doing the SSD for the OS + ZFS for my data like you guys are doing. I'm fully comfortable with ZFS itself in terms of reliability, but I'm not sure about how this ZEVO implementation impacts this. Upon realizing that mirroring isn't supported, I'm thinking that perhaps there is more complexity to the implementation than I thought originally.

Further complicating this is the knowledge that I can always trust in my backups, but I'd really like to hear more from people that ZFS send/recv has been working to another machine over the network (I'm not interested in keeping a USB drive plugged into this laptop). I like being able to not only have a copy of my data, but also to be able to backpedal, so I don't want to use rsync.

Also further complicating this is my entertaining building a NAS and going with a double SSD mirror on the laptop (it doesn't make sense to mirror an SSD with a SATA drive), but this will get expensive having to not only rely on the NAS, but also to invest in two SSDs.

I might just end up waiting, although I don't really know what for... I'm just not really happy with the current options. What would make me orgasmic is a laptop with two ZFS SATA mirrors, plus a small pair of SSDs for caching so I can reap the benefits of SSD performance.

mduell · Feb 2, 2012, 04:09 PM

Originally Posted by P

So my read of this is that if I do use ZFS on a single slice, it will kill the disk cache. Correct? That basically means that I need to use L2ARC/ZIL or performance is likely to go down.

The disk cache is only disabled for writes (not reads) and only disabled on the drives that are partitioned. So if you have a whole HDD for storage and a partitioned SSD for L2ARC/ZIL, you get native read and write caching on the HDD and native read caching on the SSD.

Originally Posted by P

So the ZFS thing to do then would be to set up one pool on the internal HDD with a mirror on the external HDD and then set up regular snapshots. This would store the snapshots twice, but they're more efficient than TM anyway).

No. You'd set up a pool of the internal drive, take snapshots there, and then zfs send those snapshots (well, snapshot initially and snapshot diffs later) to the external.

Originally Posted by besson3c

This sounds like a good plan to me! Another piece of information that might be relevant to you is that you cannot grow your pools by adding new disks to them if they are RAIDZ, while you can do this with mirrors of any configuration. So, if you'd ever want to take those disks and move them elsewhere you'll be able to do a ZFS export, transplant your two disks, ZFS import, and you'll be back up and running without having to reconstruct your array.

This may be completely and utterly irrelevant to you, but I'm just saying this in case you might anticipate wanting to move to a NAS or some system with more drive bays while keeping your existing data and drives. In ZFS the holy grail is more drive bays, not single drives with a ton of capacity, so you can keep your 1TB drives for as long as they can be purchased and just keeping buying more and more rather than having to spend more on higher capacity drives. At some point in the future you can also up all of these drives to, say, 2TB drives as mduell has described without skipping a beat.

Again, sorry for the dump of extraneous info, but this might be useful to some who might be thinking of a growth strategy. You have to be a little calculated about this, because unfortunately you can't grow the capacity of a pool just by adding a single drive.

I think you've misunderstood. You cannot grow a RAIDZ vdev by adding drives to it, but you can always add more vdevs (single drives or mirrors or RAIDZs) to a pool. If you have a RAIDZ as the only vdev in a pool, you could add a single drive vdev or a mirror vdev to the pool; it wouldn't make a lot of sense in most cases*, but it is possible.

* It could make sense if you had a pool with a single RAIDZ vdev, only 2 more physical bays available, and you wanted to expand the pool. You could add 2 drives and attach them to the pool as a mirror; this expands the available pool storage and keeps everything in the pool recoverable from a drive loss.

Originally Posted by besson3c

One of the more popular drive configs is mirrored RAIDZ sets. A RAIDZ config needs a minimum of 3 drives, so a lot of people create two 3 drive RAIDZ sets and mirror them together, allowing you to grow the size of this pool by adding new drives in groups of 3. You can also skip RAIDZ and just grow your array by adding mirrors in groups of two.

This would be a rather wasteful/paranoid scheme, using 6 disks to achieve the capacity of 2.

Originally Posted by P

Also - can I expand one drive to a mirror with reformatting? If not I'm ending up in a chicken and egg scenario.

Yes, you can arbitrarily add and remove mirrors, as we did for the disk migration I mentioned.

Originally Posted by besson3c

Further complicating this is the knowledge that I can always trust in my backups, but I'd really like to hear more from people that ZFS send/recv has been working to another machine over the network (I'm not interested in keeping a USB drive plugged into this laptop). I like being able to not only have a copy of my data, but also to be able to backpedal, so I don't want to use rsync.

What do you want to know? We zfs send about 30GB/day from database servers to nearby backup servers and 10GB/day to off-site backup servers.

Originally Posted by besson3c

Also further complicating this is my entertaining building a NAS and going with a double SSD mirror on the laptop (it doesn't make sense to mirror an SSD with a SATA drive), but this will get expensive having to not only rely on the NAS, but also to invest in two SSDs.

Mirrored SSDs is weird, do you really need high availability like that? I'd say use an SSD as your primary and then a HDD as a local backup drive to send snapshots to for cost reasons. Unless you really need the high availability, a $500 SSD and $100 HDD is more space than two $300 SSDs.

P · Feb 2, 2012, 04:53 PM

Originally Posted by mduell

No. You'd set up a pool of the internal drive, take snapshots there, and then zfs send those snapshots (well, snapshot initially and snapshot diffs later) to the external.

OK, but then I'd need:

a) something that sends this automagically
b) something that thins those snapshots eventually

Because I don't expect that those features exist already in some nice app?

besson3c · Feb 2, 2012, 05:15 PM

Originally Posted by mduell

I think you've misunderstood. You cannot grow a RAIDZ vdev by adding drives to it, but you can always add more vdevs (single drives or mirrors or RAIDZs) to a pool. If you have a RAIDZ as the only vdev in a pool, you could add a single drive vdev or a mirror vdev to the pool; it wouldn't make a lot of sense in most cases*, but it is possible.

* It could make sense if you had a pool with a single RAIDZ vdev, only 2 more physical bays available, and you wanted to expand the pool. You could add 2 drives and attach them to the pool as a mirror; this expands the available pool storage and keeps everything in the pool recoverable from a drive loss.

I understand that you can have idle drives in the same pool set aside as spares, but I don't think you're right here, unless I'm misunderstanding what you've written here... The configuration of that RAIDZ device is immutable. It cannot change without redefining that device. You can swap out drives and grow the capacity that way (as long as all drives are the same size), but you can't make a 4 drive RAIDZ array a 5, 6, or x drive device, no?

This would be a rather wasteful/paranoid scheme, using 6 disks to achieve the capacity of 2.

What I've described is RAID 10, right? Striped RAIDZ sets? Or did I describe Mirrored RAIDZ sets?

What do you want to know? We zfs send about 30GB/day from database servers to nearby backup servers and 10GB/day to off-site backup servers.

Yeah, I'm cool with ZFS send/recv too (although I don't use it to the extent you do), but what I'm unclear of is how this works with ZEVO. I'm really confused as to why certain basic features are not available in this ZEVO product - I figured that it was basically a port of ZFS and with it you'd get all of the stuff that comes with ZFS and its CLI tools. If we are to take the idea that it doesn't do mirroring at face value, is it logical to assume that the ZEVO stuff is some weird bastardized implementation of ZFS?

Mirrored SSDs is weird, do you really need high availability like that? I'd say use an SSD as your primary and then a HDD as a local backup drive to send snapshots to for cost reasons. Unless you really need the high availability, a $500 SSD and $100 HDD is more space than two $300 SSDs.

I don't need that high availability, but it would be nice to be able to count on self healing so that backups would be for additional integrity, not for the primary source of integrity.

BLAZE_MkIV · Feb 2, 2012, 05:29 PM

The nice thing about pool / array / dev layering is you have arrays for physical disk fault tolerance and you can keep adding more arrays to the pool for more capacity, as long as you have enough drive bays. Just because you have 16 drives doesn't mean you need to make 1 array, you can make 4 and add them to the pool. There a whole subject matter on array size vs drive failure rate etc.

mduell · 06:58 PM

Originally Posted by P

OK, but then I'd need:

a) something that sends this automagically
b) something that thins those snapshots eventually

Because I don't expect that those features exist already in some nice app?

Yes, you would and as far as I know they don't. We implemented those in about 100 lines of script. It's not ideal for you but not terribly difficult.

Originally Posted by besson3c

I understand that you can have idle drives in the same pool set aside as spares, but I don't think you're right here, unless I'm misunderstanding what you've written here... The configuration of that RAIDZ device is immutable. It cannot change without redefining that device. You can swap out drives and grow the capacity that way (as long as all drives are the same size), but you can't make a 4 drive RAIDZ array a 5, 6, or x drive device, no?

Correct, you cannot change the number of drives in a RAIDZ vdev (not counting adding/deleting mirrors of existing drives). You said "you cannot grow your pools by adding new disks" and that is incorrect, you can add vdevs (single disk, mirrored disk, RAIDZn) to a pool that contains a RAIDZ vdev.

Say I have a pool of 1TB drives as follows:

Code:
	NAME        STATE     READ WRITE CKSUM
	tank        ONLINE       0     0     0
	  raidz2-0  ONLINE       0     0     0
	    da8     ONLINE       0     0     0
	    da20    ONLINE       0     0     0
	    da12    ONLINE       0     0     0
	    da16    ONLINE       0     0     0
	    da4     ONLINE       0     0     0
	    da9     ONLINE       0     0     0
	    da21    ONLINE       0     0     0

The pool has 5TB capacity. I can add another RAIDZ to the pool with a different number of drives:

Code:
	NAME        STATE     READ WRITE CKSUM
	tank        ONLINE       0     0     0
	  raidz2-0  ONLINE       0     0     0
	    da8     ONLINE       0     0     0
	    da20    ONLINE       0     0     0
	    da12    ONLINE       0     0     0
	    da16    ONLINE       0     0     0
	    da4     ONLINE       0     0     0
	    da9     ONLINE       0     0     0
	    da21    ONLINE       0     0     0
	  raidz-1   ONLINE       0     0     0
	    da13    ONLINE       0     0     0
	    da17    ONLINE       0     0     0
	    da5     ONLINE       0     0     0
	    da2     ONLINE       0     0     0

My pool capacity is now 8TB (5TB+3TB). I can also add a mirror to the pool:

Code:
	NAME        STATE     READ WRITE CKSUM
	tank        ONLINE       0     0     0
	  raidz2-0  ONLINE       0     0     0
	    da8     ONLINE       0     0     0
	    da20    ONLINE       0     0     0
	    da12    ONLINE       0     0     0
	    da16    ONLINE       0     0     0
	    da4     ONLINE       0     0     0
	    da9     ONLINE       0     0     0
	    da21    ONLINE       0     0     0
	  raidz-1   ONLINE       0     0     0
	    da13    ONLINE       0     0     0
	    da17    ONLINE       0     0     0
	    da5     ONLINE       0     0     0
	    da2     ONLINE       0     0     0
	  mirror-0  ONLINE       0     0     0
	    da0     ONLINE       0     0     0
	    da1     ONLINE       0     0     0

My pool capacity is now 9TB (5TB+3TB+1TB). I can also add a single drive vdev to the pool (for storage, not as a spare), but this comment is long enough already.

Originally Posted by besson3c

What I've described is RAID 10, right? Striped RAIDZ sets? Or did I describe Mirrored RAIDZ sets?

You used the word mirrored several times and never mentioned striping; you described a RAID51 (mirrors of RAIDZs) scheme. The most popular scheme for large ZFS pools is a stripe (as all vdevs in a pool are striped) of RAIDZs.

Originally Posted by besson3c

I don't need that high availability, but it would be nice to be able to count on self healing so that backups would be for additional integrity, not for the primary source of integrity.

Fair enough. I'd mirror 600GB SSDs if money were no object.

besson3c · Feb 2, 2012, 07:00 PM

Originally Posted by mduell

Correct, you cannot change the number of drives in a RAIDZ vdev (not counting adding/deleting mirrors of existing drives). You said "you cannot grow your pools by adding new disks" and that is incorrect, you can add vdevs (single disk, mirrored disk, RAIDZn) to a pool that contains a RAIDZ vdev.

Cool.. Just me being sloppy with language then. Pool = place where devices live, a container for your filesystems, device/vdev = actual RAID array? Whatever the latter should be called, I was erroneously using the word "pool" in the latter context.

You used the word mirrored several times and never mentioned striping; you described a RAID51 (mirrors of RAIDZs) scheme. The most popular scheme for large ZFS pools is a stripe (as all vdevs in a pool are striped) of RAIDZs.

Thank you, I stand corrected... Meant to say stripe, not mirror.

besson3c · Feb 2, 2012, 07:08 PM

Originally Posted by BLAZE_MkIV

The nice thing about pool / array / dev layering is you have arrays for physical disk fault tolerance and you can keep adding more arrays to the pool for more capacity, as long as you have enough drive bays

Yeah, but like mduell and I were discussing, this is not so for RAIDZ arrays.

Just because you have 16 drives doesn't mean you need to make 1 array, you can make 4 and add them to the pool. There a whole subject matter on array size vs drive failure rate etc.

A valid point, but you can't share capacity between these arrays. This is of concern to those who really want to maximize capacity available to whatever machines will be accessing these filesystems.

BLAZE_MkIV · Feb 2, 2012, 08:43 PM

I'm confused. You can add multiple arrays to a pool. The pool will "JBOD" them for you.
edit: like he pointed out in his example.
They're trying to make it so you don't need to disk swap your way to a larger array. I though there's a way to make it move all the data off one of the devices in the pool so you can remove it.

besson3c · Feb 2, 2012, 08:49 PM

Originally Posted by BLAZE_MkIV

I'm confused. You can add multiple arrays to a pool. The pool will "JBOD" them for you.

Multiple arrays, but if you set aside 4 disks for a RAIDZ device, for example, you can't take some of those disks away to use somewhere else or add disks to this array, it is immutable. Mirrored sets, however, can be dismantled and expanded.

BLAZE_MkIV · Feb 2, 2012, 10:41 PM

Yeah but you're size is the size of all the pools in the array specifically because of this. Same problem with traditional raid 5 arrays.

CharlesS · Feb 2, 2012, 11:17 PM

Originally Posted by P

So the ZFS thing to do then would be to set up one pool on the internal HDD with a mirror on the external HDD and then set up regular snapshots.

Is that doable with the internal HDD being formatted as HFS+, as it currently must be in order to be OS X-bootable?

P · Feb 3, 2012, 06:06 AM

Originally Posted by CharlesS

Is that doable with the internal HDD being formatted as HFS+, as it currently must be in order to be OS X-bootable?

I'm booting off an internal SSD (in the optical bay), with a lot of folders on the HDD symlinked to their correct position on the SSD boot drive. The HDD might go ZFS - the SSD stays on HFS+ and remains the root.

besson3c · Feb 3, 2012, 09:20 AM

Originally Posted by BLAZE_MkIV

Yeah but you're size is the size of all the pools in the array specifically because of this. Same problem with traditional raid 5 arrays.

But the capacity of the individual arrays do not combine together. IOW, the capacity of disks that are not a member of the RAIDZ vdev are off-limits.

mduell · Feb 3, 2012, 09:43 AM

Originally Posted by besson3c

Cool.. Just me being sloppy with language then. Pool = place where devices live, a container for your filesystems, device/vdev = actual RAID array? Whatever the latter should be called, I was erroneously using the word "pool" in the latter context.

The pool is the largest unit of storage:
- A pool is comprised of one or more vdevs combined (striped) together (a vdev is comprised of one or more disks)
- A pool is segmented into one or more datasets (mostly for enabling/disabling specific features like quotas, compression, and deduplication)

I'd prefer if we don't use the word array since it's not often used in the context of ZFS and confusing with legacy storage implementations.

Originally Posted by besson3c

But the capacity of the individual arrays do not combine together. IOW, the capacity of disks that are not a member of the RAIDZ vdev are off-limits.

Incorrect, the capacity of individual vdevs ("arrays") do combine together in the pool and data is striped across them. The capacity of disks that are members vdevs are availabel in the pool, regardless of which type of vdev they are. The presence of a RAIDZ vdev in a pool does not prevent you from adding non-RAIDZ (or RAIDZs of a different level or number of drives) vdevs to the pool and having the storage be available/usable. See my example pool above that grew from 5 to 8 to 9TB using heterogeneous vdevs.

besson3c · Feb 3, 2012, 10:05 AM

Originally Posted by mduell

Incorrect, the capacity of individual vdevs ("arrays") do combine together in the pool and data is striped across them. The capacity of disks that are members vdevs are availabel in the pool, regardless of which type of vdev they are. The presence of a RAIDZ vdev in a pool does not prevent you from adding non-RAIDZ (or RAIDZs of a different level or number of drives) vdevs to the pool and having the storage be available/usable. See my example pool above that grew from 5 to 8 to 9TB using heterogeneous vdevs.

So you can grow the pool, but not the individual RAIDZ vdevs once they've been defined. How does this differ from what I've said? I get that you can add stuff to the pool that will co-exist with that RAIDZ vdev, but my point is that that RAIDZ vdev cannot reap the benefits of those disks unless you replace members of the RAIDZ vdev with these disks, or you decide to reconstruct that vdev.

I just think this is a very important thing to understand, because a lot of people seem to be quick to create RAIDZ vdevs since they offer many virtues, while not thinking about a growth strategy. For instance, if you have 6 drive bays and a RAIDZ vdev comprised of 6 disks in those 6 drive bays, your hands are pretty tied in terms of flexibility. It is perhaps in part or wholly because of this that it is recommended to either build that 6 disk array as 3 mirrored pairs, or a striped pair of 3 disk RAIDz set.

BLAZE_MkIV · Feb 3, 2012, 11:04 AM

If you've only got 6 drive bays in your box just buy a new box, copy all the data across, and throw away the old one.

besson3c · Feb 3, 2012, 11:16 AM

Originally Posted by BLAZE_MkIV

If you've only got 6 drive bays in your box just buy a new box, copy all the data across, and throw away the old one.

Or, if the total space needed could be accommodated by the combined capacity of two large drives, you could in theory dismantle this setup without having to acquire a new box (and without relying on external drives of some sort).

Also noteworthy is that you'd get better performance with either of the non 6 drive RAIDZ configs.

My point is simply to plan this carefully and don't just assume that you can add capacity to an individual RAIDZ vdev.

mduell · Feb 3, 2012, 12:57 PM

Originally Posted by besson3c

So you can grow the pool, but not the individual RAIDZ vdevs once they've been defined. How does this differ from what I've said? I get that you can add stuff to the pool that will co-exist with that RAIDZ vdev, but my point is that that RAIDZ vdev cannot reap the benefits of those disks unless you replace members of the RAIDZ vdev with these disks, or you decide to reconstruct that vdev.

I just think this is a very important thing to understand, because a lot of people seem to be quick to create RAIDZ vdevs since they offer many virtues, while not thinking about a growth strategy. For instance, if you have 6 drive bays and a RAIDZ vdev comprised of 6 disks in those 6 drive bays, your hands are pretty tied in terms of flexibility. It is perhaps in part or wholly because of this that it is recommended to either build that 6 disk array as 3 mirrored pairs, or a striped pair of 3 disk RAIDz set.

You said:
"But the capacity of the individual arrays do not combine together." - they do, the "arrays" (vdevs) combine together in the pool
"IOW, the capacity of disks that are not a member of the RAIDZ vdev are off-limits." - the capacity of disks that are not a member of a RAIDZ vdev are available/usable in the pool

But I'm pretty sure you get it now.

You're right, using all available bays in a single RAIDZ offers capacity upgrades only by replacing all drives. This is still no worse than any other RAID scheme today (again with the caveat of controllers that cost less than my house).

besson3c · Feb 3, 2012, 01:02 PM

Originally Posted by mduell

You're right, using all available bays in a single RAIDZ offers capacity upgrades only by replacing all drives. This is still no worse than any other RAID scheme today (again with the caveat of controllers that cost less than my house).

Yup!

Maybe I'm just dumb, but I think my insistence on trying to be specific about the RAIDZ caveats came from my intro to ZFS and my misconception that any sort of vdev can be modified without caveats. This burned me, so I'm just trying to help prevent this from happening with others.

This is moot now since RAIDZ is not yet supported with this ZEVO thing (why, I'm not sure), but perhaps this will become relevant to Mac Pro or Hackintosh users or something at some point in the future.

P · Feb 6, 2012, 09:25 AM

Just a few followup questions, if anyone happens to know:

If I reformat both the backup drive and the main HDD to ZFS, could I still use Time Machine for backups? I realize that this will not use snapshots, so it will be complete file copies instead of block copies, but would it work?

About the lack of write caches...I'm assuming that this will not affect any other filesystem on the same drive? E.g. in my case, the HFS+ drive would still get the benefit of a write cache, right? How bad is this effect if I have a ZIL/L2ARC drive anyway?

mduell · Feb 6, 2012, 11:39 AM

Originally Posted by P

If I reformat both the backup drive and the main HDD to ZFS, could I still use Time Machine for backups? I realize that this will not use snapshots, so it will be complete file copies instead of block copies, but would it work?

My big concern here is how it will handle the directory hard links that TM uses; I don't think ZFS supports them.

Originally Posted by P

About the lack of write caches...I'm assuming that this will not affect any other filesystem on the same drive? E.g. in my case, the HFS+ drive would still get the benefit of a write cache, right? How bad is this effect if I have a ZIL/L2ARC drive anyway?

Native write caching is on a per-drive basis, so it impacts all file systems on the drive. The impact depends on your usage pattern, the biggest impact being on small random writes. It's possible whatever mechanism normally enables/disables write caching will leave it enabled.