On Sun, Dec 28, 2008 at 10:24:55PM +0100, Éric Piel wrote: > Of course, by construction, there is nothing relying on the current > relatime semantics. The problem is that whenever you are making relatime > closer to the atime behaviour, you are also getting closer to the > original drawbacks of atime (one read generates one write). If your io is sufficiently limited that one write per file per day is a significant problem, then I think there's a more serious underlying problem. > Actually, you are changing relatime from a boolean condition (maximum > one additional write per write) to a atime with a coarse grain (maximum > one additional write per day). Today you found a use case that needs a > precision of one day. Tomorrow, someone else will find a use case that > needs a precision of one hour. So maybe what is actually needed is a > third option, a "grainatime" option where you can change the precision > of the atime. The answer to "The current two options are suboptimal in almost all cases" is very rarely "Add a new option". If boot is touching too many files, it should stop touching as many files. If you have crap disks, get better disks. If your life is spent tuning fs parameters for 1% performance gains, find a better job. -- Matthew Garrett | mjg59@xxxxxxxxxxxxx -- 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
