I know that it is possible to have a Lustre Client and OST on the same blade. I recall that in older versions of lustre, this configuration had some problems. Have these problems been fixed? Is there any problem having a Client and OST on the same blade? Thanks. Roger Spellman Staff Engineer Terascala, Inc. 508-588-1501 www.terascala.com <http://www.terascala.com/> -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.lustre.org/pipermail/lustre-discuss/attachments/20080707/f87c3261/attachment.html
On Mon, 2008-07-07 at 17:00 -0400, Roger Spellman wrote:> Is there any problem having a Client and OST on the same blade?If by "same blade" you mean on the same kernel sharing the same memory pool, yes, the problems that there were still are. They are inherent problems in which the client and OST share the same memory pool and an effort to relieve memory pressure (by the client) requires memory be available to the OST. Of course if the client is experiencing memory pressure so is the OST and the OST might not get the memory it needs to help the client get the memory it needs since it''s all one pool of memory. Indeed it''s a deadlock. I''ve discussed this with one of the more VM knowledgeable engineers than I and IIRC his feeling that here really is no fool-proof fix for this. Perhaps somebody more expert in the VM wants to explain further. b. -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part Url : http://lists.lustre.org/pipermail/lustre-discuss/attachments/20080707/3c6f2bb2/attachment.bin
FUSE did it some how, didn''t they? On Mon, 2008-07-07 at 14:12 -0700, Brian J. Murrell wrote:> On Mon, 2008-07-07 at 17:00 -0400, Roger Spellman wrote: > > Is there any problem having a Client and OST on the same blade? > > If by "same blade" you mean on the same kernel sharing the same memory > pool, yes, the problems that there were still are. They are inherent > problems in which the client and OST share the same memory pool and an > effort to relieve memory pressure (by the client) requires memory be > available to the OST. Of course if the client is experiencing memory > pressure so is the OST and the OST might not get the memory it needs > to > help the client get the memory it needs since it''s all one pool of > memory. Indeed it''s a deadlock. > > I''ve discussed this with one of the more VM knowledgeable engineers > than > I and IIRC his feeling that here really is no fool-proof fix for this. > Perhaps somebody more expert in the VM wants to explain further. > > b. > > > > > plain text document attachment (ATT1031826.txt), "ATT1031826.txt" > _______________________________________________ > Lustre-discuss mailing list > Lustre-discuss at lists.lustre.org > http://lists.lustre.org/mailman/listinfo/lustre-discuss
On Tue, 2008-07-08 at 11:38 -0700, Kevin Fox wrote:> FUSE did it some how, didn''t they?I don''t know. I don''t know anything about FUSE. If you have some reference to how (if) they solved the problem I can escalate it to engineering to see if a similar solution is applicable to Lustre. b. -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part Url : http://lists.lustre.org/pipermail/lustre-discuss/attachments/20080708/548d6d74/attachment.bin
You mean ... you have a FUSE client and a FUSE server for the same file system running on the same node? Klaus On 7/8/08 11:38 AM, "Kevin Fox" <Kevin.Fox at pnl.gov>did etch on stone tablets:> FUSE did it some how, didn''t they? > > On Mon, 2008-07-07 at 14:12 -0700, Brian J. Murrell wrote: >> On Mon, 2008-07-07 at 17:00 -0400, Roger Spellman wrote: >>> Is there any problem having a Client and OST on the same blade? >> >> If by "same blade" you mean on the same kernel sharing the same memory >> pool, yes, the problems that there were still are. They are inherent >> problems in which the client and OST share the same memory pool and an >> effort to relieve memory pressure (by the client) requires memory be >> available to the OST. Of course if the client is experiencing memory >> pressure so is the OST and the OST might not get the memory it needs >> to >> help the client get the memory it needs since it''s all one pool of >> memory. Indeed it''s a deadlock. >> >> I''ve discussed this with one of the more VM knowledgeable engineers >> than >> I and IIRC his feeling that here really is no fool-proof fix for this. >> Perhaps somebody more expert in the VM wants to explain further. >> >> b. >> >> >> >> >> plain text document attachment (ATT1031826.txt), "ATT1031826.txt" >> _______________________________________________ >> Lustre-discuss mailing list >> Lustre-discuss at lists.lustre.org >> http://lists.lustre.org/mailman/listinfo/lustre-discuss > > _______________________________________________ > Lustre-discuss mailing list > Lustre-discuss at lists.lustre.org > http://lists.lustre.org/mailman/listinfo/lustre-discuss