Sent from my iPad
> On Mar 17, 2014, at 3:35 AM, Dave Cottlehuber <d...@jsonified.com> wrote:
>> On 17. März 2014 at 05:00:25, roemer (uwe.ro...@gmail.com) wrote:
>> Thanks for the detailed example!
>>> On Monday, 17 March 2014 07:34:45 UTC+11, dch wrote:
>>> I've been a happy maczfs and also zfsosx user for several years now.
>>> zfs send is a very easy way to do a very trustable
>>> backup, once you get past the first potentially large transfers.
>>> Can this happen bi-directiona? Or is it only applicable for creating
>> 'read-only' replicas of a master filesystem onto some clients?
>> I mean, what happens once you cloned one file system, sent it to your
>> laptop, then edit on both the laptop and your ZFS server?
> Then you’re screwed :-). It’s not duplicity or some other low-level sync
> tool. I find it works best when you have a known master that you’re working
> Slightly OT, but in FreeBSD with HAST you can do some gonzo crazy stuff:
>>> All my source code & work lives in a zfs case sensitive noatime
>>> copies=2 filesystem, and I replicate that regularly to my other boxes
>>> as required.
>>> How does a 'copies=2' filesystem play together with a 'RAIDZ1' (or even
>> RAIDZ2) pool?
>> RAIDZ would have all data stored redundantly already, so would 'copies=2'
>> not end up in quadrupling the storage requirement if used on a raidz pool?
> Yes, but in this case, the laptop isn’t redundant, and my data is precious.
> IIRC the whole repos dataset, even with history, is < 40 Gb, so that’s
> reasonable IMO.
>>> For most customer projects I will have 3 or more VMs running different
>>> configs or operating systems under VMWare Fusion. These each live in
>>> their own zfs filesystem, compressed lz4 noatime case sensitive. I
>>> snapshot these after creation using vagrant install, again after
>>> config, and the changes are replicated using zfs snapshots again to
>>> the other OSX system, and also to the remote FreeBSD box.
>>> I can see that zfs is really good for handling multiple virtual machines.
> Yup, zfs rollback for testing deployments or upgrades is simply bliss.
>> In summary, I'm more than happy with the performance once I used
>>> ashift=12 and moved past 8GB ram. Datasets once you get used to them
>>> are extraordinarily useful -- snapshot your config just before a
>>> critical upgrade.
>>> I start seeing the potential in snapshots. In fact, I just realised that I
>> do manual
>> 'snapshots' on some of my repeating projects already for quite some time
>> with annual
>> clones of the previous directory structure. So ZFS snapshots would be a
>> natural fit here.
>> But regarding the memory consumption:
>> What makes ZFS so memory hungry in your case?
> I don’t think it’s very hungry actually. 4GB (under the old MacZFS 74.1)
> simply wasn’t enough and I’d get crashes. With 8GB that went away. Bearing
> in mind with 16GB RAM I can run a web browser (oink at least 1GB), a 20GB VM
> that’s been compressed into a 10GB RAMdisk, +1 GB RAM for the VM, that seems
> pretty reasonable. That would leave 4GB for ZFS and the normal OSX baseline
> stuff roughly.
> I’m happy to report back with RAM usage if somebody tells me what z*
> incantation is needed.
>> Do you use deduplication?
> Never. But I do use cloned datasets a fair bit, which probably helps the
> situation a bit.
> The 2nd law of ZFS is not to use deduplication, even if you think you need it.
> IIRC the rough numbers are 1GB RAM / TB storage, and I’d want ECC RAM for
> BTW pretty sure the 1st law of ZFS is not to trust USB devices with your data.
> Dave Cottlehuber
> Sent from my PDP11
> You received this message because you are subscribed to the Google Groups
> "zfs-macos" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to zfs-macos+unsubscr...@googlegroups.com.
> For more options, visit https://groups.google.com/d/optout.
You received this message because you are subscribed to the Google Groups
To unsubscribe from this group and stop receiving emails from it, send an email
For more options, visit https://groups.google.com/d/optout.