zfs v15 and newer

C

chrcol

Is there a plan for updating zfs in later minor versions of freebsd, v15 includes quotas which is a very basic and much used function of filesystems, and there is more fixes in newer updates.

Is it expected to get newer zfs in newer 8.x versions of freebsd? or will it be updated in 9 and beyond?
 
FreeBSD 8-STABLE includes ZFSv14 which brings it to parity with Solaris 10.

You'd have to ask on the freebsd-fs mailing list if anyone is working on getting newer versions pulled into FreeBSD -CURRENT.
 
chrcol said:
not user accounting quotas, so quota per user.
Click to expand...

It can still be set, using a layout that work. This is what I have:

Code: 
/tank
  /user
    /username
      /home
      /mail
      /www

I set the quota on /tank/user/username path of the tank (as killasmurf86) and the three subfolders gets mounted in their proper location (ie /tank/user/username/home to /usr/home/username) and so on.
 
phoenix said:
FreeBSD 8-STABLE includes ZFSv14 which brings it to parity with Solaris 10.

You'd have to ask on the freebsd-fs mailing list if anyone is working on getting newer versions pulled into FreeBSD -CURRENT.
Click to expand...

Actually, Solaris 10 update 8 (10/09) has ZFS version 15. I'm not complaining, just pointing it out...

Code: 
$ zpool get version dpool
NAME   PROPERTY  VALUE    SOURCE
dpool  version   15       default

$ cat /etc/release
                       Solaris 10 10/09 s10x_u8wos_08a X86
           Copyright 2009 Sun Microsystems, Inc.  All Rights Reserved.
                        Use is subject to license terms.
                           Assembled 16 September 2009
 
dmdx86 said:
Actually, Solaris 10 update 8 (10/09) has ZFS version 15. I'm not complaining, just pointing it out...

Code: 
$ zpool get version dpool
NAME   PROPERTY  VALUE    SOURCE
dpool  version   15       default

$ cat /etc/release
                       Solaris 10 10/09 s10x_u8wos_08a X86
           Copyright 2009 Sun Microsystems, Inc.  All Rights Reserved.
                        Use is subject to license terms.
                           Assembled 16 September 2009
Click to expand...

Sure ... just when we hit parity ... they go and update. :)
 
There is very interesting feature in zpool v20
http://hub.opensolaris.org/bin/view/Community+Group+zfs/20
that is described here:
http://arc.opensolaris.org/caselog/PSARC/2009/571/20091019_jeffrey.bonwick

Deduplication is a feature of modern storage platforms by which
varying mechanisms are employed to reduce the amount of total data
stored by eliminating and sharing common components. We are adding
deduplication to ZFS in order to further enable market penetration
with ZFS and the Sun Storage 7000 series.
Click to expand...

It comes handy in specific environments like backup servers or file storages. Just curious... will it be ported to FreeBSD?
 
>Just curious... will it be ported to FreeBSD?

I think most of it will be ported, if it is at least stable in Solaris. OpenSolaris to Solaris is like Fedora to Red Hat.
 
SaveTheRbtz said:
There is very interesting feature in zpool v20
http://hub.opensolaris.org/bin/view/Community+Group+zfs/20
that is described here:
http://arc.opensolaris.org/caselog/PSARC/2009/571/20091019_jeffrey.bonwick



It comes handy in specific environments like backup servers or file storages. Just curious... will it be ported to FreeBSD?
Click to expand...

Backup and storing of virtual servers are the big applications of deduplication.
But dedup is a tricky businiss and it seems that the current implementation in zfs has little effect with backup. I've seen a discussion of this topic somewhere (sorry, don't have the link anymore) where it was shown that data from major backup applications had practically no benefit from zfs dedup (three consecutive full backups with EMC Networker gave a dedup factor of 1.03 !)

Apparently zfs use a simple block-by-block comparison of data which is useless in the context of backup.

There's a lot of things to like about zfs, but when it comes to storing large amounts of backup zfs won't help you anytime soon.
 
Oh, yes, it does.

Our backups server using gzip-9 compression has a 1.61 compression ration.

We have a test box setup using Linux + FUSE + ZFS to see how well dedupe will work with our setup. So far, with less than 1/3 of the data copied over, we have a combined compression ration over 3.0 (gzip-9 + dedupe). Dedupe most definitely helps with backups.

The block-level dedupe is better in a lot of ways than file-level dedupe. We have some data blocks that are referenced 70,000 times (from different files), which means we save a tonne of space. With large binary files (like what "standard" backup software creates), block-level dedupe is the only one that provides any benefit.

Once ZFS dedupe support is enabled in FreeBSD, we'll be able to cut our storage needs in half, or store more daily backups in the space we have.
 
I follow the lists for ZFS-Discuss and there are a lot of people using dedup who have had amazing results with it. I think it just depends on your data set.
 
phoenix said:
Oh, yes, it does.

Our backups server using gzip-9 compression has a 1.61 compression ration.

We have a test box setup using Linux + FUSE + ZFS to see how well dedupe will work with our setup. So far, with less than 1/3 of the data copied over, we have a combined compression ration over 3.0 (gzip-9 + dedupe). Dedupe most definitely helps with backups.

The block-level dedupe is better in a lot of ways than file-level dedupe. We have some data blocks that are referenced 70,000 times (from different files), which means we save a tonne of space. With large binary files (like what "standard" backup software creates), block-level dedupe is the only one that provides any benefit.

Once ZFS dedupe support is enabled in FreeBSD, we'll be able to cut our storage needs in half, or store more daily backups in the space we have.
Click to expand...

I'm not convinced. Tests with major backup applications like Networker and Netbackup show that zfs dedup has no effect.

My source for this is a conversation taking place on the Networker mailing list a few days ago. One posting from Sun engineer Attilla Mester pretty much sums it up.
Content-type: text/plain; CHARSET=US-ASCII; format=flowed
References: <4B9D3FF9.40109@aristo.tau.ac.il>
<3BEB5F9B6605A140847DEEEDF7439C5D03D2A4E5@CORPUSMX50A.corp.emc.com>
User-Agent: Thunderbird 2.0.0.24 (Macintosh/20100228)
Message-ID: <4BA27FDA.40605@sun.com>
Date: Thu, 18 Mar 2010 20:32:42 +0100
Reply-To: EMC NetWorker discussion <NETWORKER@LISTSERV.TEMPLE.EDU>,
Attila.Mester@SUN.COM
Sender: EMC NetWorker discussion <NETWORKER@LISTSERV.TEMPLE.EDU>
From: Attila Mester <Attila.Mester@SUN.COM>
Subject: Re: ZFS deduplication.
Comments: To: lemons_terry@EMC.COM
In-Reply-To: <3BEB5F9B6605A140847DEEEDF7439C5D03D2A4E5@CORPUSMX50A.corp.emc.com>

I have recently made similar tests to see what dedup ratios I can get
when writing to dedup enabled ZFS filesystems as a B2D target.
I have discovered the same behavior, e.g. NetWorker saveset streams do
not really get deduplicated. Changing the underlying ZFS dedup blocksize
doesn't have any positiv effect, even if I go down to 8k blocksize.
The only explanation I can think of is, as Yaron already pointed out,
block boundaries are aligned differently because of the different
meta-data which is part of the savesets.
It seems, at current point of the code implementation the dedup can not
deal with different block bounderies and as such, not effectively usable
for deduplicating such streams.
BTW I experienced the same thing when using NetBackup as the backup application.

regards -attila

********************************************************************
Attila Mester 5 Digit Sun internal: x62534
Data Protection Architect Tel: (+49 89) 46 008 2534
Sun Microsystems GmbH Fax: (+49 89) 46 008 2583
Sonnenallee 1 Mobil: +49 172 812 5947
85551 Heimstetten / Germany mail: attila.mester@sun.com
********************************************************************

Terry Lemons schrieb:
> Hi Yaron
>
> I know that NetWorker has a default block size for each of its output devices. This default block size can be overridden; details on this are in the NetWorker Administration Guide.
>
> Does ZFS have a specific block size that it deduplicates? If so, could it be that the NetWorker default block size for the AFTD device is not the same as, or a multiple of, the ZFS default block size?
>
> tl
>
> -----Original Message-----
> From: EMC NetWorker discussion [mailto:NETWORKER@LISTSERV.TEMPLE.EDU] On Behalf Of Yaron Zabary
> Sent: Sunday, March 14, 2010 3:59 PM
> To: NETWORKER@LISTSERV.TEMPLE.EDU
> Subject: [Networker] ZFS deduplication.
>
>
> A few days ago I read a post to EMC's Networker forum by Nicholas
> Bone (https://community.emc.com/thread/99839?tstart=0). He reported a
> test he performed with AFTD which was running on top of ZFS with dedup.
> Unfortunately, he wasn't able to get any reasonable dedup ratios (1.03
> for three full savesets of the the same file system). My conclusion was
> that Networker does not align files at block level, which confuses the
> ZFS dedup code. Is anyone familiar with some flag or any configuration
> option which will convince save or AFTD to do the right thing so that
> ZFS will be able to find identical blocks ?
>
Click to expand...
 
To me, that says that Networker is a brain-dead backup app. :) But, I have an aversion to any backup app that uses it's own undocumented binary archive format.

We used to use similar products, but they are more hassle than they are worth, especially since most of them require running some kind of agent on each of the systems to be backed up. We've since moved to plain Rsync and ZFS snapshots. It works so much quicker, smoother, nicer, and makes things so much simpler. Plus, our backups are fully searchable using standard CLI tools like find.

With that setup, you really see the benefit of ZFS dedupe. (Plus, we have a backup system for $10,000 CDN that works better, with more storage space, supporting more server, than the >$100,000 CDN system other districts are using.)
 
phoenix said:
To me, that says that Networker is a brain-dead backup app. :) But, I have an aversion to any backup app that uses it's own undocumented binary archive format.
Click to expand...
Results are similar with Netbackup, which is based on tar.
The fact is that zfs dedup does not not handle that type of data. You may blame that on the applications if you like:)
 
Tar is a binary archive format (although, at least it's documented). Once you stuff your data into a binary archive, dedupe of any kind will not work. Which is why we've moved away from all binary archive formats, and just store data as files.

Compressing archives is all you can do, which does it's own form of "dedupe" internally.
 
I don't think binary data is the problem here. It's more likely because of compression and/or encryption of the files. The odds that one or more compressed and/or encrypted files share the same data blocks on disk are somewhat astronomical. Dedup won't work.

If, however, the files are relatively static, maybe some blocks added in between, at the end, the beginning, dedup will definitely work.
 
as I understand it, the problem with newver ZFS versions is that it adds dependency on Python(?) for administrative commands (and maybe other tasks), which is not part of the FreeBSD base. Another problem is that those newer versions go deep into the changes in the OS internals, and require much more work to get ported to FreebSD ;-(
 
SirDice said:
I don't think binary data is the problem here. It's more likely because of compression and/or encryption of the files. The odds that one or more compressed and/or encrypted files share the same data blocks on disk are somewhat astronomical. Dedup won't work.

If, however, the files are relatively static, maybe some blocks added in between, at the end, the beginning, dedup will definitely work.
Click to expand...

Backup applications don't copy diskblocks. They read the files and produce a single stream of data. Any change to the source will introduce a shift of bytes within the backupstream.

When written back to disk, while the data may be 99% identical to a previous stream, a simple block-by-block comparison may well be unable to identify a single duplicate block.

Modern dedup solutions clearly use other tecniques than this. Compression ratios of 20-50X is quite common with this type of data in appliances from DataDomain, etc.
(And, yes those solutions cost $$)
 
Little offtopic but what are the consequences for freebsd if oracle would change the zfs/dtrace license from cddl to gpl to make it available to linux? or change it at all so it's not longer available for free.
wouldn't that mean that zfs could no longer be part of the base system?

seeing the latest changes make me wonder (solaris is no longer free but 90day trail).
 
What we have now they can't take from us. If they decide to keep future code to themselves that would suck, but nothing we can do about it.

By the looks of it, ZFS being GPL'ed will never happen. Oracle wants Solaris to be their high-end OS.

Let's hope they keep OpenSolaris cddl and uptodate, so people have an easy way to get to know Solaris.
 
danger@ said:
as I understand it, the problem with newver ZFS versions is that it adds dependency on Python(?) for administrative commands (and maybe other tasks), which is not part of the FreeBSD base. Another problem is that those newer versions go deep into the changes in the OS internals, and require much more work to get ported to FreebSD ;-(
Click to expand...

Thanks for the response, so defenitly not easy to do then.
 
You must log in or register to reply here.
Back
Top