Re: [TuxOnIce-devel] [RFC] TuxOnIce

[Nigel Cunningham <nigel@tuxonice.net>]

Hi.

On Mon, 2009-05-25 at 17:35 -0700, david@lang.hm wrote:
> On Tue, 26 May 2009, 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 actually have a couple of systems that have 128G of ram and 144G of 
> disk. and it can't take 3.5" drives (and I don't know if it's SAS 
> backplane can drive SATA drives, if so it can't take many of them) so the 
> 'dives are cheap' answer may not work.
> 
> now, the question of if it makes sense to try and hibernate this system is 
> a very valid one.

It is. I guess you have to ask how long it takes to get your working set
back if you shutdown instead and whether you can spare ~70G of HDD space
(maybe less, perhaps your compression ration will be very good) for the
storage.

What sort of hard drive throughput do you get? If you double that
(allowing for compression), you should have a good approximation (on the
conservative side) of the throughput you'll be able to get hibernating
and resuming (assuming the CPU(s) can compress the data fast enough).

Regards,

Nigel