[EMAIL PROTECTED] wrote: > This is kinda what tmpfs could offer if it was possible to have > pre-load it. > > However, this sounds very much like an ordinary filesystem: you load in > RAM what you need and nothing more.
i'd like to be able to load it like a ramdisk. in linux (sorry, it's what i know). i simply specify a cpio archive instead of a ramdisk and it will overlay it on tmpfs. if i feel it necessary i can limit it's size or by default it can grow to 1/2 of physical ram. > Or perhaps you want ramfs backed by swap? not really, that's why i had the next question ;-) >> okay, i was not aware of that (hence the disclaimer about naivety to >> begin with ;-) if you have a pointer about how to configure this I'd >> appreciate it. I assume if you run out of physical ram solaris will just >> hang? > > Just don't configure any swap. It isn't supposed to hang but failure > modes in RAM shortage are many and complicated: processes may die; > processes cannot be created; some things will start failing, others will > wait in the hope the memory situation get better. okay, we've just seen some strange problems without swap. i haven't had time to look into why, so we are just going to use swap anyway for now. >> Okay, that's good. Do you have the support for x86 too? I was thinking >> more about support on top of Xen. With Xen you are able to migrate >> sessions across computers and with hotplug cpus you can migrate to >> different number of cpus. I'd like to be able migrate a session of my >> server to my laptop whilst i do some hardware tinkering, then migrate it >> back. No interruption to service everythings fine. > > That's something entirely different which cannot be done without involving > a hypervisor of sorts. well, first you have to have xen support, but the hotplug cpu events should be treated the same. Although i'm probably glossing over a tremendous amount of technical detail ;-) > prtdiag is available on newer revisions of Solaris. I'll try to get a new nevada system running soon. If only i could figure out bfu... peter _______________________________________________ opensolaris-discuss mailing list opensolaris-discuss@opensolaris.org
