On 4/17/12 1:43 PM, Ted Ts'o wrote: > On Tue, Apr 17, 2012 at 01:59:37PM -0400, Ric Wheeler wrote: >> >> You could get both security and avoid the run time hit by fully >> writing the file or by having a variation that relied on "discard" >> (i.e., no need to zero data if we can discard or track it as >> unwritten). > > It's certainly the case that if the device supports persistent > discard, something which we definitely *should* do is to send the > discard at fallocate time and then mark the space as initialized. > > Unfortunately, not all devices, and in particular no HDD's for which I > aware support persistent discard. And, writing all zero's to the file > is in fact what a number of programs for which I am aware (including > an enterprise database) are doing, precisely because they tend to > write into the fallocated space in a somewhat random order, and the > extent conversion costs is in fact quite significant. But writing all > zero's to the file before you can use it is quite costly; at the very > least it burns disk bandwidth --- one of the main motivations of > fallocate was to avoid needing to do a "write all zero pass", and > while it does solve the problem for some use cases (such as DVR's), > it's not a complete solution. Can we please start with profiling the workload causing trouble, see why ext4 takes such a hit, and see if anything can be done there to fix it surgically, rather than just throwing this big hammer at it? In my (admittedly quick, hacky) test, xfs suffed about a 1% perf degradation, ext4 about 8%. Until we at least know why ext4 is so much worse, I'll signal a strong NAK for this change, for whatever may or may not be worth. :) -Eric -- 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
