Date: Mon, 19 Dec 2011 23:07:36 +0200 From: Daniel Kalchev <daniel@digsys.bg> To: Stefan Esser <se@freebsd.org> Cc: FreeBSD Current <freebsd-current@freebsd.org> Subject: Re: Uneven load on drives in ZFS RAIDZ1 Message-ID: <E858048F-66F6-4B32-A9E9-018CB5A830DC@digsys.bg> In-Reply-To: <4EEFA5E4.9070803@freebsd.org> References: <4EEF488E.1030904@freebsd.org> <83648C73-E45F-4ABA-8E83-4C8903A683AB@digsys.bg> <4EEFA5E4.9070803@freebsd.org>
next in thread | previous in thread | raw e-mail | index | archive | help
On Dec 19, 2011, at 11:00 PM, Stefan Esser wrote: > Am 19.12.2011 19:03, schrieb Daniel Kalchev: >> I have observed similar behavior, even more extreme on a spool with = dedup enabled. Is dedup enabled on this spool? >=20 > Thank you for the report! >=20 > Well, I had dedup enabled for a few short tests. But since I have got > "only" 8GB of RAM and dedup seems to require an order of magnitude = more > to be working well, I switched dedup off again after a few hours. You will need to get rid of the DDT, as those are read nevertheless even = with dedup (already) disabled. The tables refer to already deduped data. In my case, I had about 2-3TB of deduced data, with 24GB RAM. There was = no shortage of RAM and I could not confirm that ARC is full.. but = somehow the pool was placing heavy read on one or two disks only (all = others, nearly idle) -- apparently many small size reads. I resolved my issue by copying the data to a newly created filesystem in = the same pool -- luckily there was enough space available, then removing = the 'deduped' filesystems. That last operation was particularly slow and at one time I had = spontaneous reboot -- the pool was 'impossible to mount', and as weird = as it sounds, I had 'out of swap space' killing the 'zpool list' = process. I let it sit for few hours, until it has cleared itself. I/O in that pool is back to normal now. There is something terribly wrong with the dedup code. Well, if your test data is not valuable, you can just delete it. :) Daniel
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?E858048F-66F6-4B32-A9E9-018CB5A830DC>