On Tue, 1 Apr 2014 10:47:08 -0400, "Theodore Ts'o" <tytso@xxxxxxx> wrote: > On Tue, Apr 01, 2014 at 03:44:53PM +0400, Dmitry Monakhov wrote: > > BTW where this can I find this discussion? I would like to cooperate > > this that activity. Please CC me next time you will disscuss allocation > > performance mesurments. At Parallels we run https://oss.oracle.com/~mason/compilebench/ > > as load simulator. > > The discussion happened at the Ext4 developer's get together in Napa, > California, colocated with the LSF/MM and the Collaboration Summit. > You should go next year; it was a huge amount of fun, and there were a > bunch of other Parallels people there who can tell you about the > reception at the Jacuzzi Family Winery, etc. :-) Hm... the truth is that I was there. I am the man which asked your opinion about mfsync(multy-file-fsync) remember :) But probably I've simply missed an allocation topic. > > I suspect there will be some future conversations at our weekly > conference calls. Typically design stuff will happen there, but > technical low-level details about things like patches will happen on > the mailing list, so you'll be alerted when we start having specific > patches to evaluate and as we start putting together a set of > allocation benchmarks. > > If you are interested in participating on the conference calls, > contact me off-line. If the current time (8AM US/Pacific ; 11 AM > US/Eastern) isn't good for you, we can try to see if another time > works for everyone. Yes. it would be nice. Please invite be to the next call. > > One of the discussion points that came up last week is that it would > be good if we can come up with allocation tests that are fast to run. > That might mean (for example) taking a workload such as compilebench, > and changing it to use fallocate() or having a mount option which > causes the actual data path writes to be skipped for files. We would > then need to have some kind of metric to evaluate how "good" a > particular file system layout ends up being at the end of the > workload. Not just for a specific file, but for all of the files in > some kind of holistic measurement of "goodness", as well as looking at > how fragmented the free space ended up being. Exactly how we do this > is still something that we need to figure out; if you have any > suggestions, they would be most welcome! > > Cheers, > > - Ted -- To unsubscribe from this list: send the line "unsubscribe linux-ext4" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
