Snappy Testing

Alright. I've finally got around to doing some Snappy testing. I've gotten some amazing results, but also noticed a bug. My current code seems to hang after a large amount of compression. It specifically hangs when i am doing an iozone benchmark. The 500MB pass (I set it to 4GB). But before I ran iozone, i did some paliminary testing vs lzjb, and I have to say, the compression performance is higher with Snappy. I was able to get a 23.14  compression ration instead of the 15.22 ratio from lzjb, with similar cpu usage.

I suspect this has to do with the snappy_env_init method in the snappy-c library i found. It seems fishy having to initializing the environment for every compression event. I may look into it further but it does not seem very scaleable. and given that ZFS compression works at the block level, and not the file level, there are a lot of compression events happening for a single file (instead of one event, compressing a 400MB file...it would be 400 events with a zfs file sysem that is allocated using 4k blocks).

Anyway, I may or may not delve further into this. I think I could actually call this a finished project. Its in a usable state. Anyone can grab it from github and run snappy with zfsonlinux. Snappy could be a real contender in the ZFS space. I might even think about adding other algorithms to zfs. 7z, bzip and ARJ would be fun.

Comments

Popular posts from this blog

Linq To SQL and Change Tracking

BB10 and Mono

Haiku + Mono: Almost there