- luv-main - luv.asn.au

ZFS, btrfs, etc benchmarked by Postgres
by Toby Corkindale 13 Sep '11

13 Sep '11

As I threatened to do earlier today, I've run ZFS up against the PostgreSQL benchmark, along with ext4 and ZFS. (You may remember I did this a while back, looking at ext2/3/4, btrfs and xfs) I ran the results on Ubuntu 11.04 with Pg 9.0 and Ubuntu 11.10 beta with Pg 9.1. In the following results, the first combo is called "natty" and the second one "oneiric". The latter combination showed a considerable performance improvement overall - although I didn't investigate to find out whether this was due to kernel improvements, postgres improvements, or virtio improvements. The results are measured in transactions-per-second, with higher numbers being better. ext4 (data=writeback,relatime): natty: 248 oneiric: 297 ext4 (data=writeback,relatime,nobarrier): natty: didn't test oneiric: 1409 xfs (relatime): natty: didn't test oneiric: 171 btrfs (relatime): natty: 61.5 oneiric: 91 btrfs (relatime,nodatacow): natty: didn't test oneiric: 128 zfs (defaults): natty: 171 oneiric: 996 Conclusion: Last time I ran these tests, xfs and ext4 pulled very similar results, and both were miles ahead of btrfs. This time around, ext4 has managed to get a significantly faster result than xfs. However we have a new contender - ZFS performed *extremely* well on the latest Ubuntu setup - achieving triple the performance of regular ext4! I am suspicious that ZFS may not be using any "barrier" coding though - and if ext4 has those disabled, it surpasses even ZFSs high score. Oddly, ZFS performed wildly differently on ubuntu 11.04 vs 11.10b. I can't explain this. Any ideas? Cheers, Toby

1 0

iptables to block inbound connections by UID
by Russell Coker 13 Sep '11

13 Sep '11

ejabberd likes to listen on multiple TCP ports and bind to 0.0.0.0. I can't stop it from binding because then it can't do it's own IPC but I don't want to expose it to the world. Below is the script that I am currently using, the result of this is that the client that connects to one of the undesired ports just gets no response. I can't use -mowner in an INPUT chain. Is there any way I can convert a SYN/ACK to a RST on the way out? iptables -F OUTPUT iptables -A OUTPUT -d 192.168.0.0/16 -j ACCEPT iptables -A OUTPUT -d 127.0.0.0/8 -j ACCEPT # limit ejabberd iptables -A OUTPUT -p tcp --sport 5222 -j ACCEPT iptables -A OUTPUT -p tcp --sport 5269 -j ACCEPT iptables -A OUTPUT -p tcp -mowner --uid-owner 203 -j REJECT --reject-with tcp- reset -- My Main Blog http://etbe.coker.com.au/ My Documents Blog http://doc.coker.com.au/

1 0

Re: [luv-main] backkuppc and ZFS (was Re: Back ups)
by Toby Corkindale 13 Sep '11

13 Sep '11

On 12/09/11 13:20, Jason White wrote: > Peter Ross<Peter.Ross(a)bogen.in-berlin.de> wrote: > >> Every snapshot is like a filesystem, with its own metadata and data. >> >> They only "interfere" because they may point to the same (unchanged) >> data. But there is no backtracking or reconstruction from one >> snapshot to the other. > > My understanding is that this is also true of Btrfs snapshots. It should be > noted that most of the metadata are not copied when a snapshot is created, > judigng by the speed of this operation. > > Regarding ZFS, it is my impression that all of the people who understand the > internals of the file system and its implementation are Sun/Solaris > developers, some of whom may have left after the acquisition by Oracle. I > don't know what situation this creates as to the availability of expertise (at > the level of understanding the code well enough to debug it) for projects > porting it to BSD and Linux. > > Btrfs does appear to be gaining contributions from a variety of sources, > prominently Red Hat, so the expertise isn't concentrated in the hands of any > single corporation. Last time I checked, Btrfs had sucky performance, especially for PostgreSQL loads. (Even with the "nodatacow" option enabled) How does the DKIM-based ZFS look? Otherwise I'm curious enough that I'll run up a test myself. Cheers, Toby

1 0