Re: Experiences: Why BTRFS had to yield for ZFS

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



> IIRC there were some patches post-3.0 which relates to sync. If oracle
> db uses sync writes (or call sync somewhere, which it should), it
> might help to re-run the test with more recent kernel. kernel-ml
> repository might help.

Yeah there doesn't seem to be a shortage of patches coming into btrfs
 (just looking around the mailing-list) so that doesn't surprise me. 
Indeed, reading about race conditions, deadlocks and locks being held too 
long, does not serve to promote btrfs as particular production ready.

> > Ext4 starts out with a realtime to SCN ratio of about 3.4 and ends down 
around a
> > factor 2.2.
> >
> > ZFS starts out with a realtime to SCN ratio of about 7.5 and ends down 
around 
a
> > factor 4.4.
> 
> So zfsonlinux is actually faster than ext4 for that purpuse? coool !

Yes, rather amazingly fast - again, seems to us ZFS is optimized for write 
while btrfs is optimized for read.

> Just wondering, did you use "discard" option by any chance? In my
> experience it makes btrfs MUCH slower.

I actually don't remember when we added this (we started out without it), 
but I don't recall seeing a major difference. We should disable it however,
since the stupid fancy HP RAID controller refuses to pass on TRIM and Smart
commands anyway (and the propriatary HP SSD tools refuse to access 
non-enterprise HP SSD's.

--
To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html


[Index of Archives]     [Linux Filesystem Development]     [Linux NFS]     [Linux NILFS]     [Linux USB Devel]     [Linux Audio Users]     [Yosemite News]     [Linux Kernel]     [Linux SCSI]

  Powered by Linux