Kano: michaellarabel: you can prepare a vbox 3.0 final article, it is uploaded currently
Kano: michaellarabel: some are already there: http://download.virtualbox.org/virtualbox/3.0.0/
Kano: michaellarabel: http://www.virtualbox.org/wiki/Changelog
sandeen: hey, can anyone try running that apache benchmark and see if you also get tons of "(13)Permission denied: access to /test.html denied" in ~/.phoronix-test-suite]# cd ./installed-tests/apache/httpd_/logs/error_log ?
sandeen: wonders if anyone here actually runs phoronix ;)
redeeman: sandeen: michaellarabel
sandeen: ah.
sandeen: redeeman, what I meant was, uses the test suite :)
jbest: if i got the results that you guys got on the sqlite benchmarks on the brtfs/ext4 article, i'd begin to doubt my test suite :S
jbest: not trying to flame, but did you guys investigate other possible reasons why the results were what they were?
sandeen: jbest, there's nothing wrong with the test suite per se; the root cause is that ext4, xfs, and btrfs all flush the disk cache on an fsync
sandeen: ext3 doesn't
sandeen: (well, not by default)
sandeen: but I agree that leaving it at just the numbers w/ no further explanation or investigation wasn't helpful
sandeen: (well, nothing wrong with the sqlite test, that I know of, I mean)
jbest: that's a programming issue, though... the author of a program is supposed to call that, which is what led to massive data loss when ext4 was implemented without that when ubuntu began to roll that out
jbest: i understand where you're coming from, though
sandeen: sqlite calls fsync on both ext3 and extt4. on those benchmarks, ext4 was slower because ext4 flushes the disk cache to be sure it's really on the platter
jbest: gotcha
jbest: well, that makes sense, at least
sandeen: ubuntu exposed the ext4 behavior becaue their video drivers were crashing kde all the time, IIRC ;)
jbest: :)
jbest: well, that clears things up a little
jbest: sandeen: i appreciate it :D
sandeen: yeah, there's no great mystery but i'd rather have seen it spelled out in the article. if they'd asked on #ext4, or on the list, or whtanot, an explanation would have been happily provided ...
sandeen: i'm also suspicious of the iozone tests; ext4 reading 220MB/s is faster than that drive can likely go
sandeen: the problem w/ the sqlite tests is the take-away for almost anyone who reads it is "extt4 sucks for databases" which really isn't accurate
jbest: yeah.... that seems a bit excessive. unless they were raided, which wouldn't make sense if you were trying to see fs performance...
sandeen: the article said it was a single 7200 RPM 250G 8MB cache drive
jbest: yeah, there's no way it can read at 220MB/s
jbest: hehehe
sandeen: it was a 4GB read on a 4GB box; there may have been a lot of in-cache reads
jbest: indeed
sandeen: dropping caches prior to the read would have given a better result
jbest: that's the only possibility
sandeen: or at least more reliable
jbest: definitely
sandeen: repeatable, etc
sandeen: I'd like to help make the tests better if I can, but I dunno how much interest there is in that
sandeen: when I pointed out some bonnie++ results misparsing, they just dropped the test from the suite
jbest: meh, idk. i'll just continue to take the results with a grain of salt
jbest: i do feel slightly more informed, and i'll look more into it when the other fs's become more stable
sandeen: it could be really useful and informative w/ some work :)
jbest: this is true :D
jbest: has no time to help
jbest: :\
sandeen: the tests just don't make much sense; ext4, xfs, and btrfs should all be going more or less at disk speeds with sane IO
jbest: indeed
sandeen: though 4GB iozone w/ 1k record size may not be the most efficient
jbest: that's also true