lkml.org 
[lkml]   [2009]   [May]   [25]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
SubjectRe: [TuxOnIce-devel] [RFC] TuxOnIce
From
Date
Hi.

On Tue, 2009-05-26 at 00:29 +0200, Oliver Neukum wrote:
> Am Montag, 25. Mai 2009 23:39:17 schrieb Nigel Cunningham:
> > > If there's not enough swap available, swsusp should freeze, realize
> > > there's no swap, unfreeze and continue. I do not see reliability
> > > problem there.
> >
> > If there's not enough storage available (I'm also thinking of the file
> > allocator Oliver wants), freeing some memory may get you in a position
>
> No, I do want a dedicated partition. Going to a filesystem is just hiding
> the problem. Filesystems can return -ENOSPC.
> I also want my sytem to reliably hibernate if the filesystem to hold
> the image happens to be remounted ro or to be undergoing a filesystem
> check.
>
> For full reliability you simply need a reservation. In addition that's
> the fastest solution, too. A simple linear write to an unfragmented
> area.
> The typical system today has three orders of magnitude more disk
> than ram. Do you really have a sytem you want to hibernate that has
> less than 2two orders of magnitude more disk than ram?

I agree that a dedicated non-swap partition has advantages. The only
disadvantage I can think of is resizing it if you buy more RAM (and
since that's not going to happen often, it's not a biggie).

I'm not sure that going to a filesystem is hiding the problem though -
whatever solution you adopt, there can be situations in which space
available < space needed. Dedicated non-swap certainly has the least
difficulties, but least != none.

I want flexibility, because different people have different situations
and needs. You might care about a dedicated partition. Another person
might be putting their toe in the Linux water, dual booting with 80% of
the HDD in M$ and having insufficient space to shuffle Linux data around
to make the partition.

Read only filesystems aren't a problem, by the way. So long as you can
bmap the file, that's enough for TuxOnIce - it doesn't currently expand
files - just bmaps and writes directly to the blocks (not via the fs
layer). That's simpler because you _have_ to do the same approach in
reverse at resume time.

Regards,

Nigel



\
 
 \ /
  Last update: 2009-05-26 02:29    [W:0.363 / U:0.076 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site