Date: Sat, 20 Oct 2012 10:30:18 +0300 From: Daniel Kalchev <daniel@digsys.bg> To: David Wimsey <david@wimsey.us> Cc: "freebsd-fs@freebsd.org" <freebsd-fs@freebsd.org> Subject: Re: Memory consumption after turning off dedup Message-ID: <28A26432-EB80-41DF-82B2-B1D8F998D9A5@digsys.bg> In-Reply-To: <44510CBA-2D95-4BDF-8AEE-61727760321C@wimsey.us> References: <44510CBA-2D95-4BDF-8AEE-61727760321C@wimsey.us>
next in thread | previous in thread | raw e-mail | index | archive | help
The only way I am aware of to get rid of the DDT (what is consuming = memory) is to turn dedup off, then copy all the data in again -- if you = have space, you could copy within the same zpool, then remove the old = data. Maybe it doesn't remove all the DDT entries, such as for metadata, = but at least most of it will be gone. Turning off dedup only prevents = deduplication of data you write after that act. Daniel On Oct 20, 2012, at 10:18 AM, David Wimsey <david@wimsey.us> wrote: > I've had dedup on for a while and everything was good until the feeble = machine I have as a file server couldn't deal with the memory = requirements of dedup. I solved the problem by adding more RAM, = imported the pools on the machine and turned off dedup. I had a ratio = of less than 2x, and the main savings were on virtual machine disks = which I want maximum performance for. >=20 > Does the memory consumption due to the DDT go away when you turn dedup = off or do I need to do a send/recv on it? >=20 > I assume that once the block is deduced and written to disk its not = really any different than a blocks associated with a snapshot, is that = correct? >=20 > I also assume that there is no performance penalties on reads, only = writes since it (with dedup on) has to check the dedup table to see if = it is a duplicate, is that correct? >=20 > _______________________________________________ > freebsd-fs@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-fs > To unsubscribe, send any mail to "freebsd-fs-unsubscribe@freebsd.org"
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?28A26432-EB80-41DF-82B2-B1D8F998D9A5>