[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <m17iuww38t.fsf@ebiederm.dsl.xmission.com>
Date: Mon, 05 Feb 2007 17:15:14 -0700
From: ebiederm@...ssion.com (Eric W. Biederman)
To: Christoph Hellwig <hch@....de>
Cc: akpm@...l.org, haveblue@...ibm.com, linux-fsdevel@...r.kernel.org,
linux-kernel@...r.kernel.org
Subject: Re: [PATCH[RFC] kill sysrq-u (emergency remount r/o)
Christoph Hellwig <hch@....de> 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-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists