LKML Archive on lore.kernel.org help / color / mirror / Atom feed
From: Nigel Cunningham <nigel@nigel.suspend2.net> To: Henrique de Moraes Holschuh <hmh@hmh.eng.br> Cc: Andrew Morton <akpm@linux-foundation.org>, akuster@mvista.com, linux-kernel@vger.kernel.org, Pavel Machek <pavel@ucw.cz>, "Rafael J. Wysocki" <rjw@sisk.pl> Subject: Re: [patch 1/1] PM: Adds remount fs ro at suspend Date: Wed, 07 Feb 2007 22:43:13 +1100 [thread overview] Message-ID: <1170848593.9827.24.camel@nigel.suspend2.net> (raw) In-Reply-To: <20070207112539.GD8148@khazad-dum.debian.net> Hi. On Wed, 2007-02-07 at 09:25 -0200, Henrique de Moraes Holschuh wrote: > On Wed, 07 Feb 2007, Nigel Cunningham wrote: > > 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. > > We don't cope okay with the power going out, at all. And as an user case, a > need for fsck if you do something that is a reasonable use case (unplugging > devices while suspended) is not okay, either. Maybe it depends on the filesystem you use. I've used ext3 for 6 or so years of development on Suspend2, and it's never given me a single problem, despite the fact that I've sometimes done the equivalent of pulling the plug without a sync or unmount. I did try XFS at one stage. It's performance was better, but it did give problems. Nevertheless, I'm more than happy to make the above claim about ext3. > > Likewise with changes in hardware. Once hotplugging support is mature, > > suspending, switching around hardware and resuming should just result in > > hot[un]plug events. > > Well, if we add *move* events for when someone unplugs a usb stick in one > port and replugs it in another while the system is in lala-land... maybe :-) > It would be normal to do it, when dealing with docks. Isn't that part of the point to having those uuid thingys? I hate them at the moment (from the point of view of suspend code), but hopefully they'll end up being nicer to deal with.
next prev parent reply other threads:[~2007-02-07 11:43 UTC|newest] Thread overview: 20+ messages / expand[flat|nested] mbox.gz Atom feed top 2007-02-02 23:50 [patch 1/1] PM: Adds remount fs ro at suspend akuster 2007-02-03 0:16 ` Andrew Morton 2007-02-03 0:35 ` Henrique de Moraes Holschuh 2007-02-05 21:28 ` Nigel Cunningham 2007-02-05 21:35 ` Christoph Hellwig 2007-02-06 14:32 ` Henrique de Moraes Holschuh 2007-02-06 18:07 ` Rafael J. Wysocki 2007-02-06 21:38 ` Nigel Cunningham 2007-02-07 11:25 ` Henrique de Moraes Holschuh 2007-02-07 11:43 ` Nigel Cunningham [this message] 2007-02-07 12:05 ` Henrique de Moraes Holschuh 2007-02-07 14:10 ` Rafael J. Wysocki 2007-02-09 22:24 ` Pavel Machek 2007-02-13 12:12 ` Pavel Machek 2007-02-03 0:57 ` akuster 2007-02-03 10:08 ` Christoph Hellwig 2007-02-04 1:34 ` akuster 2007-02-05 16:56 ` Christoph Hellwig 2007-02-14 11:07 ` Pavel Machek 2007-02-03 16:19 ` 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=1170848593.9827.24.camel@nigel.suspend2.net \ --to=nigel@nigel.suspend2.net \ --cc=akpm@linux-foundation.org \ --cc=akuster@mvista.com \ --cc=hmh@hmh.eng.br \ --cc=linux-kernel@vger.kernel.org \ --cc=pavel@ucw.cz \ --cc=rjw@sisk.pl \ /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: linkBe 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; as well as URLs for NNTP newsgroup(s).