<div dir="ltr"><div><div><div><div>Thanks Leon,<br><br></div>Yes, interesting read; I tested with ONLY the schema files, not the L0 files, and I get dedupe of 4 as I would have expected.<br><br>The block size gave me an idea. ZFS uses 128k by default whereas SDFS is a default 4k; presumably this sort of data requires the lower size for that dedupe ratio.<br>
<br></div>I eventually managed to get a test 100Gb ZFS filesystem with 4k blocks ("zfs set recordsize=4k backup/admin", once I eventually worked that out). The copying process of the 80Gb is far far slower than either of the previous tests (I gave up after nearly 30 hours, it having only finished 30Gb; it was much slower once it hit that second 20Gb file, as I'd expect).<br>
<br></div>A "zpool list" of that then gives<br><br>NAME          SIZE  ALLOC   FREE    CAP  DEDUP  HEALTH  ALTROOT<br>backup       99.5G  31.7G  67.8G    31%  1.12x  ONLINE  -<br><br></div>So it DID make some difference, but it's so much slower and impractical that it looks like I'll stick with my initially-tested sdfs. (At least there is a .deb for it, in GoogleCode, which works well.)<br>
<br>Andrew<br><div><br></div></div><div class="gmail_extra"><br><br><div class="gmail_quote">On 23 December 2013 17:39, Leon Wright <span dir="ltr"><<a href="mailto:techman83@gmail.com" target="_blank">techman83@gmail.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div><div><div>I've been using ZFS for a while and the deduplication pretty much "Just works" from what I can tell.<br>
<br>root@kitten:/home/leon# zfs list<div class="im"><br>NAME       USED  AVAIL  REFER  MOUNTPOINT<br></div>
zfs        506G   133G    30K  /zfs<br>zfs/data   505G   133G   505G  /data<br><br>root@kitten:/home/leon# zpool list<div class="im"><br>NAME   SIZE  ALLOC   FREE    CAP  DEDUP  HEALTH  ALTROOT<br></div>zfs    496G   353G   143G    71%  1.56x  ONLINE  -<br>

<br>Filesystem            Size Used Avail Use% Mounted on<br>zfs/data              639G  506G  134G  80% /data<br><br></div>I'm using more than the disk size and have 134G free :-)<br><br></div>Though It may depend on the size of the files and the block sizes. This site had some interesting info:<br>

<br><a href="https://blogs.oracle.com/scottdickson/entry/sillyt_zfs_dedup_experiment" target="_blank">https://blogs.oracle.com/scottdickson/entry/sillyt_zfs_dedup_experiment</a><br><br></div>Leon<br></div><div class="gmail_extra">
<br clear="all">
<div>--<br>DRM 'manages access' in the same way that jail 'manages freedom.'<br><br># cat /dev/mem | strings | grep -i cats<br>Damn, my RAM is full of cats... MEOW!!</div><div><div class="h5">
<br><br><div class="gmail_quote">On Mon, Dec 23, 2013 at 5:06 PM, Andrew Furey <span dir="ltr"><<a href="mailto:andrew.furey@gmail.com" target="_blank">andrew.furey@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">

<div dir="ltr"><div><div>Looks like it does it with hard-linking identical files and relying on most of them not changing (which is what I'm already doing successfully [with scripts by hand] for other aspects of the server backup).<br>


<br>Unfortunately these 25Gb database files are GUARANTEED to change one to another (even 5 minutes apart, they'd have internal log pointers etc that would have changed; they're Informix IDS L0 backup files). Given that a difference of even 1 byte means it needs a different copy of the file...<br>


<br></div>I'm relying on the fact that while SOME of the file will have changed, MUCH of it won't at block level. I just seem to be doing it wrong for ZFS when compared to the compression opendedup obtained (which I would have expected for the data in question).<br>


<br>Further; running "zdb -S backup" to simulate the deduplication with the data, returned all the same numbers; so it looks like it thinks it IS deduping. Might the two systems use differing block sizes for comparison, or something?<span><font color="#888888"><br>


<br></font></span></div><span><font color="#888888">Andrew<br></font></span></div><div class="gmail_extra"><div><div><br><br><div class="gmail_quote">On 23 December 2013 16:25, William Kenworthy <span dir="ltr"><<a href="mailto:billk@iinet.net.au" target="_blank">billk@iinet.net.au</a>></span> wrote:<br>


<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Rather than dedupe after, is this something dirvish may be better at?<br>
<br>
<a href="http://www.dirvish.org/" target="_blank">http://www.dirvish.org/</a><br>
<br>
BillK<br>
<div><div><br>
<br>
<br>
<br>
<br>
On 23/12/13 15:59, Andrew Furey wrote:<br>
> Hi all,<br>
><br>
> I'm testing different deduplicating filesystems on Wheezy for storing<br>
> database backups (somewhat-compressed database dumps, average of about 25Gb<br>
> times 12 clients, ideally 30 days worth, so 9 terabytes raw). To test I<br>
> have a set of 4 days' worth from the same server, of 21Gb each day.<br>
><br>
> I first played with opendedup (aka sdfs) which is Java-based so loads up<br>
> the system a bit when reading and writing (not near as bad on physical as<br>
> on a VM, though). With that, the first file is the full 21Gb or near to,<br>
> while the subsequent ones are a bit smaller - one of them is down to 5.4Gb,<br>
> as reported by a simple du.<br>
><br>
> Next I'm trying ZFS, as something a bit more native would be preferred. I<br>
> have a 1.06Tb raw LVM logical volume, so I run<br>
><br>
> zpool create -O dedup=on backup /dev/VolGroup00/LogVol01<br>
><br>
> zpool list gives:<br>
><br>
> NAME     SIZE  ALLOC   FREE    CAP  DEDUP  HEALTH  ALTROOT<br>
> backup  1.05T   183K  1.05T     0%  1.00x  ONLINE  -<br>
><br>
> I then create a filesystem device under it (I've tried without it first,<br>
> made no difference to what's coming):<br>
><br>
> zfs create -o dedup=on backup/admin<br>
><br>
> Now zfs list gives:<br>
><br>
> NAME           USED  AVAIL  REFER  MOUNTPOINT<br>
> backup         104K  1.04T    21K  /backup<br>
> backup/admin    21K  1.04T    21K  /backup/admin<br>
><br>
> Looks OK so far.<br>
><br>
> Trouble is, when I copy my 80Gb-odd set to it with plain rsync (same as<br>
> before), I only get a dedupe ratio of 1.01x (ie nothing at all):<br>
><br>
> NAME     SIZE  ALLOC   FREE    CAP  DEDUP  HEALTH  ALTROOT<br>
> backup  1.05T  78.5G  1001G     7%  1.01x  ONLINE  -<br>
><br>
> I also found "zdb backup | grep plain", which indicates that there is no<br>
> deduping being done on any files on the disk, including the schema files<br>
> also included (column 7 should be something less than 100):<br>
><br>
>        107    2    16K   128K  2.75M  2.75M  100.00  ZFS plain file<br>
>        108    2    16K   128K  2.13M  2.12M  100.00  ZFS plain file<br>
>        109    1    16K     8K     8K     8K  100.00  ZFS plain file<br>
>        110    1    16K   9.5K   9.5K   9.5K  100.00  ZFS plain file<br>
>        111    1    16K   9.5K   9.5K   9.5K  100.00  ZFS plain file<br>
>        112    1    16K  12.0K  12.0K  12.0K  100.00  ZFS plain file<br>
>        113    1    16K   9.5K   9.5K   9.5K  100.00  ZFS plain file<br>
>        114    4    16K   128K  19.9G  19.9G  100.00  ZFS plain file<br>
>        115    1    16K    512    512    512  100.00  ZFS plain file<br>
>        116    1    16K     8K     8K     8K  100.00  ZFS plain file<br>
>        117    1    16K   9.5K   9.5K   9.5K  100.00  ZFS plain file<br>
>        118    1    16K   9.5K   9.5K   9.5K  100.00  ZFS plain file<br>
>        119    1    16K  14.5K  14.5K  14.5K  100.00  ZFS plain file<br>
>        120    1    16K  14.5K  14.5K  14.5K  100.00  ZFS plain file<br>
>        121    1    16K  3.50K  3.50K  3.50K  100.00  ZFS plain file<br>
><br>
> 95% of those schema files are in fact identical, so filesystem hard links<br>
> would dedupe them perfectly...<br>
><br>
><br>
> I must be missing something, surely? Or should I just go ahead with<br>
> opendedup and be done with? Any others I should know about (btrfs didn't<br>
> sound terribly stable from what I've been reading)?<br>
><br>
> TIA and Merry Christmas,<br>
> Andrew<br>
><br>
><br>
><br>
</div></div>> _______________________________________________<br>
> PLUG discussion list: <a href="mailto:plug@plug.org.au" target="_blank">plug@plug.org.au</a><br>
> <a href="http://lists.plug.org.au/mailman/listinfo/plug" target="_blank">http://lists.plug.org.au/mailman/listinfo/plug</a><br>
> Committee e-mail: <a href="mailto:committee@plug.org.au" target="_blank">committee@plug.org.au</a><br>
> PLUG Membership: <a href="http://www.plug.org.au/membership" target="_blank">http://www.plug.org.au/membership</a><br>
><br>
<br>
_______________________________________________<br>
PLUG discussion list: <a href="mailto:plug@plug.org.au" target="_blank">plug@plug.org.au</a><br>
<a href="http://lists.plug.org.au/mailman/listinfo/plug" target="_blank">http://lists.plug.org.au/mailman/listinfo/plug</a><br>
Committee e-mail: <a href="mailto:committee@plug.org.au" target="_blank">committee@plug.org.au</a><br>
PLUG Membership: <a href="http://www.plug.org.au/membership" target="_blank">http://www.plug.org.au/membership</a><br>
</blockquote></div><br><br clear="all"><br></div></div><div>-- <br>Linux supports the notion of a command line or a shell for the same<br>reason that only children read books with only pictures in them.<br>Language, be it English or something else, is the only tool flexible<br>


enough to accomplish a sufficiently broad range of tasks.<br>                          -- Bill Garrett
</div></div>
<br>_______________________________________________<br>
PLUG discussion list: <a href="mailto:plug@plug.org.au" target="_blank">plug@plug.org.au</a><br>
<a href="http://lists.plug.org.au/mailman/listinfo/plug" target="_blank">http://lists.plug.org.au/mailman/listinfo/plug</a><br>
Committee e-mail: <a href="mailto:committee@plug.org.au" target="_blank">committee@plug.org.au</a><br>
PLUG Membership: <a href="http://www.plug.org.au/membership" target="_blank">http://www.plug.org.au/membership</a><br></blockquote></div><br></div></div></div>
</blockquote></div><br><br clear="all"><br>-- <br>Linux supports the notion of a command line or a shell for the same<br>reason that only children read books with only pictures in them.<br>Language, be it English or something else, is the only tool flexible<br>
enough to accomplish a sufficiently broad range of tasks.<br>                          -- Bill Garrett
</div>