Re: [zfs-discuss] Dedup performance hit

2010-06-14 Thread Richard Elling
Erik is right, more below... On Jun 13, 2010, at 10:17 PM, Erik Trimble wrote: Hernan F wrote: Hello, I tried enabling dedup on a filesystem, and moved files into it to take advantage of it. I had about 700GB of files and left it for some hours. When I returned, only 70GB were moved. I

Re: [zfs-discuss] Dedup performance hit

2010-06-14 Thread Dennis Clarke
You are severely RAM limited. In order to do dedup, ZFS has to maintain a catalog of every single block it writes and the checksum for that block. This is called the Dedup Table (DDT for short). So, during the copy, ZFS has to (a) read a block from the old filesystem, (b) check the

Re: [zfs-discuss] Dedup performance hit

2010-06-14 Thread remi.urbillac
To add such a device, you would do: 'zpool add tank mycachedevice' Hi Correct me if I'm wrong, but for me the good command should be : 'zpool add tank cache mycachedevice' If you don't use the cache keyword, the device would be added as a classical top level vdev. Remi

[zfs-discuss] Dedup performance hit

2010-06-13 Thread Hernan F
Hello, I tried enabling dedup on a filesystem, and moved files into it to take advantage of it. I had about 700GB of files and left it for some hours. When I returned, only 70GB were moved. I checked zpool iostat, and it showed about 8MB/s R/W performance (the old and new zfs filesystems are

Re: [zfs-discuss] Dedup performance hit

2010-06-13 Thread Erik Trimble
Hernan F wrote: Hello, I tried enabling dedup on a filesystem, and moved files into it to take advantage of it. I had about 700GB of files and left it for some hours. When I returned, only 70GB were moved. I checked zpool iostat, and it showed about 8MB/s R/W performance (the old and new zfs

Re: [zfs-discuss] Dedup performance hit

2010-06-13 Thread John J Balestrini
Howdy all, I too dabbled with dedup and found the performance poor with only 4gb ram. I've since disabled dedup and find the performance better but zpool list still shows a 1.15x dedup ratio. Is this still a hit on disk io performance? Aside from copying the data off and back onto the