[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-Id: <1170797924.14398.19.camel@nigel.suspend2.net>
Date: Wed, 07 Feb 2007 08:38:44 +1100
From: Nigel Cunningham <nigel@...el.suspend2.net>
To: Henrique de Moraes Holschuh <hmh@....eng.br>
Cc: Andrew Morton <akpm@...ux-foundation.org>, akuster@...sta.com,
linux-kernel@...r.kernel.org, Pavel Machek <pavel@....cz>,
"Rafael J. Wysocki" <rjw@...k.pl>
Subject: Re: [patch 1/1] PM: Adds remount fs ro at suspend
Hi.
On Tue, 2007-02-06 at 12:32 -0200, Henrique de Moraes Holschuh wrote:
> On Tue, 06 Feb 2007, Nigel Cunningham wrote:
> > Why do you think remounting filesystems is necessary? Are you getting
> > problems with some particular filesystem?
>
> No. But anything in a removable device neets to be either remounted
> read-only or unmounted if that is at all possible, because the user could
> unplug it. It is of course, sync'd anyway, so if the remount/umount fails,
> no corruption should happen... but the fs will be dirty, etc.
>
> It can get very ugly when you factor in docks and removable bays. It's not
> just USB/firewire mass-storage devices and memory cards. And there is the
> patological cases where the user suspends with the device in one port, and
> resumes with the device in another port.
>
> I feel userspace *can* do all that needs to be done, but we are (currently)
> very bad at it.
Ok, as far as usage scenario goes, that's fair enough. But as to the
solution, I wonder though whether it's making life more complicated than
it needs to be. After all, we should also be able to cope okay with
having the power suddenly go out. If we can cope with that, cleaning
filesystems prior to suspending should be a non-issue.
Likewise with changes in hardware. Once hotplugging support is mature,
suspending, switching around hardware and resuming should just result in
hot[un]plug events.
Regards,
Nigel
-
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