Note: "permalinks" may not be as permanent as we would like,
direct links of old sources may well be a few messages off.
Hi Antonio, I think this problem can also happen for non-OS disks. Considering that we access a non-OS disk , we can have pages in memory that belong to this disk. In that case, the system may ask to flush these "dirty" pages to the non-OS disk. And here we are: potential deadlock as I explain in my first post. I hope this clarify the problem. Correct me if I have made wrong assumptions, I just want to have the conviction that this cannot happen in production. Ivan At Tuesday, 01/02/2011 on 17:44 Antonio Anselmi wrote: OS disk is usually a local device and not managed by drbd, i.e. is not a backing device. Unless I'm missing something about your question. Antonio -- Lo scopo del lavoro è quello di guadagnarsi il tempo libero (Aristotele) The purpose of the job is to gain leisure (Aristotele) 2011/2/1 Ivan Frain : > Hi all, > > I am currently evaluating DRBD as a storage candidate for highly available > storage in a virtualized environment. > It seems like a very good alternative to expensive SAN/NAS. > I was wondering how DRBD deals with the network block device deadlock > problem. > This problem (described here: http://lwn.net/Articles/195416/) can be > summarized as follows: if the system runs short in memory, it will try to > write dirty page to disk in order to free memory space. if the disk is a > network block device, the dirty page write may need to allocate some other > memory pages which is not possible since the solution to have more memory > available was to write the dirty page to disk. > > If someone has some information about that problem I'am eager to read it. > > Thank you in advance. > > BR, > Ivan > > > _______________________________________________ > drbd-user mailing list > drbd-user at lists.linbit.com > http://lists.linbit.com/mailman/listinfo/drbd-user > > _______________________________________________ drbd-user mailing list drbd-user at lists.linbit.com http://lists.linbit.com/mailman/listinfo/drbd-user -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.linbit.com/pipermail/drbd-user/attachments/20110201/a6b824d8/attachment.htm>