> In the "Thoughts on ZFS Pool Backup Strategies thread" it was stated > that zfs send, sends uncompress data and uses the ARC. > > If "zfs send" sends uncompress data which has already been compress > this is not very efficient, and it would be *nice* to see it send the > original compress data. (or an option to do it)
You've got 2 questions in your post. The one above first ... It's true that "zfs send" sends uncompressed data. So I've heard. I haven't tested it personally. I seem to remember there's some work to improve this, but not available yet. Because it was easier to implement the uncompressed send, and that already is super-fast compared to all the alternatives. > I thought I would ask a true or false type questions mainly for > curiosity sake. > > If "zfs send" uses standard ARC cache (when something is not already in > the ARC) I would expect this to hurt (to some degree??) the performance > of the system. (ie I assume it has the effect of replacing > current/useful data in the cache with not very useful/old data And this is a separate question. I can't say first-hand what ZFS does, but I have an educated guess. I would say, for every block the "zfs send" needs to read ... if the block is in ARC or L2ARC, then it won't fetch again from disk. But it is not obliterating the ARC or L2ARC with old data. Because it's smart enough to work at a lower level than a user-space process, and tell the kernel (or whatever) something like "I'm only reading this block once; don't bother caching it for my sake." _______________________________________________ zfs-discuss mailing list zfs-discuss@opensolaris.org http://mail.opensolaris.org/mailman/listinfo/zfs-discuss
