It's a shame no one was able/wanted to answer my subsequent questions. For anyone else that want to do a similar thing, I thought I would just post back how we worked round it in the end.
We decided to use the "brd" kernel module - ram-disk backed by a block device. The only problem with that is that it has some shortcomings currently (which is why we didn't go that route initially). With the vanilla kernel module, you can only specify one size of ramdisk (when you load the module). If you want two different sized disks, that presents a problem. You are supposed to be able to partition the disks, but there are some bugs in the implementation when you try and format the partitions (I have raised a bug). You could RAID lots of smaller disks together to achieve different sizes, but this convolutes the set-up. Instead we have modified the brd module code to allow us to specify an array for disk sizes when you load the module, so we can create several different sizes of block backed ram disks. This is working nicely so far with DRBD running on top. If we need to stop the ramdisks, we dd some images (this is all automated), and dd to restore. Cheers, Just On 14 February 2012 13:36, Justin Cattle <[email protected]> wrote: > I'm not 100% sure it wasn't caught by the spam filter on the way out :) > So I'm reposting this - as I never got any more responses. > > > Please see my latest post below - Thanks! > > > Cheers, > Just > > > > ---------- Forwarded message ---------- > From: Justin Cattle <[email protected]> > Date: 9 February 2012 13:51 > Subject: Re: [DRBD-user] Seeking extra info on loopback mounted devices > To: [email protected] > > > Thanks Florian. > > > While that does illustrate how convoluted the process becomes when you > have so many layers (as in this case), it seems to me that it's the point > where there is no free memory left to allocate that ruins the party. > I may be missing something here - please correct me if I'm wrong. > > If the problem only manifests when the system is under memory pressure, is > it not possible to avoid the deadlock if you manage your memory > very strictly? > > To extend that even further, it might it also then be possible to quantify > how much spare memory you need to have in reserve to guarantee operation > without a deadlock? > > Are their factors to consider other than memory that might cause the > deadlock? > > > > Cheers, > Just > > On 9 February 2012 13:29, Florian Haas <[email protected]> wrote: > >> On Thu, Feb 9, 2012 at 12:08 PM, Justin Cattle <[email protected]> wrote: >> > Is this still the case - DRBD 8.3 (or even 8.4) using Linux 3.1 ? >> >> http://lists.linbit.com/pipermail/drbd-user/2011-May/016009.html >> >> Hope this helps. >> >> Cheers, >> Florian >> >> -- >> Need help with High Availability? >> http://www.hastexo.com/now >> _______________________________________________ >> drbd-user mailing list >> [email protected] >> http://lists.linbit.com/mailman/listinfo/drbd-user >> > > > This message has been checked for all known viruses by the Postini Virus Control Centre.
_______________________________________________ drbd-user mailing list [email protected] http://lists.linbit.com/mailman/listinfo/drbd-user
