Brian Gold | 8 Aug 2012 17:27
Picon
Favicon

undoing zfs deduplication

I've got a system running 9.0-release w/ a zfs v28 pool. Within that pool I have 3 datasets, two of which have deduplication
enabled. I've recently been having a lot of performance issues with deduplication and have determined
that I need far more ram that
I currently have in order to support dedupe. I don't have the budget for the ram necessary so I would like to
move away from
deduplication. I'm aware  that you can't simply turn dedupe off, you need to completely nuke the
filesystem. 

What I'm wondering is, would it be possible for me to create new datasets within the same pool (I have a ton of
available space) and
use a combination of "zfs send" & "zfs receive" to migrate my deduped datasets and all of their snapshots
(daily, weekly, & monthly)
over to the new dataset? 

Brian Gold
System Administrator
Bard College at Simon's Rock

_______________________________________________
freebsd-fs <at> freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-fs
To unsubscribe, send any mail to "freebsd-fs-unsubscribe <at> freebsd.org"

Freddie Cash | 8 Aug 2012 17:41
Picon
Gravatar

Re: undoing zfs deduplication

On Wed, Aug 8, 2012 at 8:27 AM, Brian Gold <bgold <at> simons-rock.edu> wrote:
> I've got a system running 9.0-release w/ a zfs v28 pool. Within that pool I have 3 datasets, two of which have deduplication
> enabled. I've recently been having a lot of performance issues with deduplication and have determined
that I need far more ram that
> I currently have in order to support dedupe. I don't have the budget for the ram necessary so I would like to
move away from
> deduplication. I'm aware  that you can't simply turn dedupe off, you need to completely nuke the filesystem.
>
> What I'm wondering is, would it be possible for me to create new datasets within the same pool (I have a ton of
available space) and
> use a combination of "zfs send" & "zfs receive" to migrate my deduped datasets and all of their snapshots
(daily, weekly, & monthly)
> over to the new dataset?

Yes, that is the only option for "un-deduping" a filesystem.

zfs send/recv from the deduped filesystem to one with dedup=off.  Then
delete the deduped filesystem.

Note:  a "zfs destroy" will use a lot of RAM as it has to go through
an update all the DDT entries.  You may have to manually delete
individual snapshots, and then manually delete individual directories
in the filesystem, before destroying the actual filesystem.  You may
run into a situation where you don't have enough RAM/ARC to destroy a
deduped filesystem.

--

-- 
Freddie Cash
fjwcash <at> gmail.com
_______________________________________________
(Continue reading)

Brian Gold | 8 Aug 2012 18:08
Picon
Favicon

RE: undoing zfs deduplication

> Yes, that is the only option for "un-deduping" a filesystem.
> 
> zfs send/recv from the deduped filesystem to one with dedup=off.  Then delete the deduped filesystem.
> 
> Note:  a "zfs destroy" will use a lot of RAM as it has to go through an update all the DDT entries.  You may have to
manually delete
> individual snapshots, and then manually delete individual directories in the filesystem, before
destroying the actual filesystem.  You
> may run into a situation where you don't have enough RAM/ARC to destroy a deduped filesystem.
> 
> --
> Freddie Cash
> fjwcash <at> gmail.com

>From what I've read so far, it looks like a "zfs send -R" would send the filesystem and all of the snapshots
I've made. So would something like this work to move the duped filesystem and all of its snapshots over to a
new undeduped filesystem: "zfs send -R backup/duped | zfs receive -duv backup/deduped" ?

_______________________________________________
freebsd-fs <at> freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-fs
To unsubscribe, send any mail to "freebsd-fs-unsubscribe <at> freebsd.org"

Freddie Cash | 8 Aug 2012 18:32
Picon
Gravatar

Re: undoing zfs deduplication

On Wed, Aug 8, 2012 at 9:08 AM, Brian Gold <bgold <at> simons-rock.edu> wrote:
>> Yes, that is the only option for "un-deduping" a filesystem.
>>
>> zfs send/recv from the deduped filesystem to one with dedup=off.  Then delete the deduped filesystem.
>>
>> Note:  a "zfs destroy" will use a lot of RAM as it has to go through an update all the DDT entries.  You may have
to manually delete
>> individual snapshots, and then manually delete individual directories in the filesystem, before
destroying the actual filesystem.  You
>> may run into a situation where you don't have enough RAM/ARC to destroy a deduped filesystem.
>>
>> --
>> Freddie Cash
>> fjwcash <at> gmail.com
>
> From what I've read so far, it looks like a "zfs send -R" would send the filesystem and all of the snapshots
I've made. So would something like this work to move the duped filesystem and all of its snapshots over to a
new undeduped filesystem: "zfs send -R backup/duped | zfs receive -duv backup/deduped" ?

Yes.  That will create a new filesystem and snapshots of the non-deduped data.

You would still have to delete the deduped filesystem, though, to
clear out the DDT and remove the extra RAM requirements of dedupe.

--

-- 
Freddie Cash
fjwcash <at> gmail.com
_______________________________________________
freebsd-fs <at> freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-fs
(Continue reading)

Nikolay Denev | 8 Aug 2012 17:55
Picon
Gravatar

Re: undoing zfs deduplication

On Aug 8, 2012, at 6:27 PM, Brian Gold <bgold <at> simons-rock.edu> wrote:

> I've got a system running 9.0-release w/ a zfs v28 pool. Within that pool I have 3 datasets, two of which have deduplication
> enabled. I've recently been having a lot of performance issues with deduplication and have determined
that I need far more ram that
> I currently have in order to support dedupe. I don't have the budget for the ram necessary so I would like to
move away from
> deduplication. I'm aware  that you can't simply turn dedupe off, you need to completely nuke the
filesystem. 
> 
> What I'm wondering is, would it be possible for me to create new datasets within the same pool (I have a ton of
available space) and
> use a combination of "zfs send" & "zfs receive" to migrate my deduped datasets and all of their snapshots
(daily, weekly, & monthly)
> over to the new dataset? 
> 
> Brian Gold
> System Administrator
> Bard College at Simon's Rock
> 
> 
> 
> _______________________________________________
> freebsd-fs <at> freebsd.org mailing list
> http://lists.freebsd.org/mailman/listinfo/freebsd-fs
> To unsubscribe, send any mail to "freebsd-fs-unsubscribe <at> freebsd.org"

I believe simply disabling dedup should be enough.
Some blocks still will be just a "reference" to the original block because of the previously enabled
deduplication, but this won't use additional memory.
(Continue reading)


Gmane