On Wed, Jul 17, 2013 at 12:17:18PM +1000, Tim Connors wrote:
On Tue, 16 Jul 2013, Craig Sanders wrote:
On Mon, Jul 15, 2013 at 03:33:09PM +1000, Tim Connors wrote:
I find zfs obtuse, awkward, inflexible, prone to failure and unreliable.
you must be using a different zfs than the one i'm using because that description is the exact opposite in every respect of my experience with zfs.
I've got one for you; just came in on the mailing list (someone got stale mounts when their kernel nfs server restarted):
ZFS and the NFS kernel server are not that tightly integrated.
yep, that's a known issue - the integration with NFS and CIFS was designed for solaris, and it's a low-priority issue to get it as tightly integrated for linux. it also doesn't qualify as either "prone to failure" or "unreliable" personally, i prefer defining NFS & CIFS exports in /etc/exports and smb.conf anyway. if i wanted to make use of the zfs attributes, it wouldn't be at all difficult to write a script to generate the appropriate config fragments for samba and exports. i'd start with a loop like this: for fs in $(zfs get sharesmb,sharenfs -t filesystem) ; do [...] done i've already got code to generate smb.conf stanzas for websites in my vhosting system (so that web sites can be shared to appropriate users on the LAN or via VPN) - it's trivial. and generating /etc/exports is even easier. BTW, speaking of samba, zfs snapshots also work nicely with shadow copy if you're backing up windows PCs. http://forums.freebsd.org/showthread.php?t=32282
Even then, for it to be worthwhile, when you have 800TB of VMs deployed, you can't easily dedup that (although from memory, a TB of RAM only costs about $100K).
no, de-duping would not be practical at that scale.
For any VMs I've ever seen, the identical shared data isn't all that much (our templates are 40GB in size) compared to the half TB deployed on average per VM. Hardly seems worth all the pain.
your usage obviously can't make use of de-duping - but for lots of virtualisation scenarios (e.g. web-hosting with lots of little web-servers) it can make sense.
it's also useful on backup servers where you end up with dozens or hundreds of copies of the same files (esp. if you're backing up entire systems, including OS)
On my home backup server, the backup software dedups at the file level (but shared between VMs - achieved by hardlinking all files detected to be the same, comparing actual content rather than hash collisions). It does a very good job according to its own stats.
yeah, well, i hate backuppc - every time i've tried to use it, it's been a disaster. rsync/zfs send and snapshots work far better for me. somebody, might have been you, mentioned in this thread that rsync is a worst-case load for zfs....not in my experience. but the link farms in backuppc absolutely kill performance on every filesystem i've tried it on, including zfs.
I acknowledge that there are some uninteresting systems out there that are massively duplicated SOEs with bugger-all storage. Might fit that pattern. And yet I believe our VDI appliances that they're trying to roll out at work *still* won't be backed by ZFS with dedup.
i agree - there are only very limited circumstances where de-duping is worthwhile. in most cases, it's just too expensive - the cost of ram vs disk or ssd is prohibitive. but there *are* some scenarios where it is the right solution, or at least a good solution.
i've found 16GB more than adequate to run 2 4TB zpools, [...]
Unfortunately, little Atom NASes seem to max out at 4GB.
"Don't do that then" this kind of idiotic arbitrary limitation is the main reason i prefer to build my own than to buy an appliance. not only is it usually cheaper (sometimes far cheaper - half or a third of the total cost because appliance NASes are absurd over-priced for what you get), but you get much better hardware with much better specs. and upgradability and repairitude. (i also really like that I'm the one making the design trade-off decisions when building my own, rather than accepting someone else's choices. i can design the system to suit my exact needs rather than adapt my needs to fit the capabilities of a generic appliance) for qnap and similar applicances you're looking at over $500 for 2 bay NAS - two drives, that's crap. for 5 or 6 drive bays, it's $800 - $1000. 8 bays, around $1300. and that's with no drives. Who in their right mind would pay that when you can build your own 8 or even 12 bay (or more if you use 2.5" drives) ZFS system with a great motherboard and CPU and bucketloads of ram for between $500 and $800? you can even still use an atom or fusion cpu if low-power is a requirement (but, really, with that many drives the CPU power usage isn't that big a deal, and a better CPU helps with compression) for HP microsevers and the like, i posted about that in luv-talk a few days ago, with rough costings for a slightly cheaper and significantly better AMD Fusion based system.
i tend to check and double-check potentially dangerous command lines before i hit enter, anyway.
No <up>-<up>-<enter> sudo reboots? ;P
nope, i have shutdown and reboot excluded from bash history: export HISTIGNORE='shutdown*:reboot*' having to retype shutdown commands saves me from the aaaaaaararggggghhhhhh! feeling of accidentally rebooting when i didn't mean to...i've done that too many times in the past. craig -- craig sanders <cas@taz.net.au> BOFH excuse #179: multicasts on broken packets