Date: Thu, 17 May 2018 15:24:15 +0200 From: Stefan Esser <se@freebsd.org> To: Konstantin Belousov <kostikbel@gmail.com> Cc: Bruce Evans <brde@optusnet.com.au>, FreeBSD File-Systems <freebsd-fs@freebsd.org> Subject: Re: [Bug 210316] panic after trying to r/w mount msdosfs on write protected media Message-ID: <57342a02-ddf3-0a41-d394-74b8f8a27a83@freebsd.org> In-Reply-To: <20180517114235.GI6887@kib.kiev.ua> References: <bug-210316-3630@https.bugs.freebsd.org/bugzilla/> <bug-210316-3630-eXVbCR5qFd@https.bugs.freebsd.org/bugzilla/> <20180517163709.F1129@besplex.bde.org> <8c1cb4b3-633a-5b14-0713-727b03f44f4e@freebsd.org> <20180517114235.GI6887@kib.kiev.ua>
next in thread | previous in thread | raw e-mail | index | archive | help
Am 17.05.18 um 13:42 schrieb Konstantin Belousov: > On Thu, May 17, 2018 at 10:04:01AM +0200, Stefan Esser wrote: >> In case that a media (whether removable or not) was mounted R/W and not >> written to (had no dirty buffers) for more than a few seconds, the mount >> could be downgraded to R/O (in the same way as by a "mount -u -o ro"). A >> flag that recorded the fact, that this partition may be written to could >> then be checked in the "write to R/O partition" error case, and if the >> file system was only temporarily set to R/O, it could be treated like a >> first access to a writable partition (i.e., write a dirty flag into the >> super-block or whatever action the file system performs when mounted R/W). >> >> In short, the suggestion is to down-grade the mount state of any file-system >> not used for some configurable time to R/O, with an automatic upgrade to R/W >> on the next write attempt. > Downgrade to ro revokes all file descriptors opened for write, otherwise > it is not a downgrade. Really? I was not aware of that effect, but I think it can be dealt with in a similar way as an unmount request for a file system with open files. In the case of SD cards or other media used for file transfer, it is unlikely that a file system is in active use for an extended time (except for the duration of the file transfer). This is obviously not true for embedded ARM platforms that use SD cards for normal file systems. But the revocation of file file descriptors open for writing does not appear necessary to me. A clean state should be reached (same as a vetoed unmount request typically creates) and then a "clean" superblock could be written, which only corresponds to the state of the file system, not that individual files had their stdio buffers flushed and the file completely written. The flushing of stdio buffers would cause a remount of the partition as R/W. And this will obviously only ever occur, if the file descriptors have not been revoked. > This would be a huge mess. Yes, definitely. But it has been more than a decade since I looked into this topic and AFAIR, it was sufficient to just wait for no dirty buffers, then set the partition to R/O (and at the same time write a clean super-block) and have a flag that allows restarting writes after marking the super-block dirty again. It is not necessary to actually perform a R/O remount. The only guarantee required is, that the super-block is not marked clean if there are any outstanding writes (to make sure, that data blocks and meta-data are consistent) when a clean super-block is written, and that the next write attempt is intercepted and causes the super-block to be dirtied before the write is allowed to change any on disk data. Regards, STefan
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?57342a02-ddf3-0a41-d394-74b8f8a27a83>