On Mon 2015-05-11 19:34:34, Daniel Phillips wrote: > > > On 05/11/2015 04:17 PM, Theodore Ts'o wrote: > > On Tue, May 12, 2015 at 12:12:23AM +0200, Pavel Machek wrote: > >> Umm, are you sure. If "some areas of disk are faster than others" is > >> still true on todays harddrives, the gaps will decrease the > >> performance (as you'll "use up" the fast areas more quickly). > > > > It's still true. The difference between O.D. and I.D. (outer diameter > > vs inner diameter) LBA's is typically a factor of 2. This is why > > "short-stroking" works as a technique, > > That is true, and the effect is not dominant compared to introducing > a lot of extra seeks. > > > and another way that people > > doing competitive benchmarking can screw up and produce misleading > > numbers. > > If you think we screwed up or produced misleading numbers, could you > please be up front about it instead of making insinuations and > continuing your tirade against benchmarking and those who do it. Are not you little harsh with Ted? He was polite. > The ram disk removes seek overhead and greatly reduces media transfer > overhead. This does not change things much: it confirms that Tux3 is > significantly faster than the others at synchronous loads. This is > apparently true independently of media type, though to be sure SSD > remains to be tested. > > The really interesting result is how much difference there is between > filesystems, even on a ram disk. Is it just CPU or is it synchronization > strategy and lock contention? Does our asynchronous front/back design > actually help a lot, instead of being a disadvantage as you predicted? > > It is too bad that fs_mark caps number of tasks at 64, because I am > sure that some embarrassing behavior would emerge at high task counts, > as with my tests on spinning disk. I'd call system with 65 tasks doing heavy fsync load at the some time "embarrassingly misconfigured" :-). It is nice if your filesystem can stay fast in that case, but... Pavel -- (english) http://www.livejournal.com/~pavelmachek (cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html -- To unsubscribe from this list: send the line "unsubscribe linux-fsdevel" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
