lkml.org 
[lkml]   [2009]   [Jan]   [3]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: Power Management with rootfs on SDMMC.


On Sat, 3 Jan 2009, Alan Cox wrote:

> > [Now, olympus uses VFAT and probably will not write to the filesystem
> > unless you take a picture... with mp3 player, I'd expect mtime to be
> > updated on the playlist files...]
>
> Some of the MP3/OGG players (especially the bigger disk based ones) use
> the file system to store their own metadata so yes it makes a nasty mess.

Well, it goes both ways. You can make a nasty mess right now by suspending
and simply not having a working computer when it comes back - all your
work being lost.

At least with cameras and mp3 players you _can_ choose to just unmount
them before suspending (and most distros would hopefully mount them with
something like automount anyway?). In contrast, if your root (or /home)
directory is on a SD card, and that card is over USB rather than some IDE
controller, you're basically screwed.

Yes, distros can set the /sys/bus/usb/devices/.../power/persist thing for
important filesystems automatically, and I'm sure there are magic udev
rules that could be written (and perhaps even exist). The likelihood that
they actually get things right is pretty low, though. So I suspect we'd be
much better off having sane defaults in the kernel instead.

And yes, the "sane defaults" may well be that FATFS does _not_ make the
media be persistent.

Think "door lock" commands (aka "prevent/allow medium removal"). This is
really not that very different. Some filesystems are so important that the
user messing with them is deadly anyway - so we should "lock" them and
consider them persistent - and if the user does something bad, there was
really never any good solution for it. Other filesystems we're better off
just letting the user rip out, because we can be reasonably expected to
handle it gracefully.

So it boils down to the fact that if you have something like / or /home
mounted, we really _cannot_ do any better than "assume the user doesn't
screw us up".

A per-filesystem callback to re-verify at resume might be a good idea, but
a lot of filesystems cannot reasonably do a lot of verification.

Linus


\
 
 \ /
  Last update: 2009-01-03 22:21    [W:0.475 / U:0.512 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site