Re: [zfs-discuss] Summary: Dedup memory and performance (again, again)

2011-07-14 Thread Frank Van Damme
Op 12-07-11 13:40, Jim Klimov schreef: > Even if I batch background RM's so a hundred processes hang > and then they all at once complete in a minute or two. Hmmm. I only run one rm process at a time. You think running more processes at the same time would be faster? -- No part of this copyright

Re: [zfs-discuss] Summary: Dedup memory and performance (again, again)

2011-07-14 Thread Jim Klimov
2011-07-14 11:54, Frank Van Damme пишет: Op 12-07-11 13:40, Jim Klimov schreef: Even if I batch background RM's so a hundred processes hang and then they all at once complete in a minute or two. Hmmm. I only run one rm process at a time. You think running more processes at the same time would b

Re: [zfs-discuss] Summary: Dedup memory and performance (again, again)

2011-07-14 Thread Frank Van Damme
Op 14-07-11 12:28, Jim Klimov schreef: >> > Yes, quite often it seems so. > Whenever my slow "dcpool" decides to accept a write, > it processes a hundred pending deletions instead of one ;) > > Even so, it took quite a few pool or iscsi hangs and then > reboots of both server and client, and about

Re: [zfs-discuss] Summary: Dedup memory and performance (again, again)

2011-07-14 Thread Jim Klimov
2011-07-14 15:48, Frank Van Damme пишет: It seems counter-intuitive - you'd say: concurrent disk access makes things only slower - , but it turns out to be true. I'm deleting a dozen times faster than before. How completely ridiculous. Thank you :-) Well, look at it this way: it is not only ab

Re: [zfs-discuss] Summary: Dedup memory and performance (again, again)

2011-07-14 Thread Daniel Carosone
um, this is what xargs -P is for ... -- Dan. On Thu, Jul 14, 2011 at 07:24:52PM +0400, Jim Klimov wrote: > 2011-07-14 15:48, Frank Van Damme ?: >> It seems counter-intuitive - you'd say: concurrent disk access makes >> things only slower - , but it turns out to be true. I'm deleting a >>

Re: [zfs-discuss] Summary: Dedup memory and performance (again, again)

2011-07-14 Thread Edward Ned Harvey
> From: zfs-discuss-boun...@opensolaris.org [mailto:zfs-discuss- > boun...@opensolaris.org] On Behalf Of Edward Ned Harvey > > I understand the argument, DDT must be stored in the primary storage pool > so > you can increase the size of the storage pool without running out of space > to hold the D

Re: [zfs-discuss] Summary: Dedup memory and performance (again, again)

2011-07-14 Thread Jim Klimov
2011-07-15 6:21, Daniel Carosone ?: um, this is what xargs -P is for ... Thanks for the hint. True, I don't often use xargs. However from the man pages, I don't see a "-P" option on OpenSolaris boxes of different releases, and there is only a "-p" (prompt) mode. I am not eager to enter "ye

Re: [zfs-discuss] Summary: Dedup memory and performance (again, again)

2011-07-14 Thread Daniel Carosone
On Fri, Jul 15, 2011 at 07:56:25AM +0400, Jim Klimov wrote: > 2011-07-15 6:21, Daniel Carosone ?: >> um, this is what xargs -P is for ... > > Thanks for the hint. True, I don't often use xargs. > > However from the man pages, I don't see a "-P" option > on OpenSolaris boxes of different release

Re: [zfs-discuss] Summary: Dedup memory and performance (again, again)

2011-07-14 Thread Frank Van Damme
Op 15-07-11 04:27, Edward Ned Harvey schreef: > Is anyone from Oracle reading this? I understand if you can't say what > you're working on and stuff like that. But I am merely hopeful this work > isn't going into a black hole... > > Anyway. Thanks for listening (I hope.) ttyl If they aren'