Re: [zfs-discuss] Improving L1ARC cache efficiency with dedup
On Dec 11, 2011 5:12 AM, "Nathan Kroenert" wrote: > > On 12/11/11 01:05 AM, Pawel Jakub Dawidek wrote: >> >> On Wed, Dec 07, 2011 at 10:48:43PM +0200, Mertol Ozyoney wrote: >>> >>> Unfortunetly the answer is no. Neither l1 nor l2 cache is dedup aware. >>> >>> The only vendor i know that can do this is Netapp >> >> And you really work at Oracle?:) >> >> The answer is definiately yes. ARC caches on-disk blocks and dedup just >> reference those blocks. When you read dedup code is not involved at all. >> Let me show it to you with simple test: >> >> Create a file (dedup is on): >> >># dd if=/dev/random of=/foo/a bs=1m count=1024 >> >> Copy this file so that it is deduped: >> >># dd if=/foo/a of=/foo/b bs=1m >> >> Export the pool so all cache is removed and reimport it: >> >># zpool export foo >># zpool import foo >> >> Now let's read one file: >> >># dd if=/foo/a of=/dev/null bs=1m >>1073741824 bytes transferred in 10.855750 secs (98909962 bytes/sec) >> >> We read file 'a' and all its blocks are in cache now. The 'b' file >> shares all the same blocks, so if ARC caches blocks only once, reading >> 'b' should be much faster: >> >># dd if=/foo/b of=/dev/null bs=1m >>1073741824 bytes transferred in 0.870501 secs (1233475634 bytes/sec) >> >> Now look at it, 'b' was read 12.5 times faster than 'a' with no disk >> activity. Magic?:) >> > > Hey all, > > That reminds me of something I have been wondering about... Why only 12x faster? If we are effectively reading from memory - as compared to a disk reading at approximately 100MB/s (which is about an average PC HDD reading sequentially), I'd have thought it should be a lot faster than 12x. > > Can we really only pull stuff from cache at only a little over one gigabyte per second if it's dedup data? The second file may gave the same data, but not the same metadata -the inode number at least must be different- so the znode for it must get read in, and that will slow reading the copy down a bit. Nico -- ___ zfs-discuss mailing list zfs-discuss@opensolaris.org http://mail.opensolaris.org/mailman/listinfo/zfs-discuss
Re: [zfs-discuss] Improving L1ARC cache efficiency with dedup
On Mon, Dec 12, 2011 at 08:30:56PM +0400, Jim Klimov wrote: > 2011-12-12 19:03, Pawel Jakub Dawidek пишет: > > As I said, ZFS reading path involves no dedup code. No at all. > > I am not sure if we contradicted each other ;) > > What I meant was that the ZFS reading path involves reading > logical data blocks at some point, consulting the cache(s) > if the block is already cached (and up-to-date). These blocks > are addressed by some unique ID, and now with dedup there are > several pointers to same block. > > So, basically, reading a file involves reading ZFS metadata, > determining data block IDs, fetching them from disk or cache. > > Indeed, this does not need to be dedup-aware; but if the other > chain of metadata blocks points to same data or metadata blocks > which were already cached (for whatever reason, not limited to > dedup) - this is where the read-speed boost appears. > Likewise, if some blocks are not cached, such as metadata > needed to determine the second file's block IDs, this incurs > disk IOs and may decrease overall speed. Ok, you are right, although in this test, I believe metadata of the other file was already prefetched. I'm using this box for something else now, so can't retest, but the procedure is so easy that everyone is welcome to try it:) -- Pawel Jakub Dawidek http://www.wheelsystems.com FreeBSD committer http://www.FreeBSD.org Am I Evil? Yes, I Am! http://yomoli.com pgpNepBs6v1MX.pgp Description: PGP signature ___ zfs-discuss mailing list zfs-discuss@opensolaris.org http://mail.opensolaris.org/mailman/listinfo/zfs-discuss
