Hi, Following up on this thread i download the latest OpenSUSE and repeated the read / write performamce test and again compared to XFS etc. Reads seem good. But writes are still way down compared to XFS. Also BTRFS seems to scale in performance very purely? whilst all the FS's i tested ramp up performance within a couple of DDs or threads... btrfs just doesnt, so for most typical writes while XFS is around 1300MBsec , btrfs is only around 500MBsec Any ideas? Marek On Thu, May 12, 2011 at 12:41 AM, cwillu <cwillu@xxxxxxxxxx> wrote: > On Wed, May 11, 2011 at 4:33 PM, Marek Fstump <marekfstump@xxxxxxxxx> wrote: >> Hi >> >> I am very interested in using BTRFS for my solution but in basic tests >> it seems to be very poor on read and write performance. I am >> surprised by this so suspect that maybe I am doing something >> incorrectly or that there are updates I should be using, but I am not >> sure how I update BTRFS on SLES11 >> >> Summary: >> RESULTS on link below >> SLES11 SP1 >> Compared Sequential read/write performance against XFS and OCFS2 >> Backend storage – FusionIO SLC SSD = circa 750MBsec >> >> Tests set as follows: >> Filesystem contains 30 x 4GB files (made of random data) >> Read tests will read from 1 to 30 files concurrently >> Write tests will write 1 to 30 concurrent NEW files (simple 000’s) >> dd -direct flag used on writes >> >> All defaults used for mounting etc. >> >> Results shown in attachment. >> >> BTRFS looks an excellent FS and perfect for my application and I am >> hoping that there are some factors that I am missing >> and would appreciate any advice / help >> >> Graph is here (Thank you ‘cwillu’) >> >> http://cwillu.com/files/btrfs/read-write_perf.pdf > > A couple questions: > > Which kernel version? > How big is the partition the testing is done on? > How does btrfs compare if you drop the -direct flag, and instead sync > + drop_caches before, and time until sync completes after dd (for all > of them, not just btrfs)? > > There are a couple btrfs mount options that will improve performance > in this particular case, but this benchmark may not reflect your > actual needs. >
Attachment:
Capture.PNG
Description: PNG image
