mirror of https://lore.kernel.org/lkml/
 help / color / mirror / Atom feed
From: Linus Torvalds <torvalds@linux-foundation.org>
To: Alan Cox <alan@lxorguk.ukuu.org.uk>
Cc: Pavel Machek <pavel@suse.cz>, Andreas Mohr <andi@lisas.de>,
	Sriram V <vshrirama@gmail.com>,
	Pierre Ossman <drzeus-list@drzeus.cx>,
	linux-kernel@vger.kernel.org
Subject: Re: Power Management with rootfs on SDMMC.
Date: Sun, 4 Jan 2009 09:53:08 -0800 (PST)	[thread overview]
Message-ID: <alpine.LFD.2.00.0901040946280.3179@localhost.localdomain> (raw)
In-Reply-To: <20090104120415.33e32c6b@lxorguk.ukuu.org.uk>



On Sun, 4 Jan 2009, Alan Cox wrote:
> 
> The distribution question is 'how do you make that decision reliably and
> correctly ?'. That is closely followed by 'what state should it end up in
> if the relevant scripts don't run for some reason ?' - which is clearly
> "not persistent" for safety reasons.

No.

You clearly haven't even read my emails. I quote:

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

however, the sane default remains that things like / and /home _should_ be 
marked persistent.


> I was simply pointing out that
> 
> - the general distribution default cannot be one that harms user data on
> music players

No you were not. You were repeatign that mantra as if it was relevant, 
when it isn't.

> - that you can fix it more elegantly by quiescing and validating file
> systems across a suspend/resume

Send me a patch. 

Hint: you can't sanely even validate it without teaching the USB layer 
_not_ to disconnect and re-connect the damn thing on resume (ie set the 
"persistent" flag), because that can easily cause totally unrelated 
changes to cause the device to be re-enumerated. How do you even find it? 

In other words, you're wrong. 

The only sane thing to do is what I already outlined: teach the 
mount-points (and yes, on a per-mount-point basis) to mark the devices 
persistent, and make the device drivers honor that.

Then, in _addition_, you can - once the device stays around - you can also 
add a filesystem callback for suspend/resume, and make the filesystem try 
to do extra sanity checking. 

But quite frankly, that's very much the secondary stage, since it won't 
matter in any sane real situation (ie once you've simply said that "we 
don't cae about FAT being persistent"). And it's a secondary stage also 
simply because it needs to happen _after_ you've already made the ones you 
care about persistent, since it simply won't work otherwise.

			Linus

  reply	other threads:[~2009-01-04 17:53 UTC|newest]

Thread overview: 15+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2009-01-02  6:35 Sriram V
2009-01-02 10:21 ` Andreas Mohr
2009-01-02 11:21   ` Pierre Ossman
2009-01-02 12:21     ` Andreas Mohr
2009-01-02 17:24   ` Pavel Machek
2009-01-03 20:23     ` Linus Torvalds
2009-01-03 20:43       ` Pavel Machek
2009-01-03 20:45         ` Alan Cox
2009-01-03 21:16           ` Linus Torvalds
2009-01-03 23:10             ` Alan Cox
2009-01-04  2:59               ` Linus Torvalds
2009-01-04 12:04                 ` Alan Cox
2009-01-04 17:53                   ` Linus Torvalds [this message]
2009-03-29 16:26     ` Andreas Mohr
2009-04-05 18:45       ` Pierre Ossman

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=alpine.LFD.2.00.0901040946280.3179@localhost.localdomain \
    --to=torvalds@linux-foundation.org \
    --cc=alan@lxorguk.ukuu.org.uk \
    --cc=andi@lisas.de \
    --cc=drzeus-list@drzeus.cx \
    --cc=linux-kernel@vger.kernel.org \
    --cc=pavel@suse.cz \
    --cc=vshrirama@gmail.com \
    /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

all inboxes | Powered by JetHome®