[DRBD-user] Seeking extra info on loopback mounted devices

Justin Cattle j at ocado.com
Fri Mar 2 10:00:38 CET 2012

Note: "permalinks" may not be as permanent as we would like,
direct links of old sources may well be a few messages off.


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 <j at ocado.com> 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 <j at ocado.com>
> Date: 9 February 2012 13:51
> Subject: Re: [DRBD-user] Seeking extra info on loopback mounted devices
> To: drbd-user at lists.linbit.com
>
>
> 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 <florian at hastexo.com> wrote:
>
>> On Thu, Feb 9, 2012 at 12:08 PM, Justin Cattle <j at ocado.com> 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
>> drbd-user at lists.linbit.com
>> http://lists.linbit.com/mailman/listinfo/drbd-user
>>
>
>
>

This message has been checked for all known viruses by the Postini Virus Control Centre.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linbit.com/pipermail/drbd-user/attachments/20120302/cbcc6b7d/attachment.htm>


More information about the drbd-user mailing list