Colin Raven wrote:
Hey Cindy!
Any idea of when we might see 129? (an approximation only). I ask the
question because I'm pulling budget funds to build a filer, but it may
not be in service until mid-January. Would it be reasonable to say
that we might see 129 by then, or are we looking at sum
Hey Cindy!
Any idea of when we might see 129? (an approximation only). I ask the
question because I'm pulling budget funds to build a filer, but it may not
be in service until mid-January. Would it be reasonable to say that we might
see 129 by then, or are we looking at summer...or even beyond?
I
Hi Jim,
Nevada build 128 had some problems so will not be released.
The dedup space fixes should be available in build 129.
Thanks,
Cindy
On 12/02/09 02:37, Jim Klimov wrote:
Hello all
Sorry for bumping an old thread, but now that snv_128 is due to appear as a
public DVD download, I wonder
Hello all
Sorry for bumping an old thread, but now that snv_128 is due to appear as a
public DVD download, I wonder: has this fix for zfs-accounting and other issues
with zfs dedup been integrated into build 128?
We have a fileserver which is likely to have much redundant data and we'd like
to
Eric Schrock wrote:
On Nov 3, 2009, at 12:24 PM, Cyril Plisko wrote:
I think I'm observing the same (with changeset 10936) ...
# mkfile 2g /var/tmp/tank.img
# zpool create tank /var/tmp/tank.img
# zfs set dedup=on tank
# zfs create tank/foobar
This has to do with the fact that dedu
>>> I think I'm observing the same (with changeset 10936) ...
>>
>> # mkfile 2g /var/tmp/tank.img
>> # zpool create tank /var/tmp/tank.img
>> # zfs set dedup=on tank
>> # zfs create tank/foobar
>
> This has to do with the fact that dedup space accounting is charged to all
> filesystems, reg
I'm fairly new to all this and I think that is the intended behavior.
Also from my limited understanding I believe dedup behavior it would
significantly cut down on access times.
For the most part though this is such new code that I would wait abit to see
where they take it.
On Tue, Nov 3, 2009 a
On Nov 3, 2009, at 12:24 PM, Cyril Plisko wrote:
I think I'm observing the same (with changeset 10936) ...
# mkfile 2g /var/tmp/tank.img
# zpool create tank /var/tmp/tank.img
# zfs set dedup=on tank
# zfs create tank/foobar
This has to do with the fact that dedup space accounting is
Cyril Plisko wrote:
I think I'm observing the same (with changeset 10936) ...
# mkfile 2g /var/tmp/tank.img
# zpool create tank /var/tmp/tank.img
# zfs set dedup=on tank
# zfs create tank/foobar
This has to do with the fact that dedup space accounting is charged to all
f
On Nov 3, 2009, at 6:01 AM, Jürgen Keil wrote:
I think I'm observing the same (with changeset 10936) ...
# mkfile 2g /var/tmp/tank.img
# zpool create tank /var/tmp/tank.img
# zfs set dedup=on tank
# zfs create tank/foobar
This has to do with the fact that dedup space accounting
> I think I'm observing the same (with changeset 10936) ...
# mkfile 2g /var/tmp/tank.img
# zpool create tank /var/tmp/tank.img
# zfs set dedup=on tank
# zfs create tank/foobar
> dd if=/dev/urandom of=/tank/foobar/file1 bs=1024k count=512
512+0 records in
512+0 record
> So.. it seems that data is deduplicated, zpool has
> 54.1G of free space, but I can use only 40M.
>
> It's x86, ONNV revision 10924, debug build, bfu'ed from b125.
I think I'm observing the same (with changeset 10936) ...
I created a 2GB file, and a "tank" zpool on top of that file,
with compr
12 matches
Mail list logo
