Re: [PATCH[RFC] kill sysrq-u (emergency remount r/o)
On Mon, Feb 05, 2007 at 10:17:44PM -0500, Theodore Tso wrote: > > 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. Revoke is only part of it. What we really need is proper forced unmount support. That means revoking any kind of userspace access, blocking new access and making sure the ondisk image is coherent. This would definitly be a useful feature, but it's a lot of work. - To unsubscribe from this list: send the line "unsubscribe linux-fsdevel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH[RFC] kill sysrq-u (emergency remount r/o)
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 [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH[RFC] kill sysrq-u (emergency remount r/o)
Hi. On Mon, 2007-02-05 at 18:32 +0100, Christoph Hellwig wrote: > Hi there, > > 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. > > I've attached one patch in this mail that simply kills the > functionality, and in a reply to this mail I'll send a second one > that keeps the sysrq functionality, but removes the force argument > from do_remount_sb that overrides the still busy check. This version > is currently not useful, but makes a lot of sense once Dave Hansens > per-mountpoint r/o patches get in, as we can check for a real write > in progress instead of simply a file opened with write permission. > > Any ideas and comments? I'm not really keen - it sometimes get's invoked here and by others in a sysrq-s sysrq-u sysrq-b sequence (sync, unmount, reboot) in a context where things have gone south (particularly if there's some process stuck). In that context it helps make filesystems cleaner than they'd otherwise be, and the fact that writers might still be in progress is irrelevant because the next keypress is going to reboot anyway. Ok. I'll admit to being a heretic ext3 user, loving not having to fsck after the above and still getting zero corruption as a result. Regards, Nigel - To unsubscribe from this list: send the line "unsubscribe linux-fsdevel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH[RFC] kill sysrq-u (emergency remount r/o)
Christoph Hellwig <[EMAIL PROTECTED]> writes: > Hi there, > > 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. > > I've attached one patch in this mail that simply kills the > functionality, and in a reply to this mail I'll send a second one > that keeps the sysrq functionality, but removes the force argument > from do_remount_sb that overrides the still busy check. This version > is currently not useful, but makes a lot of sense once Dave Hansens > per-mountpoint r/o patches get in, as we can check for a real write > in progress instead of simply a file opened with write permission. > > Any ideas and comments? Most things that sysrq allows you to do are dubious but work most of the time, and are much better than the alternatives. Synching and remounting read-only are several of those, so is rebooting. If you look at the emergency reboot path it doesn't do the clean shutdown that every other reboot path does. So if it is a maintenance problem I'm inclined to believe there is a problem that needs fixing. Otherwise I'm not certain you understand the point of making thees things available with sysrq. Eric - To unsubscribe from this list: send the line "unsubscribe linux-fsdevel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH[RFC] kill sysrq-u (emergency remount r/o)
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? >Any ideas and comments? sysrq+u is helpful. It is like \( sysrq+s && make sure no further writes go to disk \). Jan -- - To unsubscribe from this list: send the line "unsubscribe linux-fsdevel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
