On Sun, 2007-07-22 at 16:05 +0200, Pierre Ossman wrote:
> On Sun, 22 Jul 2007 14:18:33 +0100
> Richard Purdie <[email protected]> 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.
Corruption is corruption and it shouldn't happen if we can avoid it. It
happens with complete certainty in one case and only happens in the
other if the user does something which is a fairly obvious bad idea
(which is documented as such).
> > 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.
It is however if the MMC layer is going to add Kconfig options which
corrupt things, it can add things to start fixing things too. If those
things can be adapted into more generic code paths, so much the better.
> 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.
Given I can suspend the device with "echo mem > /sys/power/state", that
implies we need to fix echo? ;-)
> > 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.
Agreed.
> And if we keep papering over the problems, you reduce the motivation
> of fixing this properly.
Maybe although I don't like existing functionality being broken even if
its less than ideal.
Regards.
Richard
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[Index of Archives]
[Kernel Newbies]
[Netfilter]
[Bugtraq]
[Photo]
[Stuff]
[Gimp]
[Yosemite News]
[MIPS Linux]
[ARM Linux]
[Linux Security]
[Linux RAID]
[Video 4 Linux]
[Linux for the blind]
[Linux Resources]
