] On Behalf Of Tom
Sent: 25 September 2010 04:40
To: David Blasingame Oracle
Cc: zfs-discuss@opensolaris.org
Subject: Re: [zfs-discuss] Data transfer taking a longer time than expected
(Possibly dedup related)
Thanks a lot for that. I'm not experienced in reading the output of dtrace,
but I'm pretty
Thanks a lot for that. I'm not experienced in reading the output of dtrace,
but I'm pretty sure that dedup was the cause here, as I disabling it during
the transfer, immediately raised the transfer speed to ~100MB/s.
Thanks for the article you linked to — it seems my system would need about
16GB
Hi all
I'm currently moving a fairly big dataset (~2TB) within the same zpool. Data is
being moved from a dataset to another, which has dedup enabled.
The transfer started at quite a slow transfer speed — maybe 12MB/s. But it is
now crawling to a near halt. Only 800GB has been moved in 48
Can I disable dedup on the dataset while the transfer is going on?
Yes. Only the blocks copied after disabling dedupe will not be deduped. The
stuff you have already copied will be deduped.
Can I simply Ctrl-C the procress to stop it?
Yes, you can do that to a mv process.
Maybe stop the
How do you know it is dedup causing the problem?
You can check to see how much is by looking at the threads (look for ddt)
mdb -k
::threadlist -v
or dtrace it.
fbt:zfs:ddt*:entry
You can disable dedup. I believe current dedup data stays until it gets
over written. I'm not sure what send
Thanks, I'm going to do that. I'm just worried about corrupting my data, or
other problems. I wanted to make sure there is nothing I really should be
careful with.
--
This message posted from opensolaris.org
___
zfs-discuss mailing list
