On Mon, 2015-08-24 at 09:29 +0800, Dongsheng Yang wrote: > On 08/10/2015 10:46 AM, Dongsheng Yang wrote: > > On 08/09/2015 05:17 AM, Richard Weinberger wrote: > > > Am 30.07.2015 um 07:48 schrieb Dongsheng Yang: > > > > We need to set or clear MS_RDONLY in remounting. > > > > > > Care to explain why? > > > Does the quota subsystem need that information? > > > If so, where? > > > > Ha, yes, you are right. > > > > When we remount to rw from ro, we need to call dquot_resume. > > And dquot_resume will call vfs_load_quota_inode() which > > will check the MS_RDONLY. If it's ro mode, will return > > an -EROFS. > > > > And I know that we are using ->ro_mount in ubifs > > to store the mounted mode. So we don't care about > > the MS_RDONLY in ubifs. But why not to tell vfs we are in > > ro or rw? Does it cause any problem? > > Hi Artem, > I found there is a commit 2ef13294d to introduce > ro_mount to ubifs. Yes, I see the reason to use ro_mount > rather than MS_RDONLY in ubifs. But why we do not set > MS_RDONLY to tell vfs it's in rdonly or not? Current > quota depends on it. Does this patch cause some problem? MS_RDONLY is set at mount time, then it can be changed when we re -mount, and then UBIFS can change it when there was a critical error, to ask VFS to stop writing more data to the file-system. See 'ubifs_ro_mode()'. The custom ro_mount is the same as MS_RDONLY, but it does not change in 'ubifs_ro_mode()'. It preserves the last mount state before the error happened - was it R/O or R/W. Why is this needed? UBIFS allocate different amount of resources depending on whether we are R/O or R/W. We use less memory in R/O mode, for example. At unmount time, we need to know whether we allocated the "RW" amount of resources or the "RO" amount of resources. We cannot use the MS_RDONLY flag to detect that, because it is changed in 'ubifs_ro_mode()' unconditionally, so we lose the information. Therefore we use the custom ro_mount flag - it tells us how we were mounted, so we know how much resources to free. 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
