On Wed, 2015-06-10 at 18:10 +0800, Dongsheng Yang wrote: > On 06/10/2015 05:21 PM, Artem Bityutskiy wrote: > > On Wed, 2015-06-10 at 11:16 +0800, Dongsheng Yang wrote: > >> Therefore, I introduced a new option named as force_atime in ubifs. > >> That's a ubifs-dependent opiton and it works as a main switch, in > >> a higher level compared with atime and noatime. If force_atime, we > >> support the atime-related flags. Otherwise, we don't care about all of > >> them in flags and don't support atime anyway. > > > > How bad is it to just default to relatime like other file-systems do, > > comparing to what we have now? > > Ha, yes, that's a problem. I read it from wiki that the author think > it's bad for ubifs. But I did not do a measure about it. Since I am one of the authors, I think we were mostly looking at the full atime support, and did not really look at relatime. > In theory, yes, lots of writing would damage the flash. So I think > just make it optional to user is a flexible way to do it. Even we > want to make the default to relatime, I think it's better to keep > the compatibility for a period and provide a force_atime to user. > > When lots of users said "okey, we are mostly choosing force_atime in our > use cases.". I believe that's a safe way to make ubifs supporting > atime by default. Let me make a step back. So what I hear is that the problem is that you cannot find the original mount options. For example, when you see the MNT_RELATIME flag, you do not know whether it was specified by the user or it was VFS adding this flag. Is this correct? If it is correct, then I think we need to look at a VFS-level solution. If the above is the only problem, then I'd say that introducing a custom "force_atime" is a work-around for VFS limitations. Artem. -- 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
