From: Pierre Ossman <drzeus-mmc@drzeus.cx>
To: Richard Purdie <rpurdie@rpsys.net>
Cc: kernel list <linux-kernel@vger.kernel.org>
Subject: Re: MMC/SD Root filesystem suspend/resume problems
Date: Sun, 22 Jul 2007 16:05:34 +0200 [thread overview]
Message-ID: <20070722160534.3ccfc8f9@poseidon.drzeus.cx> (raw)
In-Reply-To: <1185110313.6819.8.camel@localhost.localdomain>
On Sun, 22 Jul 2007 14:18:33 +0100
Richard Purdie <rpurdie@rpsys.net> wrote:
>
> I enabled the MMC_UNSAFE_RESUME option and the problems I was seeing
> was "fixed". I think having this option is a bad idea (in its current
> form) as it doesn't actually stop filesystem corruption.
>
> With the option disabled, if a filesystem is mounted when you suspend
> my tests show the filesystem is corrupted. At least if the option is
> enabled, the filesystem is only corrupted if you remove the card
> whilst suspended which is more preferable.
>
I disagree. With this option you get silent corruption, without you get
noisy corruption. And I would always prefer the latter, even if it
increases the risk of it happening.
> I guess the solution would be to abort the suspend if mounted systems
> were detected and the option was disabled? Alternatively the option
> could be "auto" enabled only for mounted systems maybe with a printk
> warning?
>
This is a general problem for all removable/hotpluggable storage. So
sticking it in the MMC block device would be the wrong layer IMO.
Until the filesystems can be made to store something sane on disk
before the suspend, I'd say this is best handled in user space. Let the
user space tools refuse to initiate the suspend as long as any
removable devices are mounted.
> Of course the best solution would be to have filesystems support
> suspend/resume requests since other subsystems like pcmcia also suffer
> this problem and would benefit from this but I accept that teaching
> filesystems this is more difficult.
>
Doesn't mean we shouldn't do it. And if we keep papering over the
problems, you reduce the motivation of fixing this properly.
Rgds
--
-- Pierre Ossman
Linux kernel, MMC maintainer http://www.kernel.org
PulseAudio, core developer http://pulseaudio.org
rdesktop, core developer http://www.rdesktop.org
next prev parent reply other threads:[~2007-07-22 14:05 UTC|newest]
Thread overview: 10+ messages / expand[flat|nested] mbox.gz Atom feed top
2007-07-19 15:53 Richard Purdie
2007-07-19 16:42 ` Richard Purdie
2007-07-19 17:03 ` Pierre Ossman
2007-07-22 13:18 ` Richard Purdie
2007-07-22 14:05 ` Pierre Ossman [this message]
2007-07-22 14:28 ` Richard Purdie
2007-07-22 14:59 ` Pierre Ossman
2007-07-25 19:01 ` Pavel Machek
2007-07-25 19:20 ` Richard Purdie
2007-07-25 22:47 ` Pavel Machek
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20070722160534.3ccfc8f9@poseidon.drzeus.cx \
--to=drzeus-mmc@drzeus.cx \
--cc=linux-kernel@vger.kernel.org \
--cc=rpurdie@rpsys.net \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox
Powered by JetHome