On Mon, Feb 05, 2007 at 09:40:08PM +0100, Jan Engelhardt wrote: > > On Feb 5 2007 18:32, Christoph Hellwig wrote: > > > >in two recent discussions (file_list_lock scalability and remount r/o > >on suspend) I stumbled over this emergency remount feature. It's not > >actually useful because it tries a potentially dangerous remount > >despite writers still beeing in progress, which we can't get rid. > > The current way is to remount things, and return -EROFS to any process > that attempts to write(). Unless we want to kill processes to get rid of > them [most likely we possibly won't], I am fine with how things are atm. > So, what's the "dangerous" part, actually? The dangerous part is that we change f->f_mode for all open files without regard for whether there might be any writes underway at the time. This isn't *serious* although the results might be a little strange and it might result in a confused return from write(2). More seriously, mark_files_ro() in super.c *only* changes f->f_mode and doesn't deal with the possibility that the file might be mapped read-write. For filesystems that do delayed allocation, I'm not at all convinced that an emergency read-only will result in the filesystem doing anything at all sane, depending on what else the filesystem might do when the filesystem is forced into read-only state. > sysrq+u is helpful. It is like \( sysrq+s && make sure no further writes > go to disk \). I agree it is useful, but if we're going to do it we really should do it right. We should have real revoke() functionality on file descriptors, which revokes all of the mmap()'s (any attempt to write into a previously read/write mmap will cause a SEGV) as well as changing f_mode, and then use that to implement emergency read-only remount. - Ted - 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
