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 _______________________________________________ linux-pm mailing list linux-pm@xxxxxxxxxxxxxxxxxxxxxxxxxx https://lists.linux-foundation.org/mailman/listinfo/linux-pm
