Re: [Lustre-discuss] Lustre support for ipv6
In message <1248420309.21455.12.ca...@berloga.shadowland>,Alexey Lyashkov write s: >On Thu, 2009-07-23 at 15:53 -0500, Nicolas Williams wrote: >> On Thu, Jul 23, 2009 at 09:07:39AM -0500, Mitch Felton wrote: >> > Does anyone know if Lustre 1.8 supports ipv6? >> >> I believe it does not. >> >this should be work for tcp LND, but never tested before. i doubt it. when i looked at the lustre code i only saw AF_INET. if there was any sort of ipv6 support there would have to be atleast a little mention of AF_INET6 for some of the socket operations. ___ Lustre-discuss mailing list Lustre-discuss@lists.lustre.org http://lists.lustre.org/mailman/listinfo/lustre-discuss
Re: [Lustre-discuss] Lustre support for ipv6
In message <20090724153810.gf1...@sun.com>,Nicolas Williams writes: >We should have a plan for IPv6 though. you should HAVE ipv6 support. this would give you a leg up on other clustered filesystems. some organizations require ipv6 support for future products. you would now have another reason lustre is "better". ___ Lustre-discuss mailing list Lustre-discuss@lists.lustre.org http://lists.lustre.org/mailman/listinfo/lustre-discuss
Re: [Lustre-discuss] IB storage as an OST target
On Tue, 29 Mar 2011 09:23:59 -0400 Jason Hill wrote: > On Mon, Mar 28, 2011 at 09:36:43AM -0400, Jason Hill wrote: > storage as well. I would definately suggest putting your LNET and SRP > connections on different physical HCA's to keep the traffic at least isolated > on the OSS side. i doubt this matters as much as it once did. pci/pci-x wasnt capacble of reading/writing at the same time due to its bus nature (even though pci-x was point-to-point to the bridge chip). pci-express (and infiniband) can both read and write at the same time. so you can stream in data from srp and stream it out via lnet at the same time on the same port. a bigger concern might be the number of luns behind a single port on your storage controller. most people have more ost's/oss's than ports on the storage controllers. ___ Lustre-discuss mailing list Lustre-discuss@lists.lustre.org http://lists.lustre.org/mailman/listinfo/lustre-discuss
Re: [Lustre-discuss] IB storage as an OST target
On Wed, 30 Mar 2011 12:00:04 -0400 David Dillow wrote: > While it is true both are full duplex, there are also setup messages > flowing in both directions to set up the large transfers. In the past, > we've certainly seen problems at scale with small messages getting > blocked behind large bulk traffic on LNET. It would be interesting to > see how much self-interference is generated when running storage over > the same HCA as LNET, versus having them on separate NICs -- especially i kind of gather that if your clients are doing a mix of i/o (reads and writes) that this is going to happen regardless. two hcas/ports get a sort of parallelism to help alleviate some of this congestion. but a faster port (say 40G) would just as helpful? ___ Lustre-discuss mailing list Lustre-discuss@lists.lustre.org http://lists.lustre.org/mailman/listinfo/lustre-discuss
[Lustre-discuss] [bug?] mdc_enter_request() problems
we have seen a few crashes that look like: [250696.381575] RIP: 0010:[] [] mdc_exit_request+0x74/0xb0 [mdc] ... [250696.381575] Call Trace: [250696.381575] [] mdc_intent_getattr_async_interpret+0x82/0x500 [mdc] [250696.381575] [] ptlrpc_check_set+0x200/0x1690 [ptlrpc] [250696.381575] [] ptlrpcd_check+0x110/0x250 [ptlrpc] and i sort of gather the problem arises from mdc_enter_request(). it allocates an mdc_cache_waiter on the stack and inserts it into the wait list and then returns. int mdc_enter_request(struct client_obd *cli) ... struct mdc_cache_waiter mcw; ... list_add_tail(&mcw.mcw_entry, &cli->cl_cache_waiters); init_waitqueue_head(&mcw.mcw_waitq); later mdc_exit_request() finds this mcw by iterating the list. seeing as mcw was allocated on the stack, i dont think you can do this. mcw might have been reused by the time mdc_exit_request() gets around to removing it. void mdc_exit_request(struct client_obd *cli) ... mcw = list_entry(l, struct mdc_cache_waiter, mcw_entry); ___ Lustre-discuss mailing list Lustre-discuss@lists.lustre.org http://lists.lustre.org/mailman/listinfo/lustre-discuss
Re: [Lustre-discuss] [bug?] mdc_enter_request() problems
On Mon, 08 Aug 2011 12:03:25 -0400 chas williams - CONTRACTOR wrote: > later mdc_exit_request() finds this mcw by iterating the list. > seeing as mcw was allocated on the stack, i dont think you can do this. > mcw might have been reused by the time mdc_exit_request() gets around > to removing it. nevermind. i see this has been fixed in later releases apparently (i was looking at 1.8.5). if l_wait_event() returns "early" (like from being interrupted) mdc_enter_request() does the cleanup itself now. ___ Lustre-discuss mailing list Lustre-discuss@lists.lustre.org http://lists.lustre.org/mailman/listinfo/lustre-discuss
Re: [Lustre-discuss] [bug?] mdc_enter_request() problems
On Tue, 09 Aug 2011 10:29:43 -0600 Kevin Van Maren wrote: > > chas williams - CONTRACTOR wrote: > > nevermind. i see this has been fixed in later releases apparently (i > > was looking at 1.8.5). if l_wait_event() returns "early" (like > > from being interrupted) mdc_enter_request() does the cleanup itself now. > > That code is unchanged in 1.8.6. it appears to have been fixed in the 2.x releases. i think this is the relevant change http://review.whamcloud.com/#change,506 ___ Lustre-discuss mailing list Lustre-discuss@lists.lustre.org http://lists.lustre.org/mailman/listinfo/lustre-discuss
Re: [Lustre-discuss] Anybody have a client running on a 2.6.37 or later kernel?
i have some patches to get the 1.8.6-wc1 client running on FC14. i was working on FC15 (which would be 2.6.38) but got distracted. the changes needed to get to 2.6.38 are a bit tedious. the kernel warning flags changed and some of the configure tests need to be re-written a bit so they don't -Werror On Fri, 21 Oct 2011 20:49:57 -0700 "Carlson, Timothy S" wrote: > Folks, > > I've got a need to run a 2.6.37 or later kernel on client machines in order > to properly support AMD Interlagos CPUs. My other option is to switch from > RHEL 5.x to RHEL 6.x and use the whamcloud 1.8.6-wc1 patchless client (the > latest RHEL 6 kernel also supports Interlagos). But I would first like to > investigate using a 2.6.37 or later kernel on RHEL 5. > > I have a running kernel and started down the path of building Lustre against > 2.6.37.6 and ran into the changes that have been made wrt to ioctl(), proc > structures, etc. I am *not* a kernel programmer would rather not mess around > too much in the source. > > So I am asking if anyone has successfully patched up Lustre to get a client > working with 2.6.37.6 or later. > > Thanks! > > Tim > ___ > Lustre-discuss mailing list > Lustre-discuss@lists.lustre.org > http://lists.lustre.org/mailman/listinfo/lustre-discuss > ___ Lustre-discuss mailing list Lustre-discuss@lists.lustre.org http://lists.lustre.org/mailman/listinfo/lustre-discuss
Re: [Lustre-discuss] Interoperable issues between 1.8.6 and 2.1
On Wed, 22 Aug 2012 21:00:17 -0400 Ken Hornstein wrote: > >I am not finding where it says explicitly that a lustre client running > >1.8 will successfully be able to read and write to a set of lustre > >servers running lustre 2.1. are there any known issues? > > I forget where that was written down; I can report that it works fine. > WITH THE EXCEPTION of ia64 1.8-based clients; that totally doesn't work. when i looked at this briefly i believe the problem was that the ia64 was fetching a page size (16k for the ia64) from the MDS. the 2.x MDS replies with a 4k page and the ia64 client thinks this a short read. this wouldnt be hard to fix for the ia64 but didnt seem like it was worth the trouble. ___ Lustre-discuss mailing list Lustre-discuss@lists.lustre.org http://lists.lustre.org/mailman/listinfo/lustre-discuss
