From shay at opensfs.org Thu Mar 1 17:29:53 2012 From: shay at opensfs.org (Shay Seager) Date: Thu, 1 Mar 2012 09:29:53 -0800 Subject: [Lustre-devel] LUG Program Announced Message-ID: Hello Lustre Community! The LUG committee is happy to announce that we have just published the LUG Program. Please follow this link http://www.opensfs.org/lug/program to see what all the excitement is about. Don't forget to register by March 9th to ensure early bird pricing and hotel room discounts! Register here: http://www.opensfs.org/lug/registration. We look forward to seeing you at LUG! - - - Shay Seager Open SFS Secretary www.opensfs.org (925) 290-7641 shay at opensfs.org -------------- next part -------------- An HTML attachment was scrubbed... URL: From philippe.deniel at cea.fr Fri Mar 2 12:25:20 2012 From: philippe.deniel at cea.fr (DENIEL Philippe) Date: Fri, 02 Mar 2012 13:25:20 +0100 Subject: [Lustre-devel] Does LUSTRE supports setfsuid/setfsgid ? Message-ID: <4F50BC30.5090602@cea.fr> Hi List, I am the maintener of NFS-Ganesha, a NFS server running in User Space. The server has several backends on different filesystems. One of the backend is dedicated to LUSTRE, using liblustreapi.a . The server is generic and I faced the problem to "su" to a user inside a thread for backends whose calls have no specific credentials parameter. For backends like XFS, GPFS and VFS (they are accessed via the "open by handle" feature in kernel > 2.6.39) I can use setfsuid/setfsgid. I works pretty well and provides a way to "become" a different user in different threads. I plan to use the same kind of logic with LUSTRE. Here comes my question : does LUSTRE supports setfsuid and setfsgid and it behaves a every filesystem accessed by the VFS ? Regards Philippe From adilger at whamcloud.com Fri Mar 2 19:28:54 2012 From: adilger at whamcloud.com (Andreas Dilger) Date: Fri, 2 Mar 2012 11:28:54 -0800 Subject: [Lustre-devel] Does LUSTRE supports setfsuid/setfsgid ? In-Reply-To: <4F50BC30.5090602@cea.fr> References: <4F50BC30.5090602@cea.fr> Message-ID: <9EB68D7F-0152-4148-8330-B40E6BA0F719@whamcloud.com> On 2012-03-02, at 4:25 AM, DENIEL Philippe wrote: > I am the maintener of NFS-Ganesha, a NFS server running in User Space. > The server has several backends on different filesystems. One of the > backend is dedicated to LUSTRE, using liblustreapi.a . > The server is generic and I faced the problem to "su" to a user inside a > thread for backends whose calls have no specific credentials parameter. > For backends like XFS, GPFS and VFS (they are accessed via the "open by > handle" feature in kernel > 2.6.39) I can use setfsuid/setfsgid. I works > pretty well and provides a way to "become" a different user in different > threads. I plan to use the same kind of logic with LUSTRE. > Here comes my question : does LUSTRE supports setfsuid and setfsgid and > it behaves a every filesystem accessed by the VFS ? Yes, Lustre supports this, as far as I know. Potential difficulties include that if the "su" process is only partial, then the fsuid/fsgid may be wrong on the MDS, so the supplementary group upcall on the MDS may return the wrong group list for that UID. Another difficulty is that Lustre does not yet support the "open by handle" feature, though I worked with the original developer to ensure that it would work reasonably well with Lustre. I don't think this would be too hard for someone to implement, but I haven't yet looked into the details. Lustre already allows lookup-by-FID, which would be necessary for this feature. Cheers, Andreas -- Andreas Dilger Whamcloud, Inc. Principal Lustre Engineer http://www.whamcloud.com/ From kelly.zhang at emc.com Thu Mar 8 10:01:10 2012 From: kelly.zhang at emc.com (kelly.zhang at emc.com) Date: Thu, 8 Mar 2012 05:01:10 -0500 Subject: [Lustre-devel] if "--enable-split" option is still (or to be) supported? Message-ID: Hi All, I am configuring and building Lustre. While I met a problem which needs you guys to take a look. When compiling with "--enable-split" option, "make rpms" will fail. But if without this option, it works correctly. The error message would look like: $ ./configure --enable-split --with-linux=/home/build/kernel/rpmbuild/BUILD/kernel-2.6.32-220.4.2.el6/linux-2.6.32-220.4.2.el6.x86_64/ $ make rpms /home/build2/kernel/rpmbuild/BUILD/lustre-2.1.56/lustre/cmm/cmm_split.c: In function 'cmm_object_find': /home/build2/kernel/rpmbuild/BUILD/lustre-2.1.56/lustre/cmm/cmm_split.c:256: error: 'fid' undeclared (first use in this function) /home/build2/kernel/rpmbuild/BUILD/lustre-2.1.56/lustre/cmm/cmm_split.c:256: error: (Each undeclared identifier is reported only once /home/build2/kernel/rpmbuild/BUILD/lustre-2.1.56/lustre/cmm/cmm_split.c:256: error: for each function it appears in.) cc1: warnings being treated as errors /home/build2/kernel/rpmbuild/BUILD/lustre-2.1.56/lustre/cmm/cmm_split.c: In function 'cmm_split_slave_create': /home/build2/kernel/rpmbuild/BUILD/lustre-2.1.56/lustre/cmm/cmm_split.c:309: error: format '%llu' expects type 'long long unsigned int', but argument 10 has type 'mdsno_t' /home/build2/kernel/rpmbuild/BUILD/lustre-2.1.56/lustre/cmm/cmm_split.c: In function 'cmm_split_dir': /home/build2/kernel/rpmbuild/BUILD/lustre-2.1.56/lustre/cmm/cmm_split.c:742: error: 'MDS_LMV_MD_NAME' undeclared (first use in this function) make[8]: *** [/home/build2/kernel/rpmbuild/BUILD/lustre-2.1.56/lustre/cmm/cmm_split.o] Error 1 make[7]: *** [/home/build2/kernel/rpmbuild/BUILD/lustre-2.1.56/lustre/cmm] Error 2 make[6]: *** [/home/build2/kernel/rpmbuild/BUILD/lustre-2.1.56/lustre] Error 2 make[5]: *** [_module_/home/build2/kernel/rpmbuild/BUILD/lustre-2.1.56] Error 2 make[5]: Leaving directory `/home/build2/kernel/rpmbuild/BUILD/kernel-2.6.32-220.4.2.el6/linux-2.6.32-220.4.2.el6.x86_64' make[4]: *** [modules] Error 2 make[4]: Leaving directory `/home/build2/kernel/rpmbuild/BUILD/lustre-2.1.56' make[3]: *** [all-recursive] Error 1 make[3]: Leaving directory `/home/build2/kernel/rpmbuild/BUILD/lustre-2.1.56' make[2]: *** [all] Error 2 make[2]: Leaving directory `/home/build2/kernel/rpmbuild/BUILD/lustre-2.1.56' error: Bad exit status from /var/tmp/rpm-tmp.NXaQK0 (%build) kernel source used: 2.6.32-220.4.2.el6.x86_64 After checking the related code, it seems that piece of code is either still under development or silently dropped: git blame cmm_split.c -L252,257 d2d56f38 (tappro 2007-07-30 21:08:59 +0000 252) struct cmm_object *cmm_object_find(const struct lu_env *env, d2d56f38 (tappro 2007-07-30 21:08:59 +0000 253) struct cmm_device *d, d2d56f38 (tappro 2007-07-30 21:08:59 +0000 254) const struct lu_fid *f) d2d56f38 (tappro 2007-07-30 21:08:59 +0000 255) { 0ad352cf (nikita 2008-10-18 17:14:45 +0000 256) return md2cmm_obj(md_object_find_slice(env, &d->cmm_md_dev, fid)); d2d56f38 (tappro 2007-07-30 21:08:59 +0000 257) } So: Just want to confirm that if "--enable-split" is still (or to be) supported? Thanks for your time. Your help are much more appreciated. Best Regards, Kelly Zhang(EMC) -------------- next part -------------- An HTML attachment was scrubbed... URL: From tao.peng at emc.com Thu Mar 8 14:55:30 2012 From: tao.peng at emc.com (tao.peng at emc.com) Date: Thu, 8 Mar 2012 09:55:30 -0500 Subject: [Lustre-devel] oldest lustre supported SUSE kernel In-Reply-To: <9C0BB3E3-D296-42A0-89EA-67F299215215@whamcloud.com> References: <9C0BB3E3-D296-42A0-89EA-67F299215215@whamcloud.com> Message-ID: Hi Andreas, > -----Original Message----- > From: Andreas Dilger [mailto:adilger at whamcloud.com] > Sent: Tuesday, February 07, 2012 12:36 AM > To: Peng, Tao > Cc: > Subject: Re: [Lustre-devel] oldest lustre supported SUSE kernel > > On 2012-02-06, at 2:53, wrote: > > > > As I know, the oldest lustre supported RHEL kernel is 2.6.18-latest. What is the oldest SUSE kernel? > 2.6.32-latest? > > That depends on which version of Lustre you are asking about, and whether you are asking about the > client or server. > > For Lustre 2.2+ servers it will be SLES11 SP1 (2.6.32), since it matches RHEL6 (2.6.32). > > For clients it is RHEL5 (2.6.18) and SLES11 SP0 (2.6.27). > We found that latest master branch doesn't build client for SLES11 SP0 (2.6.27). Does it mean master has moved on dropping SLES11 SP0 or it should be fixed? Thanks, Tao From: Zhang, Kelly Sent: Thursday, March 08, 2012 6:44 PM To: Peng, Tao Cc: China COE FastData Subject: RE: Conversation with Zhang, Kelly The latest Lustre code also fails on suse11SP0(kernel version linux-2.6.27.19-5.1), when building Lustre: cc1: warnings being treated as errors /home/master/kernel/rpmbuild/BUILD/lustre-2.2.50/lustre/llite/llite_mmap.c:585: error: initialization from incompatible pointer type make[8]: *** [/home/master/kernel/rpmbuild/BUILD/lustre-2.2.50/lustre/llite/llite_mmap.o] Error 1 make[7]: *** [/home/master/kernel/rpmbuild/BUILD/lustre-2.2.50/lustre/llite] Error 2 make[6]: *** [/home/master/kernel/rpmbuild/BUILD/lustre-2.2.50/lustre] Error 2 make[5]: *** [_module_/home/master/kernel/rpmbuild/BUILD/lustre-2.2.50] Error 2 make[5]: Leaving directory `/var/tmp/kernel-source-2.6.27.19-build/usr/src/linux-2.6.27.19-5.1' make[4]: *** [modules] Error 2 make[4]: Leaving directory `/home/master/kernel/rpmbuild/BUILD/lustre-2.2.50' make[3]: *** [all-recursive] Error 1 make[3]: Leaving directory `/home/master/kernel/rpmbuild/BUILD/lustre-2.2.50' make[2]: *** [all] Error 2 make[2]: Leaving directory `/home/master/kernel/rpmbuild/BUILD/lustre-2.2.50' error: Bad exit status from /var/tmp/rpm-tmp.76807 (%build) From jsimmons at infradead.org Thu Mar 8 16:49:12 2012 From: jsimmons at infradead.org (James Simmons) Date: Thu, 8 Mar 2012 16:49:12 +0000 (GMT) Subject: [Lustre-devel] oldest lustre supported SUSE kernel In-Reply-To: References: <9C0BB3E3-D296-42A0-89EA-67F299215215@whamcloud.com> Message-ID: > > On 2012-02-06, at 2:53, wrote: > > > > > > As I know, the oldest lustre supported RHEL kernel is 2.6.18-latest. What is the oldest SUSE kernel? > > 2.6.32-latest? > > > > That depends on which version of Lustre you are asking about, and whether you are asking about the > > client or server. > > > > For Lustre 2.2+ servers it will be SLES11 SP1 (2.6.32), since it matches RHEL6 (2.6.32). > > > > For clients it is RHEL5 (2.6.18) and SLES11 SP0 (2.6.27). > > > We found that latest master branch doesn't build client for SLES11 SP0 (2.6.27). Does it mean master has moved on dropping SLES11 SP0 or it should be fixed? I build and use lustre on SLES11 SP1 clients and routers (using server version). It works fine. Is there a reason you use SP0? From tao.peng at emc.com Fri Mar 9 01:54:38 2012 From: tao.peng at emc.com (tao.peng at emc.com) Date: Thu, 8 Mar 2012 20:54:38 -0500 Subject: [Lustre-devel] oldest lustre supported SUSE kernel In-Reply-To: References: <9C0BB3E3-D296-42A0-89EA-67F299215215@whamcloud.com> Message-ID: > -----Original Message----- > From: James Simmons [mailto:jsimmons at infradead.org] > Sent: Friday, March 09, 2012 12:49 AM > To: Peng, Tao > Cc: adilger at whamcloud.com; wc-discuss at whamcloud.com; lustre-devel at lists.lustre.org > Subject: Re: [Lustre-devel] oldest lustre supported SUSE kernel > > > > > On 2012-02-06, at 2:53, wrote: > > > > > > > > As I know, the oldest lustre supported RHEL kernel is 2.6.18-latest. What is the oldest SUSE > kernel? > > > 2.6.32-latest? > > > > > > That depends on which version of Lustre you are asking about, and whether you are asking about the > > > client or server. > > > > > > For Lustre 2.2+ servers it will be SLES11 SP1 (2.6.32), since it matches RHEL6 (2.6.32). > > > > > > For clients it is RHEL5 (2.6.18) and SLES11 SP0 (2.6.27). > > > > > We found that latest master branch doesn't build client for SLES11 SP0 (2.6.27). Does it mean master > has moved on dropping SLES11 SP0 or it should be fixed? > > I build and use lustre on SLES11 SP1 clients and routers (using server > version). It works fine. Is there a reason you use SP0? We are not using SP0. Just that we are working on cleaning up some old code and would like to make sure Lustre works as it says in the lustre/kernel_patches/which_patch 2.6.27.19-5 (SLES11) Thanks, Tao From adilger at whamcloud.com Fri Mar 9 05:56:42 2012 From: adilger at whamcloud.com (Andreas Dilger) Date: Fri, 9 Mar 2012 13:56:42 +0800 Subject: [Lustre-devel] Changing FID->DLM lock encoding for version Message-ID: I'm planning to change the FID->DLM lock encoding for the FID "version" field in order to free up some space in the DLM lock resource (potentially for directory quotas, and other uses). Currently the FID is mapped into the DLM lock as follows: name[0] = fid_seq(fid); name[1] = fid_oid(fid); name[2] = fid_ver(fid); name[3] = { name hash for pdirops } The 32-bit FID VER is currently always 0 today, and I'd like to move into the high 32 bits of name[1] along with the 32-bit OID, to avoid consuming the name[2] field. The new encoding would be equivalent to the following: name[0] = fid_seq(fid); name[1] = ((__u64)fid_ver(fid) << 32) | fid_ver(fid); name[2] = 0; name[3] = { name hash for pdirops } but using the "fid_ver_oid(fid)" macro that is also doing something similar to encode the FID into the 64-bit "o_id" and "o_gr" fields of struct obdo and elsewhere in the OST protocol. Since fid_ver(fid) is always zero, it doesn't really matter where we encode it today, since it doesn't affect the resulting DLM lock resource name or cause any interoperability issues, but allows more flexibility in the future. Since future use of the FID version (intended for snapshots and datasets within a single Lustre filesystem) will need changes on the client side anyway, there should never be non-zero VER seen by an older client. A patch to do this has been submitted to Gerrit master with: Change-Id: If1e500cfb277dfc25bc056bb0c5763e48e7dccdf I intend to land a similar patch for b1_8 and b2_1, but I'd like to verify that nobody is using the FID version, nor plans to use it in the near future (i.e. in the next couple of years). Cheers, Andreas -- Andreas Dilger Whamcloud, Inc. Principal Lustre Engineer http://www.whamcloud.com/ From adilger at whamcloud.com Fri Mar 9 07:36:49 2012 From: adilger at whamcloud.com (Andreas Dilger) Date: Fri, 9 Mar 2012 15:36:49 +0800 Subject: [Lustre-devel] oldest lustre supported SUSE kernel In-Reply-To: References: <9C0BB3E3-D296-42A0-89EA-67F299215215@whamcloud.com> Message-ID: On 2012-03-08, at 10:55 PM, wrote: >> Andreas Dilger wrote: >> On 2012-02-06, at 2:53, wrote: >>> As I know, the oldest lustre supported RHEL kernel is 2.6.18-latest. What is the oldest SUSE kernel? >> >> 2.6.32-latest? >> >> That depends on which version of Lustre you are asking about, and whether you are asking about the client or server. >> >> For Lustre 2.2+ servers it will be SLES11 SP1 (2.6.32), since it matches RHEL6 (2.6.32). >> >> For clients it is RHEL5 (2.6.18) and SLES11 SP0 (2.6.27). > > We found that latest master branch doesn't build client for SLES11 SP0 (2.6.27). Does it mean master has moved on dropping SLES11 SP0 or it should be fixed? This looks like the page_mkwrite() prototype changing from "struct page *" (which is in kernels before 2.6.29) to "struct vm_fault *" (which is used in later kernels). I don't have a SLES11 SP0 kernel available to check which one it is using, but it should be the "struct page *" based on the kernel version. This should already be handled by the check for HAVE_VM_OP_FAULT, but possibly this is broken in newer versions of the SP0 kernel? It often happens that vendor kernels backport code/APIs from newer kernels in order to make porting other drivers/filesystem code easier. As you can tell, we do not build the SLES11 SP0 client ourselves automatically, only the SP1 client, but if the effort is not huge it would be preferable to keep this client working. We typically try to keep the range of working clients as large as possible, since administrators may not have as much control over the running clients as they do over the servers. I would guess (without having looked at the SP0 kernel) that it may just be possible to change lustre/autoconf/lustre-core.m4 to check this prototype, and move the two ll_page_mkwrite() helpers into their own "#ifdef HAVE_PAGE_MKWRITE_VM_FAULT" section separate from HAVE_VM_OP_FAULT. If this analysis is incorrect, I apologize, but I'm travelling and unable to download the whole kernel at this time. Cheers, Andreas > From: Zhang, Kelly > Sent: Thursday, March 08, 2012 6:44 PM > To: Peng, Tao > Cc: China COE FastData > Subject: RE: Conversation with Zhang, Kelly > > The latest Lustre code also fails on suse11SP0(kernel version linux-2.6.27.19-5.1), when building Lustre: > cc1: warnings being treated as errors > /home/master/kernel/rpmbuild/BUILD/lustre-2.2.50/lustre/llite/llite_mmap.c:585: error: initialization from incompatible pointer type > make[8]: *** [/home/master/kernel/rpmbuild/BUILD/lustre-2.2.50/lustre/llite/llite_mmap.o] Error 1 > make[7]: *** [/home/master/kernel/rpmbuild/BUILD/lustre-2.2.50/lustre/llite] Error 2 > make[6]: *** [/home/master/kernel/rpmbuild/BUILD/lustre-2.2.50/lustre] Error 2 > make[5]: *** [_module_/home/master/kernel/rpmbuild/BUILD/lustre-2.2.50] Error 2 > make[5]: Leaving directory `/var/tmp/kernel-source-2.6.27.19-build/usr/src/linux-2.6.27.19-5.1' > make[4]: *** [modules] Error 2 > make[4]: Leaving directory `/home/master/kernel/rpmbuild/BUILD/lustre-2.2.50' > make[3]: *** [all-recursive] Error 1 > make[3]: Leaving directory `/home/master/kernel/rpmbuild/BUILD/lustre-2.2.50' > make[2]: *** [all] Error 2 > make[2]: Leaving directory `/home/master/kernel/rpmbuild/BUILD/lustre-2.2.50' > error: Bad exit status from /var/tmp/rpm-tmp.76807 (%build) > Cheers, Andreas -- Andreas Dilger Whamcloud, Inc. Principal Lustre Engineer http://www.whamcloud.com/ From tao.peng at emc.com Fri Mar 9 11:32:17 2012 From: tao.peng at emc.com (tao.peng at emc.com) Date: Fri, 9 Mar 2012 06:32:17 -0500 Subject: [Lustre-devel] oldest lustre supported SUSE kernel In-Reply-To: References: <9C0BB3E3-D296-42A0-89EA-67F299215215@whamcloud.com> Message-ID: > -----Original Message----- > From: Andreas Dilger [mailto:adilger at whamcloud.com] > Sent: Friday, March 09, 2012 3:37 PM > To: Peng, Tao > Cc: lustre-devel at lists.lustre.org; wc-discuss at whamcloud.com > Subject: Re: [Lustre-devel] oldest lustre supported SUSE kernel > > On 2012-03-08, at 10:55 PM, wrote: > >> Andreas Dilger wrote: > >> On 2012-02-06, at 2:53, wrote: > >>> As I know, the oldest lustre supported RHEL kernel is 2.6.18-latest. What is the oldest SUSE > kernel? > >> > >> 2.6.32-latest? > >> > >> That depends on which version of Lustre you are asking about, and whether you are asking about the > client or server. > >> > >> For Lustre 2.2+ servers it will be SLES11 SP1 (2.6.32), since it matches RHEL6 (2.6.32). > >> > >> For clients it is RHEL5 (2.6.18) and SLES11 SP0 (2.6.27). > > > > We found that latest master branch doesn't build client for SLES11 SP0 (2.6.27). Does it mean master > has moved on dropping SLES11 SP0 or it should be fixed? > > This looks like the page_mkwrite() prototype changing from "struct page *" (which is in kernels before > 2.6.29) to "struct vm_fault *" (which is used in later kernels). I don't have a SLES11 SP0 kernel > available to check which one it is using, but it should be the "struct page *" based on the kernel > version. This should already be handled by the check for HAVE_VM_OP_FAULT, but possibly this is > broken in newer versions of the SP0 kernel? > > It often happens that vendor kernels backport code/APIs from newer kernels in order to make porting > other drivers/filesystem code easier. > > As you can tell, we do not build the SLES11 SP0 client ourselves automatically, only the SP1 client, > but if the effort is not huge it would be preferable to keep this client working. We typically try to > keep the range of working clients as large as possible, since administrators may not have as much > control over the running clients as they do over the servers. > > I would guess (without having looked at the SP0 kernel) that it may just be possible to change > lustre/autoconf/lustre-core.m4 to check this prototype, and move the two ll_page_mkwrite() helpers > into their own "#ifdef HAVE_PAGE_MKWRITE_VM_FAULT" section separate from HAVE_VM_OP_FAULT. Thanks for confirming that it is still supported. And I verified it can be fixed as you described. I created LU-1200 and attached the fix there. Cheers, Tao > > If this analysis is incorrect, I apologize, but I'm travelling and unable to download the whole kernel > at this time. > > Cheers, Andreas > > > From: Zhang, Kelly > > Sent: Thursday, March 08, 2012 6:44 PM > > To: Peng, Tao > > Cc: China COE FastData > > Subject: RE: Conversation with Zhang, Kelly > > > > The latest Lustre code also fails on suse11SP0(kernel version linux-2.6.27.19-5.1), when building > Lustre: > > cc1: warnings being treated as errors > > /home/master/kernel/rpmbuild/BUILD/lustre-2.2.50/lustre/llite/llite_mmap.c:585: error: > initialization from incompatible pointer type > > make[8]: *** [/home/master/kernel/rpmbuild/BUILD/lustre-2.2.50/lustre/llite/llite_mmap.o] Error 1 > > make[7]: *** [/home/master/kernel/rpmbuild/BUILD/lustre-2.2.50/lustre/llite] Error 2 > > make[6]: *** [/home/master/kernel/rpmbuild/BUILD/lustre-2.2.50/lustre] Error 2 > > make[5]: *** [_module_/home/master/kernel/rpmbuild/BUILD/lustre-2.2.50] Error 2 > > make[5]: Leaving directory `/var/tmp/kernel-source-2.6.27.19-build/usr/src/linux-2.6.27.19-5.1' > > make[4]: *** [modules] Error 2 > > make[4]: Leaving directory `/home/master/kernel/rpmbuild/BUILD/lustre-2.2.50' > > make[3]: *** [all-recursive] Error 1 > > make[3]: Leaving directory `/home/master/kernel/rpmbuild/BUILD/lustre-2.2.50' > > make[2]: *** [all] Error 2 > > make[2]: Leaving directory `/home/master/kernel/rpmbuild/BUILD/lustre-2.2.50' > > error: Bad exit status from /var/tmp/rpm-tmp.76807 (%build) > > > > > Cheers, Andreas > -- > Andreas Dilger Whamcloud, Inc. > Principal Lustre Engineer http://www.whamcloud.com/ > > > > From jsimmons at infradead.org Fri Mar 9 12:56:54 2012 From: jsimmons at infradead.org (James Simmons) Date: Fri, 9 Mar 2012 12:56:54 +0000 (GMT) Subject: [Lustre-devel] oldest lustre supported SUSE kernel In-Reply-To: References: <9C0BB3E3-D296-42A0-89EA-67F299215215@whamcloud.com> Message-ID: > > As you can tell, we do not build the SLES11 SP0 client ourselves automatically, only the SP1 client, > > but if the effort is not huge it would be preferable to keep this client working. We typically try to > > keep the range of working clients as large as possible, since administrators may not have as much > > control over the running clients as they do over the servers. > > > > I would guess (without having looked at the SP0 kernel) that it may just be possible to change > > lustre/autoconf/lustre-core.m4 to check this prototype, and move the two ll_page_mkwrite() helpers > > into their own "#ifdef HAVE_PAGE_MKWRITE_VM_FAULT" section separate from HAVE_VM_OP_FAULT. > Thanks for confirming that it is still supported. And I verified it can be fixed as you described. I created LU-1200 and attached the fix there. Sorry to nit pick but can you push your patch with gerrit instead of just posting it to the Jira ticket. From surya1 at llnl.gov Fri Mar 9 16:25:17 2012 From: surya1 at llnl.gov (Prakash Surya) Date: Fri, 9 Mar 2012 08:25:17 -0800 Subject: [Lustre-devel] [wc-discuss] Changing FID->DLM lock encoding for version In-Reply-To: References: Message-ID: <20120309162517.GG21926@llnl.gov> On Thu, Mar 08, 2012 at 09:56:42PM -0800, Andreas Dilger wrote: > I'm planning to change the FID->DLM lock encoding for the FID "version" field in order to free up some space in the DLM lock resource (potentially for directory quotas, and other uses). > > Currently the FID is mapped into the DLM lock as follows: > > name[0] = fid_seq(fid); > name[1] = fid_oid(fid); > name[2] = fid_ver(fid); > name[3] = { name hash for pdirops } > > The 32-bit FID VER is currently always 0 today, and I'd like to move into the high 32 bits of name[1] along with the 32-bit OID, to avoid consuming the name[2] field. The new encoding would be equivalent to the following: > > name[0] = fid_seq(fid); > name[1] = ((__u64)fid_ver(fid) << 32) | fid_ver(fid); Typo: name[1] = ((__u64)fid_ver(fid) << 32 | fid_oid(fid)); > name[2] = 0; > name[3] = { name hash for pdirops } > > but using the "fid_ver_oid(fid)" macro that is also doing something similar to encode the FID into the 64-bit "o_id" and "o_gr" fields of struct obdo and elsewhere in the OST protocol. Since fid_ver(fid) is always zero, it doesn't really matter where we encode it today, since it doesn't affect the resulting DLM lock resource name or cause any interoperability issues, but allows more flexibility in the future. > > Since future use of the FID version (intended for snapshots and datasets within a single Lustre filesystem) will need changes on the client side anyway, there should never be non-zero VER seen by an older client. > > A patch to do this has been submitted to Gerrit master with: > > Change-Id: If1e500cfb277dfc25bc056bb0c5763e48e7dccdf > > I intend to land a similar patch for b1_8 and b2_1, but I'd like to verify that nobody is using the FID version, nor plans to use it in the near future (i.e. in the next couple of years). > > Cheers, Andreas > -- > Andreas Dilger Whamcloud, Inc. > Principal Lustre Engineer http://www.whamcloud.com/ > > > From tao.peng at emc.com Fri Mar 9 16:23:38 2012 From: tao.peng at emc.com (tao.peng at emc.com) Date: Fri, 9 Mar 2012 11:23:38 -0500 Subject: [Lustre-devel] [wc-discuss] Re: oldest lustre supported SUSE kernel In-Reply-To: References: <9C0BB3E3-D296-42A0-89EA-67F299215215@whamcloud.com> , Message-ID: ________________________________________ From: James Simmons [jsimmons at infradead.org] Sent: Friday, March 09, 2012 8:56 PM To: Peng, Tao Cc: adilger at whamcloud.com; wc-discuss at whamcloud.com; lustre-devel at lists.lustre.org Subject: [wc-discuss] Re: [Lustre-devel] oldest lustre supported SUSE kernel > > As you can tell, we do not build the SLES11 SP0 client ourselves automatically, only the SP1 client, > > but if the effort is not huge it would be preferable to keep this client working. We typically try to > > keep the range of working clients as large as possible, since administrators may not have as much > > control over the running clients as they do over the servers. > > > > I would guess (without having looked at the SP0 kernel) that it may just be possible to change > > lustre/autoconf/lustre-core.m4 to check this prototype, and move the two ll_page_mkwrite() helpers > > into their own "#ifdef HAVE_PAGE_MKWRITE_VM_FAULT" section separate from HAVE_VM_OP_FAULT. > Thanks for confirming that it is still supported. And I verified it can be fixed as you described. I created LU-1200 and attached the fix there. Sorry to nit pick but can you push your patch with gerrit instead of just posting it to the Jira ticket. [PT] Here it is: http://review.whamcloud.com/#change,2277 From hashir.kidwai at gmail.com Fri Mar 9 10:24:56 2012 From: hashir.kidwai at gmail.com (Hashir Kidwai) Date: Fri, 9 Mar 2012 14:24:56 +0400 Subject: [Lustre-devel] Problems in installing Lustre Client in OpenSuse-12.1 Desktop Message-ID: Hello, I have posted this question on wc discussion forum but no response as of yet, So I thought may be able to get some help from somebody from lustre group or Mr. Adilger. Your help will highly be appreciated. Thanks Original Message: Hello, I have setup MGS and OSS on RHEL 6.2 without much problem. For client, when I tried to install the rpms on OpenSuSe machine especially lustre-client-module, it gave me tons of error. I think I need some extra modules to support that. Here is the detailed output when I am trying to install lustre-client-module. At the end, I am also forwarding you the output of uname -a Linux OpenSuSe-LustreClient 3.1.9-1.4-desktop.. ---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- rpm -ivh lustre-client-modules-2.1.56-2.6.32.36_0.5_default_ gbc5b01b.x86_64.rpm error: Failed dependencies: kernel(default:kernel_sched) = 791cbfea55486180 is needed by lustre-client-modules-2.1.56-2.6.32.36_0.5_default_gbc5b01b.x86_64 kernel(default:kernel_sched) = a1e405adbae82281 is needed by lustre-client-modules-2.1.56-2.6.32.36_0.5_default_gbc5b01b.x86_64 kernel(default:kernel_params) = 7a2a1002ec0a9ea5 is needed by lustre-client-modules-2.1.56-2.6.32.36_0.5_default_gbc5b01b.x86_64 kernel(default:fs_namei) = 30fe80ecd377a069 is needed by lustre-client-modules-2.1.56-2.6.32.36_0.5_default_gbc5b01b.x86_64 kernel(default:kernel_rcutree) = 8dd75c6c1874174c is needed by lustre-client-modules-2.1.56-2.6.32.36_0.5_default_gbc5b01b.x86_64 kernel(default:kernel_mutex) = bb7ac1f8989b9c06 is needed by lustre-client-modules-2.1.56-2.6.32.36_0.5_default_gbc5b01b.x86_64 kernel(default:net_socket) = 0a59dbccc880b786 is needed by lustre-client-modules-2.1.56-2.6.32.36_0.5_default_gbc5b01b.x86_64 kernel(default:kernel_groups) = 959302627b7c04dd is needed by lustre-client-modules-2.1.56-2.6.32.36_0.5_default_gbc5b01b.x86_64 kernel(default:kernel_semaphore) = c7a91f1e83a87245 is needed by lustre-client-modules-2.1.56-2.6.32.36_0.5_default_gbc5b01b.x86_64 kernel(default:mm_mempolicy) = dd136c5f866f6c61 is needed by lustre-client-modules-2.1.56-2.6.32.36_0.5_default_gbc5b01b.x86_64 kernel(default:kernel_module) = 880f9f607cb46b02 is needed by lustre-client-modules-2.1.56-2.6.32.36_0.5_default_gbc5b01b.x86_64 kernel(default:security_security) = 5e4f124bba3917ac is needed by lustre-client-modules-2.1.56-2.6.32.36_0.5_default_gbc5b01b.x86_64 kernel(default:arch_x86_kernel_pci-dma) = 30a88bbabf8b66bc is needed by lustre-client-modules-2.1.56-2.6.32.36_0.5_default_gbc5b01b.x86_64 kernel(default:kernel_wait) = e8f53b6be41ec496 is needed by lustre-client-modules-2.1.56-2.6.32.36_0.5_default_gbc5b01b.x86_64 kernel(default:kernel_spinlock) = c587e1beb0442cf5 is needed by lustre-client-modules-2.1.56-2.6.32.36_0.5_default_gbc5b01b.x86_64 kernel(default:kernel_notifier) = d919c1e55b213d77 is needed by lustre-client-modules-2.1.56-2.6.32.36_0.5_default_gbc5b01b.x86_64 kernel(default:mm_slab) = 9da45783fcbf9f27 is needed by lustre-client-modules-2.1.56-2.6.32.36_0.5_default_gbc5b01b.x86_64 kernel(default:mm_page-writeback) = 8e235d985265075d is needed by lustre-client-modules-2.1.56-2.6.32.36_0.5_default_gbc5b01b.x86_64 kernel(default:kernel_time_timekeeping) = 8aaa55bd59b5c923 is needed by lustre-client-modules-2.1.56-2.6.32.36_0.5_default_gbc5b01b.x86_64 kernel(default:vmlinux) = 1b24bf78f91075a8 is needed by lustre-client-modules-2.1.56-2.6.32.36_0.5_default_gbc5b01b.x86_64 kernel(default:kernel_sysctl) = cfe229e69011b3f0 is needed by lustre-client-modules-2.1.56-2.6.32.36_0.5_default_gbc5b01b.x86_64 kernel(default:fs_attr) = 101b09ed17b0d1a9 is needed by lustre-client-modules-2.1.56-2.6.32.36_0.5_default_gbc5b01b.x86_64 kernel(default:drivers_char_misc) = add3ab5011e8f953 is needed by lustre-client-modules-2.1.56-2.6.32.36_0.5_default_gbc5b01b.x86_64 kernel(default:arch_x86_kernel_x8664_ksyms_64) = d9438c557e2a3e44 is needed by lustre-client-modules-2.1.56-2.6.32.36_0.5_default_gbc5b01b.x86_64 kernel(default:kernel_rwsem) = ee607b7f03367958 is needed by lustre-client-modules-2.1.56-2.6.32.36_0.5_default_gbc5b01b.x86_64 kernel(default:mm_memory) = 51b4da23e3e0862b is needed by lustre-client-modules-2.1.56-2.6.32.36_0.5_default_gbc5b01b.x86_64 kernel(default:net_core_net_namespace) = f0d903ca76dcece1 is needed by lustre-client-modules-2.1.56-2.6.32.36_0.5_default_gbc5b01b.x86_64 kernel(default:fs_inode) = 24babd1a7925913a is needed by lustre-client-modules-2.1.56-2.6.32.36_0.5_default_gbc5b01b.x86_64 kernel(default:mm_backing-dev) = 2169b86970b6e0f8 is needed by lustre-client-modules-2.1.56-2.6.32.36_0.5_default_gbc5b01b.x86_64 kernel(default:net_core_dev) = 25fc19fd2401d3cd is needed by lustre-client-modules-2.1.56-2.6.32.36_0.5_default_gbc5b01b.x86_64 kernel(default:net_core_dev) = 5adcf4ca1d2aba8a is needed by lustre-client-modules-2.1.56-2.6.32.36_0.5_default_gbc5b01b.x86_64 kernel(default:net_core_dev) = 8eae736efd27a783 is needed by lustre-client-modules-2.1.56-2.6.32.36_0.5_default_gbc5b01b.x86_64 kernel(default:drivers_infiniband_core_rdma_cm) = aa071d38cd11b1e1 is needed by lustre-client-modules-2.1.56-2.6.32.36_0.5_default_gbc5b01b.x86_64 kernel(default:fs_dcache) = e434d61a4b926724 is needed by lustre-client-modules-2.1.56-2.6.32.36_0.5_default_gbc5b01b.x86_64 kernel(default:fs_dcache) = ec172b9bcc287237 is needed by lustre-client-modules-2.1.56-2.6.32.36_0.5_default_gbc5b01b.x86_64 kernel(default:drivers_infiniband_core_ib_core) = b57a38097948c5c5 is needed by lustre-client-modules-2.1.56-2.6.32.36_0.5_default_gbc5b01b.x86_64 kernel(default:mm_filemap) = a3014e0cdcdb8bf3 is needed by lustre-client-modules-2.1.56-2.6.32.36_0.5_default_gbc5b01b.x86_64 kernel(default:mm_vmalloc) = 2ad90ab141f0dae4 is needed by lustre-client-modules-2.1.56-2.6.32.36_0.5_default_gbc5b01b.x86_64 kernel(default:arch_x86_kernel_setup_percpu) = c156e98ddda16670 is needed by lustre-client-modules-2.1.56-2.6.32.36_0.5_default_gbc5b01b.x86_64 kernel(default:lib_kernel_lock) = 33d46f710a4cfe1b is needed by lustre-client-modules-2.1.56-2.6.32.36_0.5_default_gbc5b01b.x86_64 kernel(default:fs_bio) = b54205c84b13a61e is needed by lustre-client-modules-2.1.56-2.6.32.36_0.5_default_gbc5b01b.x86_64 kernel(default:mm_truncate) = b003dc367ed3a653 is needed by lustre-client-modules-2.1.56-2.6.32.36_0.5_default_gbc5b01b.x86_64 kernel(default:fs_fs-writeback) = 7502f6ab6a5c5b66 is needed by lustre-client-modules-2.1.56-2.6.32.36_0.5_default_gbc5b01b.x86_64 kernel(default:fs_fs-writeback) = ae3fb46c691f9a12 is needed by lustre-client-modules-2.1.56-2.6.32.36_0.5_default_gbc5b01b.x86_64 kernel(default:fs_readdir) = 0e53cc462830d044 is needed by lustre-client-modules-2.1.56-2.6.32.36_0.5_default_gbc5b01b.x86_64 kernel(default:fs_filesystems) = 67240f0d05f9e578 is needed by lustre-client-modules-2.1.56-2.6.32.36_0.5_default_gbc5b01b.x86_64 kernel(default:lib_scatterlist) = 9b045ae386606954 is needed by lustre-client-modules-2.1.56-2.6.32.36_0.5_default_gbc5b01b.x86_64 kernel(default:fs_block_dev) = d2f3cd44d25afda3 is needed by lustre-client-modules-2.1.56-2.6.32.36_0.5_default_gbc5b01b.x86_64 kernel(default:fs_block_dev) = fdb82054c673d6a6 is needed by lustre-client-modules-2.1.56-2.6.32.36_0.5_default_gbc5b01b.x86_64 kernel(default:fs_seq_file) = 43506c78f6743a4d is needed by lustre-client-modules-2.1.56-2.6.32.36_0.5_default_gbc5b01b.x86_64 kernel(default:fs_xattr_acl) = 128b7054b0e8984b is needed by lustre-client-modules-2.1.56-2.6.32.36_0.5_default_gbc5b01b.x86_64 kernel(default:mm_page_alloc) = dce861bddf347db6 is needed by lustre-client-modules-2.1.56-2.6.32.36_0.5_default_gbc5b01b.x86_64 kernel(default:mm_vmscan) = a5ca7732022b4e60 is needed by lustre-client-modules-2.1.56-2.6.32.36_0.5_default_gbc5b01b.x86_64 kernel(default:fs_libfs) = e223757ef9dd5570 is needed by lustre-client-modules-2.1.56-2.6.32.36_0.5_default_gbc5b01b.x86_64 kernel(default:kernel_timer) = 5941964e823d8cb1 is needed by lustre-client-modules-2.1.56-2.6.32.36_0.5_default_gbc5b01b.x86_64 kernel(default:fs_buffer) = 6826b544e30ab74b is needed by lustre-client-modules-2.1.56-2.6.32.36_0.5_default_gbc5b01b.x86_64 kernel(default:crypto_crypto) = 611f46aa74d07b90 is needed by lustre-client-modules-2.1.56-2.6.32.36_0.5_default_gbc5b01b.x86_64 kernel(default:lib_bitmap) = 3f8c8adcfa3a36c9 is needed by lustre-client-modules-2.1.56-2.6.32.36_0.5_default_gbc5b01b.x86_64 kernel(default:block_blk-core) = 872969f718d39b5e is needed by lustre-client-modules-2.1.56-2.6.32.36_0.5_default_gbc5b01b.x86_64 kernel(default:fs_super) = 93ae87afd84e7ea2 is needed by lustre-client-modules-2.1.56-2.6.32.36_0.5_default_gbc5b01b.x86_64 kernel(default:kernel_kmod) = 6441ed6e66c21a1a is needed by lustre-client-modules-2.1.56-2.6.32.36_0.5_default_gbc5b01b.x86_64 kernel(default:block_genhd) = 3572ca2b23c77dfc is needed by lustre-client-modules-2.1.56-2.6.32.36_0.5_default_gbc5b01b.x86_64 kernel(default:fs_bad_inode) = d8a4e490116aa67a is needed by lustre-client-modules-2.1.56-2.6.32.36_0.5_default_gbc5b01b.x86_64 kernel(default:fs_open) = 198debd2f21444b8 is needed by lustre-client-modules-2.1.56-2.6.32.36_0.5_default_gbc5b01b.x86_64 kernel(default:block_blk-settings) = 341a6647981e07ba is needed by lustre-client-modules-2.1.56-2.6.32.36_0.5_default_gbc5b01b.x86_64 kernel(default:kernel_exit) = 6db9554c1d7b11eb is needed by lustre-client-modules-2.1.56-2.6.32.36_0.5_default_gbc5b01b.x86_64 kernel(default:arch_x86_kernel_cpu_common) = 6d1b028ce9beaefc is needed by lustre-client-modules-2.1.56-2.6.32.36_0.5_default_gbc5b01b.x86_64 kernel(default:mm_swap) = 88a8162f9abe7d55 is needed by lustre-client-modules-2.1.56-2.6.32.36_0.5_default_gbc5b01b.x86_64 kernel(default:fs_proc_proc) = 917b4d08ced27e78 is needed by lustre-client-modules-2.1.56-2.6.32.36_0.5_default_gbc5b01b.x86_64 kernel(default:net_ipv4_tcp) = cb5a71429fa93a60 is needed by lustre-client-modules-2.1.56-2.6.32.36_0.5_default_gbc5b01b.x86_64 kernel(default:kernel_cpu) = 9932da9563d69df3 is needed by lustre-client-modules-2.1.56-2.6.32.36_0.5_default_gbc5b01b.x86_64 kernel(default:mm_mmap) = b136a840b56d702c is needed by lustre-client-modules-2.1.56-2.6.32.36_0.5_default_gbc5b01b.x86_64 kernel(default:drivers_char_random) = bf28b0770e45055d is needed by lustre-client-modules-2.1.56-2.6.32.36_0.5_default_gbc5b01b.x86_64 kernel(default:kernel_cred) = d995cbe8fed0f8ab is needed by lustre-client-modules-2.1.56-2.6.32.36_0.5_default_gbc5b01b.x86_64 kernel(default:kernel_time) = 5d18ecef0760c385 is needed by lustre-client-modules-2.1.56-2.6.32.36_0.5_default_gbc5b01b.x86_64 kernel(default:kernel_capability) = 21ae5dc41a677bfa is needed by lustre-client-modules-2.1.56-2.6.32.36_0.5_default_gbc5b01b.x86_64 kernel(default:kernel_printk) = 3103c42dd6130248 is needed by lustre-client-modules-2.1.56-2.6.32.36_0.5_default_gbc5b01b.x86_64 kernel(default:fs_splice) = 9dc8b91fc4a68a63 is needed by lustre-client-modules-2.1.56-2.6.32.36_0.5_default_gbc5b01b.x86_64 kernel(default:lib_crc32) = 6e9f350eb5653657 is needed by lustre-client-modules-2.1.56-2.6.32.36_0.5_default_gbc5b01b.x86_64 kernel(default:kernel_kthread) = 7029782ede167f56 is needed by lustre-client-modules-2.1.56-2.6.32.36_0.5_default_gbc5b01b.x86_64 kernel(default:net_core_sock) = bbcfc198996eada7 is needed by lustre-client-modules-2.1.56-2.6.32.36_0.5_default_gbc5b01b.x86_64 kernel(default:fs_posix_acl) = d6a84241c9773c17 is needed by lustre-client-modules-2.1.56-2.6.32.36_0.5_default_gbc5b01b.x86_64 kernel(default:fs_fs_struct) = 101435b45e21f61b is needed by lustre-client-modules-2.1.56-2.6.32.36_0.5_default_gbc5b01b.x86_64 kernel(default:arch_x86_kernel_dumpstack_64) = ab0b225b5f6a80ec is needed by lustre-client-modules-2.1.56-2.6.32.36_0.5_default_gbc5b01b.x86_64 kernel(default:kernel_rcupdate) = 128c23e7c44bd405 is needed by lustre-client-modules-2.1.56-2.6.32.36_0.5_default_gbc5b01b.x86_64 kernel(default:fs_file_table) = ede4f0edf5d79c89 is needed by lustre-client-modules-2.1.56-2.6.32.36_0.5_default_gbc5b01b.x86_64 kernel(default:fs_namespace) = 32b147b5a738f364 is needed by lustre-client-modules-2.1.56-2.6.32.36_0.5_default_gbc5b01b.x86_64 kernel(default:kernel_panic) = 244b172e2d8fbf2e is needed by lustre-client-modules-2.1.56-2.6.32.36_0.5_default_gbc5b01b.x86_64 kernel(default:arch_x86_kernel_setup) = 308273d3f2190526 is needed by lustre-client-modules-2.1.56-2.6.32.36_0.5_default_gbc5b01b.x86_64 kernel(default:kernel_kallsyms) = 2262b91c7b98f562 is needed by lustre-client-modules-2.1.56-2.6.32.36_0.5_default_gbc5b01b.x86_64 kernel(default:arch_x86_mm_physaddr) = 8a91ed3165f0c415 is needed by lustre-client-modules-2.1.56-2.6.32.36_0.5_default_gbc5b01b.x86_64 kernel(default:fs_locks) = 3da3278490dd705a is needed by lustre-client-modules-2.1.56-2.6.32.36_0.5_default_gbc5b01b.x86_64 kernel(default:arch_x86_kernel_apic_nmi) = b6436addaebf1b79 is needed by lustre-client-modules-2.1.56-2.6.32.36_0.5_default_gbc5b01b.x86_64 kernel(default:kernel_signal) = 66c029933b86f1d3 is needed by lustre-client-modules-2.1.56-2.6.32.36_0.5_default_gbc5b01b.x86_64 kernel(default:init_main) = 3dedb5c02e81849e is needed by lustre-client-modules-2.1.56-2.6.32.36_0.5_default_gbc5b01b.x86_64 -------------- next part -------------- An HTML attachment was scrubbed... URL: From jsimmons at infradead.org Fri Mar 9 17:49:03 2012 From: jsimmons at infradead.org (James Simmons) Date: Fri, 9 Mar 2012 17:49:03 +0000 (GMT) Subject: [Lustre-devel] Problems in installing Lustre Client in OpenSuse-12.1 Desktop In-Reply-To: References: Message-ID: > Hello, > I have setup MGS and OSS on RHEL 6.2 without much problem. For client, when I tried to install the rpms on OpenSuSe machine especially lustre-client-module, > it gave me tons of error. I think I need some extra modules to support that. Here is the detailed output when I am trying to install lustre-client-module. > At the end, I am also forwarding you the output of uname -a > > Linux OpenSuSe-LustreClient 3.1.9-1.4-desktop.. Where are you getting this rpm from? Can you post your rpm list of kernel packages? > ----------------------------------------------------------------------------------------------------------------------------------------------------------- > ----------------------------------------------------------------- > rpm -ivh lustre-client-modules-2.1.56-2.6.32.36_0.5_default_gbc5b01b.x86_64.rpm > error: Failed dependencies: >     kernel(default:kernel_sched) = 791cbfea55486180 is needed by lustre-client-modules-2.1.56-2.6.32.36_0.5_default_gbc5b01b.x86_64 >     kernel(default:kernel_sched) = a1e405adbae82281 is needed by lustre-client-modules-2.1.56-2.6.32.36_0.5_default_gbc5b01b.x86_64 >     kernel(default:kernel_params) = 7a2a1002ec0a9ea5 is needed by lustre-client-modules-2.1.56-2.6.32.36_0.5_default_gbc5b01b.x86_64 >     kernel(default:fs_namei) = 30fe80ecd377a069 is needed by lustre-client-modules-2.1.56-2.6.32.36_0.5_default_gbc5b01b.x86_64 >     kernel(default:kernel_rcutree) = 8dd75c6c1874174c is needed by lustre-client-modules-2.1.56-2.6.32.36_0.5_default_gbc5b01b.x86_64 >     kernel(default:kernel_mutex) = bb7ac1f8989b9c06 is needed by lustre-client-modules-2.1.56-2.6.32.36_0.5_default_gbc5b01b.x86_64 >     kernel(default:net_socket) = 0a59dbccc880b786 is needed by lustre-client-modules-2.1.56-2.6.32.36_0.5_default_gbc5b01b.x86_64 >     kernel(default:kernel_groups) = 959302627b7c04dd is needed by lustre-client-modules-2.1.56-2.6.32.36_0.5_default_gbc5b01b.x86_64 >     kernel(default:kernel_semaphore) = c7a91f1e83a87245 is needed by lustre-client-modules-2.1.56-2.6.32.36_0.5_default_gbc5b01b.x86_64 >     kernel(default:mm_mempolicy) = dd136c5f866f6c61 is needed by lustre-client-modules-2.1.56-2.6.32.36_0.5_default_gbc5b01b.x86_64 >     kernel(default:kernel_module) = 880f9f607cb46b02 is needed by lustre-client-modules-2.1.56-2.6.32.36_0.5_default_gbc5b01b.x86_64 >     kernel(default:security_security) = 5e4f124bba3917ac is needed by lustre-client-modules-2.1.56-2.6.32.36_0.5_default_gbc5b01b.x86_64 >     kernel(default:arch_x86_kernel_pci-dma) = 30a88bbabf8b66bc is needed by lustre-client-modules-2.1.56-2.6.32.36_0.5_default_gbc5b01b.x86_64 >     kernel(default:kernel_wait) = e8f53b6be41ec496 is needed by lustre-client-modules-2.1.56-2.6.32.36_0.5_default_gbc5b01b.x86_64 >     kernel(default:kernel_spinlock) = c587e1beb0442cf5 is needed by lustre-client-modules-2.1.56-2.6.32.36_0.5_default_gbc5b01b.x86_64 >     kernel(default:kernel_notifier) = d919c1e55b213d77 is needed by lustre-client-modules-2.1.56-2.6.32.36_0.5_default_gbc5b01b.x86_64 >     kernel(default:mm_slab) = 9da45783fcbf9f27 is needed by lustre-client-modules-2.1.56-2.6.32.36_0.5_default_gbc5b01b.x86_64 >     kernel(default:mm_page-writeback) = 8e235d985265075d is needed by lustre-client-modules-2.1.56-2.6.32.36_0.5_default_gbc5b01b.x86_64 >     kernel(default:kernel_time_timekeeping) = 8aaa55bd59b5c923 is needed by lustre-client-modules-2.1.56-2.6.32.36_0.5_default_gbc5b01b.x86_64 >     kernel(default:vmlinux) = 1b24bf78f91075a8 is needed by lustre-client-modules-2.1.56-2.6.32.36_0.5_default_gbc5b01b.x86_64 >     kernel(default:kernel_sysctl) = cfe229e69011b3f0 is needed by lustre-client-modules-2.1.56-2.6.32.36_0.5_default_gbc5b01b.x86_64 >     kernel(default:fs_attr) = 101b09ed17b0d1a9 is needed by lustre-client-modules-2.1.56-2.6.32.36_0.5_default_gbc5b01b.x86_64 >     kernel(default:drivers_char_misc) = add3ab5011e8f953 is needed by lustre-client-modules-2.1.56-2.6.32.36_0.5_default_gbc5b01b.x86_64 >     kernel(default:arch_x86_kernel_x8664_ksyms_64) = d9438c557e2a3e44 is needed by lustre-client-modules-2.1.56-2.6.32.36_0.5_default_gbc5b01b.x86_64 >     kernel(default:kernel_rwsem) = ee607b7f03367958 is needed by lustre-client-modules-2.1.56-2.6.32.36_0.5_default_gbc5b01b.x86_64 >     kernel(default:mm_memory) = 51b4da23e3e0862b is needed by lustre-client-modules-2.1.56-2.6.32.36_0.5_default_gbc5b01b.x86_64 >     kernel(default:net_core_net_namespace) = f0d903ca76dcece1 is needed by lustre-client-modules-2.1.56-2.6.32.36_0.5_default_gbc5b01b.x86_64 >     kernel(default:fs_inode) = 24babd1a7925913a is needed by lustre-client-modules-2.1.56-2.6.32.36_0.5_default_gbc5b01b.x86_64 >     kernel(default:mm_backing-dev) = 2169b86970b6e0f8 is needed by lustre-client-modules-2.1.56-2.6.32.36_0.5_default_gbc5b01b.x86_64 >     kernel(default:net_core_dev) = 25fc19fd2401d3cd is needed by lustre-client-modules-2.1.56-2.6.32.36_0.5_default_gbc5b01b.x86_64 >     kernel(default:net_core_dev) = 5adcf4ca1d2aba8a is needed by lustre-client-modules-2.1.56-2.6.32.36_0.5_default_gbc5b01b.x86_64 >     kernel(default:net_core_dev) = 8eae736efd27a783 is needed by lustre-client-modules-2.1.56-2.6.32.36_0.5_default_gbc5b01b.x86_64 >     kernel(default:drivers_infiniband_core_rdma_cm) = aa071d38cd11b1e1 is needed by lustre-client-modules-2.1.56-2.6.32.36_0.5_default_gbc5b01b.x86_64 >     kernel(default:fs_dcache) = e434d61a4b926724 is needed by lustre-client-modules-2.1.56-2.6.32.36_0.5_default_gbc5b01b.x86_64 >     kernel(default:fs_dcache) = ec172b9bcc287237 is needed by lustre-client-modules-2.1.56-2.6.32.36_0.5_default_gbc5b01b.x86_64 >     kernel(default:drivers_infiniband_core_ib_core) = b57a38097948c5c5 is needed by lustre-client-modules-2.1.56-2.6.32.36_0.5_default_gbc5b01b.x86_64 >     kernel(default:mm_filemap) = a3014e0cdcdb8bf3 is needed by lustre-client-modules-2.1.56-2.6.32.36_0.5_default_gbc5b01b.x86_64 >     kernel(default:mm_vmalloc) = 2ad90ab141f0dae4 is needed by lustre-client-modules-2.1.56-2.6.32.36_0.5_default_gbc5b01b.x86_64 >     kernel(default:arch_x86_kernel_setup_percpu) = c156e98ddda16670 is needed by lustre-client-modules-2.1.56-2.6.32.36_0.5_default_gbc5b01b.x86_64 >     kernel(default:lib_kernel_lock) = 33d46f710a4cfe1b is needed by lustre-client-modules-2.1.56-2.6.32.36_0.5_default_gbc5b01b.x86_64 >     kernel(default:fs_bio) = b54205c84b13a61e is needed by lustre-client-modules-2.1.56-2.6.32.36_0.5_default_gbc5b01b.x86_64 >     kernel(default:mm_truncate) = b003dc367ed3a653 is needed by lustre-client-modules-2.1.56-2.6.32.36_0.5_default_gbc5b01b.x86_64 >     kernel(default:fs_fs-writeback) = 7502f6ab6a5c5b66 is needed by lustre-client-modules-2.1.56-2.6.32.36_0.5_default_gbc5b01b.x86_64 >     kernel(default:fs_fs-writeback) = ae3fb46c691f9a12 is needed by lustre-client-modules-2.1.56-2.6.32.36_0.5_default_gbc5b01b.x86_64 >     kernel(default:fs_readdir) = 0e53cc462830d044 is needed by lustre-client-modules-2.1.56-2.6.32.36_0.5_default_gbc5b01b.x86_64 >     kernel(default:fs_filesystems) = 67240f0d05f9e578 is needed by lustre-client-modules-2.1.56-2.6.32.36_0.5_default_gbc5b01b.x86_64 >     kernel(default:lib_scatterlist) = 9b045ae386606954 is needed by lustre-client-modules-2.1.56-2.6.32.36_0.5_default_gbc5b01b.x86_64 >     kernel(default:fs_block_dev) = d2f3cd44d25afda3 is needed by lustre-client-modules-2.1.56-2.6.32.36_0.5_default_gbc5b01b.x86_64 >     kernel(default:fs_block_dev) = fdb82054c673d6a6 is needed by lustre-client-modules-2.1.56-2.6.32.36_0.5_default_gbc5b01b.x86_64 >     kernel(default:fs_seq_file) = 43506c78f6743a4d is needed by lustre-client-modules-2.1.56-2.6.32.36_0.5_default_gbc5b01b.x86_64 >     kernel(default:fs_xattr_acl) = 128b7054b0e8984b is needed by lustre-client-modules-2.1.56-2.6.32.36_0.5_default_gbc5b01b.x86_64 >     kernel(default:mm_page_alloc) = dce861bddf347db6 is needed by lustre-client-modules-2.1.56-2.6.32.36_0.5_default_gbc5b01b.x86_64 >     kernel(default:mm_vmscan) = a5ca7732022b4e60 is needed by lustre-client-modules-2.1.56-2.6.32.36_0.5_default_gbc5b01b.x86_64 >     kernel(default:fs_libfs) = e223757ef9dd5570 is needed by lustre-client-modules-2.1.56-2.6.32.36_0.5_default_gbc5b01b.x86_64 >     kernel(default:kernel_timer) = 5941964e823d8cb1 is needed by lustre-client-modules-2.1.56-2.6.32.36_0.5_default_gbc5b01b.x86_64 >     kernel(default:fs_buffer) = 6826b544e30ab74b is needed by lustre-client-modules-2.1.56-2.6.32.36_0.5_default_gbc5b01b.x86_64 >     kernel(default:crypto_crypto) = 611f46aa74d07b90 is needed by lustre-client-modules-2.1.56-2.6.32.36_0.5_default_gbc5b01b.x86_64 >     kernel(default:lib_bitmap) = 3f8c8adcfa3a36c9 is needed by lustre-client-modules-2.1.56-2.6.32.36_0.5_default_gbc5b01b.x86_64 >     kernel(default:block_blk-core) = 872969f718d39b5e is needed by lustre-client-modules-2.1.56-2.6.32.36_0.5_default_gbc5b01b.x86_64 >     kernel(default:fs_super) = 93ae87afd84e7ea2 is needed by lustre-client-modules-2.1.56-2.6.32.36_0.5_default_gbc5b01b.x86_64 >     kernel(default:kernel_kmod) = 6441ed6e66c21a1a is needed by lustre-client-modules-2.1.56-2.6.32.36_0.5_default_gbc5b01b.x86_64 >     kernel(default:block_genhd) = 3572ca2b23c77dfc is needed by lustre-client-modules-2.1.56-2.6.32.36_0.5_default_gbc5b01b.x86_64 >     kernel(default:fs_bad_inode) = d8a4e490116aa67a is needed by lustre-client-modules-2.1.56-2.6.32.36_0.5_default_gbc5b01b.x86_64 >     kernel(default:fs_open) = 198debd2f21444b8 is needed by lustre-client-modules-2.1.56-2.6.32.36_0.5_default_gbc5b01b.x86_64 >     kernel(default:block_blk-settings) = 341a6647981e07ba is needed by lustre-client-modules-2.1.56-2.6.32.36_0.5_default_gbc5b01b.x86_64 >     kernel(default:kernel_exit) = 6db9554c1d7b11eb is needed by lustre-client-modules-2.1.56-2.6.32.36_0.5_default_gbc5b01b.x86_64 >     kernel(default:arch_x86_kernel_cpu_common) = 6d1b028ce9beaefc is needed by lustre-client-modules-2.1.56-2.6.32.36_0.5_default_gbc5b01b.x86_64 >     kernel(default:mm_swap) = 88a8162f9abe7d55 is needed by lustre-client-modules-2.1.56-2.6.32.36_0.5_default_gbc5b01b.x86_64 >     kernel(default:fs_proc_proc) = 917b4d08ced27e78 is needed by lustre-client-modules-2.1.56-2.6.32.36_0.5_default_gbc5b01b.x86_64 >     kernel(default:net_ipv4_tcp) = cb5a71429fa93a60 is needed by lustre-client-modules-2.1.56-2.6.32.36_0.5_default_gbc5b01b.x86_64 >     kernel(default:kernel_cpu) = 9932da9563d69df3 is needed by lustre-client-modules-2.1.56-2.6.32.36_0.5_default_gbc5b01b.x86_64 >     kernel(default:mm_mmap) = b136a840b56d702c is needed by lustre-client-modules-2.1.56-2.6.32.36_0.5_default_gbc5b01b.x86_64 >     kernel(default:drivers_char_random) = bf28b0770e45055d is needed by lustre-client-modules-2.1.56-2.6.32.36_0.5_default_gbc5b01b.x86_64 >     kernel(default:kernel_cred) = d995cbe8fed0f8ab is needed by lustre-client-modules-2.1.56-2.6.32.36_0.5_default_gbc5b01b.x86_64 >     kernel(default:kernel_time) = 5d18ecef0760c385 is needed by lustre-client-modules-2.1.56-2.6.32.36_0.5_default_gbc5b01b.x86_64 >     kernel(default:kernel_capability) = 21ae5dc41a677bfa is needed by lustre-client-modules-2.1.56-2.6.32.36_0.5_default_gbc5b01b.x86_64 >     kernel(default:kernel_printk) = 3103c42dd6130248 is needed by lustre-client-modules-2.1.56-2.6.32.36_0.5_default_gbc5b01b.x86_64 >     kernel(default:fs_splice) = 9dc8b91fc4a68a63 is needed by lustre-client-modules-2.1.56-2.6.32.36_0.5_default_gbc5b01b.x86_64 >     kernel(default:lib_crc32) = 6e9f350eb5653657 is needed by lustre-client-modules-2.1.56-2.6.32.36_0.5_default_gbc5b01b.x86_64 >     kernel(default:kernel_kthread) = 7029782ede167f56 is needed by lustre-client-modules-2.1.56-2.6.32.36_0.5_default_gbc5b01b.x86_64 >     kernel(default:net_core_sock) = bbcfc198996eada7 is needed by lustre-client-modules-2.1.56-2.6.32.36_0.5_default_gbc5b01b.x86_64 >     kernel(default:fs_posix_acl) = d6a84241c9773c17 is needed by lustre-client-modules-2.1.56-2.6.32.36_0.5_default_gbc5b01b.x86_64 >     kernel(default:fs_fs_struct) = 101435b45e21f61b is needed by lustre-client-modules-2.1.56-2.6.32.36_0.5_default_gbc5b01b.x86_64 >     kernel(default:arch_x86_kernel_dumpstack_64) = ab0b225b5f6a80ec is needed by lustre-client-modules-2.1.56-2.6.32.36_0.5_default_gbc5b01b.x86_64 >     kernel(default:kernel_rcupdate) = 128c23e7c44bd405 is needed by lustre-client-modules-2.1.56-2.6.32.36_0.5_default_gbc5b01b.x86_64 >     kernel(default:fs_file_table) = ede4f0edf5d79c89 is needed by lustre-client-modules-2.1.56-2.6.32.36_0.5_default_gbc5b01b.x86_64 >     kernel(default:fs_namespace) = 32b147b5a738f364 is needed by lustre-client-modules-2.1.56-2.6.32.36_0.5_default_gbc5b01b.x86_64 >     kernel(default:kernel_panic) = 244b172e2d8fbf2e is needed by lustre-client-modules-2.1.56-2.6.32.36_0.5_default_gbc5b01b.x86_64 >     kernel(default:arch_x86_kernel_setup) = 308273d3f2190526 is needed by lustre-client-modules-2.1.56-2.6.32.36_0.5_default_gbc5b01b.x86_64 >     kernel(default:kernel_kallsyms) = 2262b91c7b98f562 is needed by lustre-client-modules-2.1.56-2.6.32.36_0.5_default_gbc5b01b.x86_64 >     kernel(default:arch_x86_mm_physaddr) = 8a91ed3165f0c415 is needed by lustre-client-modules-2.1.56-2.6.32.36_0.5_default_gbc5b01b.x86_64 >     kernel(default:fs_locks) = 3da3278490dd705a is needed by lustre-client-modules-2.1.56-2.6.32.36_0.5_default_gbc5b01b.x86_64 >     kernel(default:arch_x86_kernel_apic_nmi) = b6436addaebf1b79 is needed by lustre-client-modules-2.1.56-2.6.32.36_0.5_default_gbc5b01b.x86_64 >     kernel(default:kernel_signal) = 66c029933b86f1d3 is needed by lustre-client-modules-2.1.56-2.6.32.36_0.5_default_gbc5b01b.x86_64 >     kernel(default:init_main) = 3dedb5c02e81849e is needed by lustre-client-modules-2.1.56-2.6.32.36_0.5_default_gbc5b01b.x86_64 > > > From Nathan_Rutman at xyratex.com Fri Mar 9 18:48:40 2012 From: Nathan_Rutman at xyratex.com (Nathan Rutman) Date: Fri, 9 Mar 2012 10:48:40 -0800 Subject: [Lustre-devel] Changing FID->DLM lock encoding for version In-Reply-To: References: Message-ID: <73AED5C780AE05478241DB067651A92102F1087C@XYUS-EX22.xyus.xyratex.com> I don't think I have any problem with this -- Umka, the replicator uses the inode version, not the fid_ver, correct? On Mar 8, 2012, at 9:56 PM, Andreas Dilger wrote: > I'm planning to change the FID->DLM lock encoding for the FID "version" field in order to free up some space in the DLM lock resource (potentially for directory quotas, and other uses). > > Currently the FID is mapped into the DLM lock as follows: > > name[0] = fid_seq(fid); > name[1] = fid_oid(fid); > name[2] = fid_ver(fid); > name[3] = { name hash for pdirops } > > The 32-bit FID VER is currently always 0 today, and I'd like to move into the high 32 bits of name[1] along with the 32-bit OID, to avoid consuming the name[2] field. The new encoding would be equivalent to the following: > > name[0] = fid_seq(fid); > name[1] = ((__u64)fid_ver(fid) << 32) | fid_ver(fid); > name[2] = 0; > name[3] = { name hash for pdirops } > > but using the "fid_ver_oid(fid)" macro that is also doing something similar to encode the FID into the 64-bit "o_id" and "o_gr" fields of struct obdo and elsewhere in the OST protocol. Since fid_ver(fid) is always zero, it doesn't really matter where we encode it today, since it doesn't affect the resulting DLM lock resource name or cause any interoperability issues, but allows more flexibility in the future. > > Since future use of the FID version (intended for snapshots and datasets within a single Lustre filesystem) will need changes on the client side anyway, there should never be non-zero VER seen by an older client. > > A patch to do this has been submitted to Gerrit master with: > > Change-Id: If1e500cfb277dfc25bc056bb0c5763e48e7dccdf > > I intend to land a similar patch for b1_8 and b2_1, but I'd like to verify that nobody is using the FID version, nor plans to use it in the near future (i.e. in the next couple of years). > > Cheers, Andreas > -- > Andreas Dilger Whamcloud, Inc. > Principal Lustre Engineer http://www.whamcloud.com/ > > > > From hashir.kidwai at gmail.com Sat Mar 10 07:59:51 2012 From: hashir.kidwai at gmail.com (Hashir Kidwai) Date: Sat, 10 Mar 2012 11:59:51 +0400 Subject: [Lustre-devel] Problems in installing Lustre Client in OpenSuse-12.1 Desktop In-Reply-To: References: Message-ID: Hello James and all, Thanks for the response. I am getting the rpm from the following whamcloud public link. http://downloads.whamcloud.com/public/lustre/lustre-2.1.0/sles11/client/x86_64/ Please let me know, what is the work around? Thanks On Fri, Mar 9, 2012 at 9:49 PM, James Simmons wrote: > > > Hello, > > I have setup MGS and OSS on RHEL 6.2 without much problem. For client, > when I tried to install the rpms on OpenSuSe machine especially > lustre-client-module, > > it gave me tons of error. I think I need some extra modules to support > that. Here is the detailed output when I am trying to install > lustre-client-module. > > At the end, I am also forwarding you the output of uname -a > > > > Linux OpenSuSe-LustreClient 3.1.9-1.4-desktop.. > > Where are you getting this rpm from? Can you post your rpm list of kernel > packages? > > > > ----------------------------------------------------------------------------------------------------------------------------------------------------------- > > ----------------------------------------------------------------- > > rpm -ivh lustre-client-modules-2.1.56-2.6.32.36 > _0.5_default_gbc5b01b.x86_64.rpm > > error: Failed dependencies: > > kernel(default:kernel_sched) = 791cbfea55486180 is needed by > lustre-client-modules-2.1.56-2.6.32.36_0.5_default_gbc5b01b.x86_64 > > kernel(default:kernel_sched) = a1e405adbae82281 is needed by > lustre-client-modules-2.1.56-2.6.32.36_0.5_default_gbc5b01b.x86_64 > > kernel(default:kernel_params) = 7a2a1002ec0a9ea5 is needed by > lustre-client-modules-2.1.56-2.6.32.36_0.5_default_gbc5b01b.x86_64 > > kernel(default:fs_namei) = 30fe80ecd377a069 is needed by > lustre-client-modules-2.1.56-2.6.32.36_0.5_default_gbc5b01b.x86_64 > > kernel(default:kernel_rcutree) = 8dd75c6c1874174c is needed by > lustre-client-modules-2.1.56-2.6.32.36_0.5_default_gbc5b01b.x86_64 > > kernel(default:kernel_mutex) = bb7ac1f8989b9c06 is needed by > lustre-client-modules-2.1.56-2.6.32.36_0.5_default_gbc5b01b.x86_64 > > kernel(default:net_socket) = 0a59dbccc880b786 is needed by > lustre-client-modules-2.1.56-2.6.32.36_0.5_default_gbc5b01b.x86_64 > > kernel(default:kernel_groups) = 959302627b7c04dd is needed by > lustre-client-modules-2.1.56-2.6.32.36_0.5_default_gbc5b01b.x86_64 > > kernel(default:kernel_semaphore) = c7a91f1e83a87245 is needed by > lustre-client-modules-2.1.56-2.6.32.36_0.5_default_gbc5b01b.x86_64 > > kernel(default:mm_mempolicy) = dd136c5f866f6c61 is needed by > lustre-client-modules-2.1.56-2.6.32.36_0.5_default_gbc5b01b.x86_64 > > kernel(default:kernel_module) = 880f9f607cb46b02 is needed by > lustre-client-modules-2.1.56-2.6.32.36_0.5_default_gbc5b01b.x86_64 > > kernel(default:security_security) = 5e4f124bba3917ac is needed by > lustre-client-modules-2.1.56-2.6.32.36_0.5_default_gbc5b01b.x86_64 > > kernel(default:arch_x86_kernel_pci-dma) = 30a88bbabf8b66bc is needed > by lustre-client-modules-2.1.56-2.6.32.36_0.5_default_gbc5b01b.x86_64 > > kernel(default:kernel_wait) = e8f53b6be41ec496 is needed by > lustre-client-modules-2.1.56-2.6.32.36_0.5_default_gbc5b01b.x86_64 > > kernel(default:kernel_spinlock) = c587e1beb0442cf5 is needed by > lustre-client-modules-2.1.56-2.6.32.36_0.5_default_gbc5b01b.x86_64 > > kernel(default:kernel_notifier) = d919c1e55b213d77 is needed by > lustre-client-modules-2.1.56-2.6.32.36_0.5_default_gbc5b01b.x86_64 > > kernel(default:mm_slab) = 9da45783fcbf9f27 is needed by > lustre-client-modules-2.1.56-2.6.32.36_0.5_default_gbc5b01b.x86_64 > > kernel(default:mm_page-writeback) = 8e235d985265075d is needed by > lustre-client-modules-2.1.56-2.6.32.36_0.5_default_gbc5b01b.x86_64 > > kernel(default:kernel_time_timekeeping) = 8aaa55bd59b5c923 is needed > by lustre-client-modules-2.1.56-2.6.32.36_0.5_default_gbc5b01b.x86_64 > > kernel(default:vmlinux) = 1b24bf78f91075a8 is needed by > lustre-client-modules-2.1.56-2.6.32.36_0.5_default_gbc5b01b.x86_64 > > kernel(default:kernel_sysctl) = cfe229e69011b3f0 is needed by > lustre-client-modules-2.1.56-2.6.32.36_0.5_default_gbc5b01b.x86_64 > > kernel(default:fs_attr) = 101b09ed17b0d1a9 is needed by > lustre-client-modules-2.1.56-2.6.32.36_0.5_default_gbc5b01b.x86_64 > > kernel(default:drivers_char_misc) = add3ab5011e8f953 is needed by > lustre-client-modules-2.1.56-2.6.32.36_0.5_default_gbc5b01b.x86_64 > > kernel(default:arch_x86_kernel_x8664_ksyms_64) = d9438c557e2a3e44 is > needed by lustre-client-modules-2.1.56-2.6.32.36_0.5_default_gbc5b01b.x86_64 > > kernel(default:kernel_rwsem) = ee607b7f03367958 is needed by > lustre-client-modules-2.1.56-2.6.32.36_0.5_default_gbc5b01b.x86_64 > > kernel(default:mm_memory) = 51b4da23e3e0862b is needed by > lustre-client-modules-2.1.56-2.6.32.36_0.5_default_gbc5b01b.x86_64 > > kernel(default:net_core_net_namespace) = f0d903ca76dcece1 is needed > by lustre-client-modules-2.1.56-2.6.32.36_0.5_default_gbc5b01b.x86_64 > > kernel(default:fs_inode) = 24babd1a7925913a is needed by > lustre-client-modules-2.1.56-2.6.32.36_0.5_default_gbc5b01b.x86_64 > > kernel(default:mm_backing-dev) = 2169b86970b6e0f8 is needed by > lustre-client-modules-2.1.56-2.6.32.36_0.5_default_gbc5b01b.x86_64 > > kernel(default:net_core_dev) = 25fc19fd2401d3cd is needed by > lustre-client-modules-2.1.56-2.6.32.36_0.5_default_gbc5b01b.x86_64 > > kernel(default:net_core_dev) = 5adcf4ca1d2aba8a is needed by > lustre-client-modules-2.1.56-2.6.32.36_0.5_default_gbc5b01b.x86_64 > > kernel(default:net_core_dev) = 8eae736efd27a783 is needed by > lustre-client-modules-2.1.56-2.6.32.36_0.5_default_gbc5b01b.x86_64 > > kernel(default:drivers_infiniband_core_rdma_cm) = aa071d38cd11b1e1 > is needed by > lustre-client-modules-2.1.56-2.6.32.36_0.5_default_gbc5b01b.x86_64 > > kernel(default:fs_dcache) = e434d61a4b926724 is needed by > lustre-client-modules-2.1.56-2.6.32.36_0.5_default_gbc5b01b.x86_64 > > kernel(default:fs_dcache) = ec172b9bcc287237 is needed by > lustre-client-modules-2.1.56-2.6.32.36_0.5_default_gbc5b01b.x86_64 > > kernel(default:drivers_infiniband_core_ib_core) = b57a38097948c5c5 > is needed by > lustre-client-modules-2.1.56-2.6.32.36_0.5_default_gbc5b01b.x86_64 > > kernel(default:mm_filemap) = a3014e0cdcdb8bf3 is needed by > lustre-client-modules-2.1.56-2.6.32.36_0.5_default_gbc5b01b.x86_64 > > kernel(default:mm_vmalloc) = 2ad90ab141f0dae4 is needed by > lustre-client-modules-2.1.56-2.6.32.36_0.5_default_gbc5b01b.x86_64 > > kernel(default:arch_x86_kernel_setup_percpu) = c156e98ddda16670 is > needed by lustre-client-modules-2.1.56-2.6.32.36_0.5_default_gbc5b01b.x86_64 > > kernel(default:lib_kernel_lock) = 33d46f710a4cfe1b is needed by > lustre-client-modules-2.1.56-2.6.32.36_0.5_default_gbc5b01b.x86_64 > > kernel(default:fs_bio) = b54205c84b13a61e is needed by > lustre-client-modules-2.1.56-2.6.32.36_0.5_default_gbc5b01b.x86_64 > > kernel(default:mm_truncate) = b003dc367ed3a653 is needed by > lustre-client-modules-2.1.56-2.6.32.36_0.5_default_gbc5b01b.x86_64 > > kernel(default:fs_fs-writeback) = 7502f6ab6a5c5b66 is needed by > lustre-client-modules-2.1.56-2.6.32.36_0.5_default_gbc5b01b.x86_64 > > kernel(default:fs_fs-writeback) = ae3fb46c691f9a12 is needed by > lustre-client-modules-2.1.56-2.6.32.36_0.5_default_gbc5b01b.x86_64 > > kernel(default:fs_readdir) = 0e53cc462830d044 is needed by > lustre-client-modules-2.1.56-2.6.32.36_0.5_default_gbc5b01b.x86_64 > > kernel(default:fs_filesystems) = 67240f0d05f9e578 is needed by > lustre-client-modules-2.1.56-2.6.32.36_0.5_default_gbc5b01b.x86_64 > > kernel(default:lib_scatterlist) = 9b045ae386606954 is needed by > lustre-client-modules-2.1.56-2.6.32.36_0.5_default_gbc5b01b.x86_64 > > kernel(default:fs_block_dev) = d2f3cd44d25afda3 is needed by > lustre-client-modules-2.1.56-2.6.32.36_0.5_default_gbc5b01b.x86_64 > > kernel(default:fs_block_dev) = fdb82054c673d6a6 is needed by > lustre-client-modules-2.1.56-2.6.32.36_0.5_default_gbc5b01b.x86_64 > > kernel(default:fs_seq_file) = 43506c78f6743a4d is needed by > lustre-client-modules-2.1.56-2.6.32.36_0.5_default_gbc5b01b.x86_64 > > kernel(default:fs_xattr_acl) = 128b7054b0e8984b is needed by > lustre-client-modules-2.1.56-2.6.32.36_0.5_default_gbc5b01b.x86_64 > > kernel(default:mm_page_alloc) = dce861bddf347db6 is needed by > lustre-client-modules-2.1.56-2.6.32.36_0.5_default_gbc5b01b.x86_64 > > kernel(default:mm_vmscan) = a5ca7732022b4e60 is needed by > lustre-client-modules-2.1.56-2.6.32.36_0.5_default_gbc5b01b.x86_64 > > kernel(default:fs_libfs) = e223757ef9dd5570 is needed by > lustre-client-modules-2.1.56-2.6.32.36_0.5_default_gbc5b01b.x86_64 > > kernel(default:kernel_timer) = 5941964e823d8cb1 is needed by > lustre-client-modules-2.1.56-2.6.32.36_0.5_default_gbc5b01b.x86_64 > > kernel(default:fs_buffer) = 6826b544e30ab74b is needed by > lustre-client-modules-2.1.56-2.6.32.36_0.5_default_gbc5b01b.x86_64 > > kernel(default:crypto_crypto) = 611f46aa74d07b90 is needed by > lustre-client-modules-2.1.56-2.6.32.36_0.5_default_gbc5b01b.x86_64 > > kernel(default:lib_bitmap) = 3f8c8adcfa3a36c9 is needed by > lustre-client-modules-2.1.56-2.6.32.36_0.5_default_gbc5b01b.x86_64 > > kernel(default:block_blk-core) = 872969f718d39b5e is needed by > lustre-client-modules-2.1.56-2.6.32.36_0.5_default_gbc5b01b.x86_64 > > kernel(default:fs_super) = 93ae87afd84e7ea2 is needed by > lustre-client-modules-2.1.56-2.6.32.36_0.5_default_gbc5b01b.x86_64 > > kernel(default:kernel_kmod) = 6441ed6e66c21a1a is needed by > lustre-client-modules-2.1.56-2.6.32.36_0.5_default_gbc5b01b.x86_64 > > kernel(default:block_genhd) = 3572ca2b23c77dfc is needed by > lustre-client-modules-2.1.56-2.6.32.36_0.5_default_gbc5b01b.x86_64 > > kernel(default:fs_bad_inode) = d8a4e490116aa67a is needed by > lustre-client-modules-2.1.56-2.6.32.36_0.5_default_gbc5b01b.x86_64 > > kernel(default:fs_open) = 198debd2f21444b8 is needed by > lustre-client-modules-2.1.56-2.6.32.36_0.5_default_gbc5b01b.x86_64 > > kernel(default:block_blk-settings) = 341a6647981e07ba is needed by > lustre-client-modules-2.1.56-2.6.32.36_0.5_default_gbc5b01b.x86_64 > > kernel(default:kernel_exit) = 6db9554c1d7b11eb is needed by > lustre-client-modules-2.1.56-2.6.32.36_0.5_default_gbc5b01b.x86_64 > > kernel(default:arch_x86_kernel_cpu_common) = 6d1b028ce9beaefc is > needed by lustre-client-modules-2.1.56-2.6.32.36_0.5_default_gbc5b01b.x86_64 > > kernel(default:mm_swap) = 88a8162f9abe7d55 is needed by > lustre-client-modules-2.1.56-2.6.32.36_0.5_default_gbc5b01b.x86_64 > > kernel(default:fs_proc_proc) = 917b4d08ced27e78 is needed by > lustre-client-modules-2.1.56-2.6.32.36_0.5_default_gbc5b01b.x86_64 > > kernel(default:net_ipv4_tcp) = cb5a71429fa93a60 is needed by > lustre-client-modules-2.1.56-2.6.32.36_0.5_default_gbc5b01b.x86_64 > > kernel(default:kernel_cpu) = 9932da9563d69df3 is needed by > lustre-client-modules-2.1.56-2.6.32.36_0.5_default_gbc5b01b.x86_64 > > kernel(default:mm_mmap) = b136a840b56d702c is needed by > lustre-client-modules-2.1.56-2.6.32.36_0.5_default_gbc5b01b.x86_64 > > kernel(default:drivers_char_random) = bf28b0770e45055d is needed by > lustre-client-modules-2.1.56-2.6.32.36_0.5_default_gbc5b01b.x86_64 > > kernel(default:kernel_cred) = d995cbe8fed0f8ab is needed by > lustre-client-modules-2.1.56-2.6.32.36_0.5_default_gbc5b01b.x86_64 > > kernel(default:kernel_time) = 5d18ecef0760c385 is needed by > lustre-client-modules-2.1.56-2.6.32.36_0.5_default_gbc5b01b.x86_64 > > kernel(default:kernel_capability) = 21ae5dc41a677bfa is needed by > lustre-client-modules-2.1.56-2.6.32.36_0.5_default_gbc5b01b.x86_64 > > kernel(default:kernel_printk) = 3103c42dd6130248 is needed by > lustre-client-modules-2.1.56-2.6.32.36_0.5_default_gbc5b01b.x86_64 > > kernel(default:fs_splice) = 9dc8b91fc4a68a63 is needed by > lustre-client-modules-2.1.56-2.6.32.36_0.5_default_gbc5b01b.x86_64 > > kernel(default:lib_crc32) = 6e9f350eb5653657 is needed by > lustre-client-modules-2.1.56-2.6.32.36_0.5_default_gbc5b01b.x86_64 > > kernel(default:kernel_kthread) = 7029782ede167f56 is needed by > lustre-client-modules-2.1.56-2.6.32.36_0.5_default_gbc5b01b.x86_64 > > kernel(default:net_core_sock) = bbcfc198996eada7 is needed by > lustre-client-modules-2.1.56-2.6.32.36_0.5_default_gbc5b01b.x86_64 > > kernel(default:fs_posix_acl) = d6a84241c9773c17 is needed by > lustre-client-modules-2.1.56-2.6.32.36_0.5_default_gbc5b01b.x86_64 > > kernel(default:fs_fs_struct) = 101435b45e21f61b is needed by > lustre-client-modules-2.1.56-2.6.32.36_0.5_default_gbc5b01b.x86_64 > > kernel(default:arch_x86_kernel_dumpstack_64) = ab0b225b5f6a80ec is > needed by lustre-client-modules-2.1.56-2.6.32.36_0.5_default_gbc5b01b.x86_64 > > kernel(default:kernel_rcupdate) = 128c23e7c44bd405 is needed by > lustre-client-modules-2.1.56-2.6.32.36_0.5_default_gbc5b01b.x86_64 > > kernel(default:fs_file_table) = ede4f0edf5d79c89 is needed by > lustre-client-modules-2.1.56-2.6.32.36_0.5_default_gbc5b01b.x86_64 > > kernel(default:fs_namespace) = 32b147b5a738f364 is needed by > lustre-client-modules-2.1.56-2.6.32.36_0.5_default_gbc5b01b.x86_64 > > kernel(default:kernel_panic) = 244b172e2d8fbf2e is needed by > lustre-client-modules-2.1.56-2.6.32.36_0.5_default_gbc5b01b.x86_64 > > kernel(default:arch_x86_kernel_setup) = 308273d3f2190526 is needed > by lustre-client-modules-2.1.56-2.6.32.36_0.5_default_gbc5b01b.x86_64 > > kernel(default:kernel_kallsyms) = 2262b91c7b98f562 is needed by > lustre-client-modules-2.1.56-2.6.32.36_0.5_default_gbc5b01b.x86_64 > > kernel(default:arch_x86_mm_physaddr) = 8a91ed3165f0c415 is needed by > lustre-client-modules-2.1.56-2.6.32.36_0.5_default_gbc5b01b.x86_64 > > kernel(default:fs_locks) = 3da3278490dd705a is needed by > lustre-client-modules-2.1.56-2.6.32.36_0.5_default_gbc5b01b.x86_64 > > kernel(default:arch_x86_kernel_apic_nmi) = b6436addaebf1b79 is > needed by lustre-client-modules-2.1.56-2.6.32.36_0.5_default_gbc5b01b.x86_64 > > kernel(default:kernel_signal) = 66c029933b86f1d3 is needed by > lustre-client-modules-2.1.56-2.6.32.36_0.5_default_gbc5b01b.x86_64 > > kernel(default:init_main) = 3dedb5c02e81849e is needed by > lustre-client-modules-2.1.56-2.6.32.36_0.5_default_gbc5b01b.x86_64 > > > > > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From yuriy_umanets at xyratex.com Sat Mar 10 12:46:44 2012 From: yuriy_umanets at xyratex.com (Yuriy Umanets) Date: Sat, 10 Mar 2012 14:46:44 +0200 Subject: [Lustre-devel] Changing FID->DLM lock encoding for version In-Reply-To: <73AED5C780AE05478241DB067651A92102F1087C@XYUS-EX22.xyus.xyratex.com> References: <73AED5C780AE05478241DB067651A92102F1087C@XYUS-EX22.xyus.xyratex.com> Message-ID: <0FDB0AE9-5DB8-4011-9F2C-04B9EE7E7FD9@xyratex.com> On 9 Mar, 2012, at 20:48, Nathan Rutman wrote: > I don't think I have any problem with this -- Umka, the replicator uses the inode version, not the fid_ver, correct? We don't use any of those. Fine to change I think. > > > On Mar 8, 2012, at 9:56 PM, Andreas Dilger wrote: > >> I'm planning to change the FID->DLM lock encoding for the FID "version" field in order to free up some space in the DLM lock resource (potentially for directory quotas, and other uses). >> >> Currently the FID is mapped into the DLM lock as follows: >> >> name[0] = fid_seq(fid); >> name[1] = fid_oid(fid); >> name[2] = fid_ver(fid); >> name[3] = { name hash for pdirops } >> >> The 32-bit FID VER is currently always 0 today, and I'd like to move into the high 32 bits of name[1] along with the 32-bit OID, to avoid consuming the name[2] field. The new encoding would be equivalent to the following: >> >> name[0] = fid_seq(fid); >> name[1] = ((__u64)fid_ver(fid) << 32) | fid_ver(fid); >> name[2] = 0; >> name[3] = { name hash for pdirops } >> >> but using the "fid_ver_oid(fid)" macro that is also doing something similar to encode the FID into the 64-bit "o_id" and "o_gr" fields of struct obdo and elsewhere in the OST protocol. Since fid_ver(fid) is always zero, it doesn't really matter where we encode it today, since it doesn't affect the resulting DLM lock resource name or cause any interoperability issues, but allows more flexibility in the future. >> >> Since future use of the FID version (intended for snapshots and datasets within a single Lustre filesystem) will need changes on the client side anyway, there should never be non-zero VER seen by an older client. >> >> A patch to do this has been submitted to Gerrit master with: >> >> Change-Id: If1e500cfb277dfc25bc056bb0c5763e48e7dccdf >> >> I intend to land a similar patch for b1_8 and b2_1, but I'd like to verify that nobody is using the FID version, nor plans to use it in the near future (i.e. in the next couple of years). >> >> Cheers, Andreas >> -- >> Andreas Dilger Whamcloud, Inc. >> Principal Lustre Engineer http://www.whamcloud.com/ >> >> >> >> -- umka From adilger at whamcloud.com Thu Mar 15 00:31:29 2012 From: adilger at whamcloud.com (Andreas Dilger) Date: Wed, 14 Mar 2012 18:31:29 -0600 Subject: [Lustre-devel] Lustre and cross-platform portability Message-ID: <5609A4E0-2356-400F-9D53-F71B7007338C@whamcloud.com> Whamcloud and EMC are jointly investigating how to be able to contribute the Lustre client code into the upstream Linux kernel. As a prerequisite to this, EMC is working to clean up the Lustre client code to better match the kernel coding style, and one of the anticipated major obstacles to upstream kernel submission is the heavy use of code abstraction via libcfs for portability to other operating systems (most notably MacOS and WinNT, but also for liblustre, and potentially *BSD). I have no information that the WinNT project will ever be released by Oracle, and as yet there has not been any code released from the MacOS port, so the libcfs portability layer is potentially exacting a high cost in code maintenance and complexity (CLIO being a prime example) for no apparent benefit. Similarly, the liblustre client needs a portability layer for userspace, and suffers from the same apparent lack of interest or users. I'd like to get some feedback from the Lustre community about removing the libcfs abstraction entirely, or possibly restructuring it to look like the Linux kernel API, and having the other platforms code against it as a Linux portability layer, like ZFS on Linux uses the Solaris Portability Layer (SPL) to avoid changing the core ZFS code. A related topic is whether it would be better to replace all cfs_* functions with standard Linux kernel functions en-masse, or migrate away from cfs_* functions slowly? Also, we're planning on deprecating the liblustre client code, due to lack of interest/usage. The current code is in disrepair, and we've been keeping it around for years without any benefit, and while I was one of the strongest advocates for keeping it in our back pocket in case of future needs, I don't see that materializing in the future. The liblustre code would be left in the tree for now, in case someone from the community is interested to get it working and maintain it, and it may be updated on a best effort basis. If nobody steps forward to do this work, the liblustre code would be deleted from the development branch in a year or so. Unfortunately, after starting this thread, I may not be able to reply to questions in a timely manner due to vacation. I look forward to a thread that concludes with unanimous agreement from all parties. :-) Cheers, Andreas -- Andreas Dilger Whamcloud, Inc. Principal Lustre Engineer http://www.whamcloud.com/ From kenh at cmf.nrl.navy.mil Thu Mar 15 18:45:38 2012 From: kenh at cmf.nrl.navy.mil (Ken Hornstein) Date: Thu, 15 Mar 2012 14:45:38 -0400 Subject: [Lustre-devel] [Twg] Lustre and cross-platform portability In-Reply-To: <5609A4E0-2356-400F-9D53-F71B7007338C@whamcloud.com> Message-ID: <201203151845.q2FIjcXV029439@hedwig.cmf.nrl.navy.mil> >I have no information that the WinNT project will ever be released >by Oracle, and as yet there has not been any code released from the >MacOS port, so the libcfs portability layer is potentially exacting >a high cost in code maintenance and complexity (CLIO being a prime >example) for no apparent benefit. Similarly, the liblustre client needs >a portability layer for userspace, and suffers from the same apparent >lack of interest or users. In terms of the MacOS X port, I don't think that's quite fair ... the code I did is available and anyone can download it. It was functional in a very basic way but needed some additonal love. Okay, I haven't rolled that stuff into the Whamcloud release ... what happened there was when there was all the uncertainty with Oracle & Lustre development I lost momentum and got caught up in other things. I've talked with the guys at Whamcloud about bringing at least the portability changes over, and that's all been on me; it's certainly on my list to work on. I can say that at least for MacOS X, there has been interest; I can't speak for the amount of interest, and there's a bit of a chicken and egg problem ... people don't plan their Lustre use around MacOS X clients because there isn't one that works well, and people don't put work into it because there isn't people who plan their Lustre use around it. >I'd like to get some feedback from the Lustre community about removing >the libcfs abstraction entirely, or possibly restructuring it to look >like the Linux kernel API, and having the other platforms code against >it as a Linux portability layer, like ZFS on Linux uses the Solaris >Portability Layer (SPL) to avoid changing the core ZFS code. A related >topic is whether it would be better to replace all cfs_* functions with >standard Linux kernel functions en-masse, or migrate away from cfs_* >functions slowly? The only thing I can think of is that if this is done, then officially Lustre is going to be a Linux-only filesystem. I understand there are real costs to maintaining the cfs layer, and I can't speak to whether or not the loss would be worth the gains. --Ken From adilger at whamcloud.com Thu Mar 15 19:39:43 2012 From: adilger at whamcloud.com (Andreas Dilger) Date: Thu, 15 Mar 2012 13:39:43 -0600 Subject: [Lustre-devel] [Twg] Lustre and cross-platform portability In-Reply-To: <201203151845.q2FIjcXV029439@hedwig.cmf.nrl.navy.mil> References: <201203151845.q2FIjcXV029439@hedwig.cmf.nrl.navy.mil> Message-ID: On 2012-03-15, at 12:45 PM, Ken Hornstein wrote: >> I have no information that the WinNT project will ever be released >> by Oracle, and as yet there has not been any code released from the >> MacOS port, so the libcfs portability layer is potentially exacting >> a high cost in code maintenance and complexity (CLIO being a prime >> example) for no apparent benefit. Similarly, the liblustre client >> needs a portability layer for userspace, and suffers from the same >> apparent lack of interest or users. > > In terms of the MacOS X port, I don't think that's quite fair ... > the code I did is available and anyone can download it. Ken, my apologies for this misstatement. I guess that my faulty memory is to blame for the fact that I didn't recall the MacOS code was made publicly available for download. > It was > functional in a very basic way but needed some additonal love. > Okay, I haven't rolled that stuff into the Whamcloud release ... I don't think I've ever seen patches sent from you to either Oracle or Whamcloud, and unfortunately nobody on our side has had the bandwidth or user demand/funding to be pulling such changes either. > what happened there was when there was all the uncertainty with > Oracle & Lustre development I lost momentum and got caught up in > other things. I've talked with the guys at Whamcloud about bringing > at least the portability changes over, and that's all been on me; > it's certainly on my list to work on. > > I can say that at least for MacOS X, there has been interest; I can't > speak for the amount of interest, and there's a bit of a chicken and > egg problem ... people don't plan their Lustre use around MacOS X > clients because there isn't one that works well, and people don't put > work into it because there isn't people who plan their Lustre use > around it. Another alternative that has been proposed is FUSE for MacOS/Solaris. I'm not sure if FUSE exists for Windows or not. Of course, this is only useful for casual access, and not for high performance usage. >> I'd like to get some feedback from the Lustre community about removing >> the libcfs abstraction entirely, or possibly restructuring it to look >> like the Linux kernel API, and having the other platforms code against >> it as a Linux portability layer, like ZFS on Linux uses the Solaris >> Portability Layer (SPL) to avoid changing the core ZFS code. A related >> topic is whether it would be better to replace all cfs_* functions with >> standard Linux kernel functions en-masse, or migrate away from cfs_* >> functions slowly? > > The only thing I can think of is that if this is done, then officially > Lustre is going to be a Linux-only filesystem. I understand there are > real costs to maintaining the cfs layer, and I can't speak to whether or > not the loss would be worth the gains. This isn't strictly correct. It would be possible to change the libcfs portability layer to export the same API as the Linux kernel to MacOS and Windows. This would simplify getting the client into the Linux kernel, but still allow a native client on MacOS. I'm fine with keeping the abstraction layer if there is legitimate use for it. Having the MacOS client in the Lustre tree in a state where it can at least be built would allow us to make changes to the code (e.g. function renaming) with some chance of it not being totally broken immediately. Cheers, Andreas -- Andreas Dilger Whamcloud, Inc. Principal Lustre Engineer http://www.whamcloud.com/ From jjw at iu.edu Thu Mar 15 19:51:45 2012 From: jjw at iu.edu (Joshua Walgenbach) Date: Thu, 15 Mar 2012 15:51:45 -0400 Subject: [Lustre-devel] [Twg] Lustre and cross-platform portability In-Reply-To: References: <201203151845.q2FIjcXV029439@hedwig.cmf.nrl.navy.mil> Message-ID: <4F624851.6030707@iu.edu> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 03/15/2012 03:39 PM, Andreas Dilger wrote: > Another alternative that has been proposed is FUSE for > MacOS/Solaris. I'm not sure if FUSE exists for Windows or not. Of > course, this is only useful for casual access, and not for high > performance usage. > I think the FUSE for Windows project is defunct, but there is a user space filesystem project for Windows called Dokan (http://dokan-dev.net/en/) that had a release a little more than a year ago. For my part, a Lustre client on Windows or OS X would be used mostly for visualization of data, rather than being computed against so a slower user space implementation would be more than sufficient. There are a few applications that are using an SMB exported Lustre filesystem for data collection, but those applications are similarly low bandwidth. It would be nice to remove the SMB server in the middle. - -Josh - -- Joshua Walgenbach, High Performance File Systems, Indiana University -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.11 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAk9iSFEACgkQcqyJPuRTYp8dRgCePbaKA2P1Km80KBJM/YG6Nky1 8pgAn3RQW1i5omkhJfFZOG+0yhtXKJFB =08vB -----END PGP SIGNATURE----- From alexey_lyashkov at xyratex.com Fri Mar 16 10:35:42 2012 From: alexey_lyashkov at xyratex.com (Alexey Lyashkov) Date: Fri, 16 Mar 2012 14:35:42 +0400 Subject: [Lustre-devel] [wc-discuss] Re: [Twg] Lustre and cross-platform portability In-Reply-To: <4F6311CB.8040506@diamond.ac.uk> References: <201203151845.q2FIjcXV029439@hedwig.cmf.nrl.navy.mil> <4F624851.6030707@iu.edu> <4F6311CB.8040506@diamond.ac.uk> Message-ID: Windows don't have a good OFED port so we anyway will lost a performance. but using a full client will able to use a striping information and accept a data from a several OST's with comparing a get a single data stream from a SMB. Also fuse client will able to run on any OS have a FUSE porting that is any BSD, OpenSolaris, MacOS, in additional to the windows. That is easy way to maintain a single client for many OS. On Mar 16, 2012, at 14:11, Gregory Matthews wrote: > On 15/03/12 19:51, Joshua Walgenbach wrote: >> For my part, a Lustre client on Windows or OS X would be used mostly >> for visualization of data, rather than being computed against so a >> slower user space implementation would be more than sufficient. >> There are a few applications that are using an SMB exported Lustre >> filesystem for data collection, but those applications are similarly >> low bandwidth. It would be nice to remove the SMB server in the >> middle. > > why bother having a windows client if you lose the performance? We have > windows based detectors and proprietary windows based analysis software > that would definitely benefit from higher performance access to lustre > file systems but replacing existing CIFS servers for no gain seems a bit > pointless. > > I understand the problems that a native MS client would have, without > buy-in from Microsoft it would be a nightmare to keep the MS tree and > the Linux tree in sync. One possible future workaround proposed by > Whamcloud at last years LUG is pNFS. > > GREG > >> >> - -Josh > > > -- > Greg Matthews 01235 778658 > Senior Computer Systems Administrator > Diamond Light Source, Oxfordshire, UK > > -- > This e-mail and any attachments may contain confidential, copyright and or privileged material, and are for the use of the intended addressee only. If you are not the intended addressee or an authorised recipient of the addressee please notify us of receipt by returning the e-mail and do not use, copy, retain, distribute or disclose the information in or attached to the e-mail. > Any opinions expressed within this e-mail are those of the individual and not necessarily of Diamond Light Source Ltd. Diamond Light Source Ltd. cannot guarantee that this e-mail or any attachments are free from viruses and we cannot accept liability for any damage which you may sustain as a result of software viruses which may be transmitted in or with the message. > Diamond Light Source Limited (company no. 4375679). Registered in England and Wales with its registered office at Diamond House, Harwell Science and Innovation Campus, Didcot, Oxfordshire, OX11 0DE, United Kingdom > > > From kenh at cmf.nrl.navy.mil Fri Mar 16 14:38:27 2012 From: kenh at cmf.nrl.navy.mil (Ken Hornstein) Date: Fri, 16 Mar 2012 10:38:27 -0400 Subject: [Lustre-devel] [Twg] Lustre and cross-platform portability In-Reply-To: Message-ID: <201203161438.q2GEcSVL005257@hedwig.cmf.nrl.navy.mil> >Ken, my apologies for this misstatement. I guess that my faulty memory >is to blame for the fact that I didn't recall the MacOS code was made >publicly available for download. No problem. Back when I gave the talk at LUG the source wasn't available yet due to issues here, but we got that worked out and I was pushing my changes to a publically available Oracle git repo. I did send out email to everyone about that, but I'm sure it was easy to miss. >I don't think I've ever seen patches sent from you to either Oracle or >Whamcloud, and unfortunately nobody on our side has had the bandwidth or >user demand/funding to be pulling such changes either. Well, I did actually submit patches to Oracle to start the process of working out at least the portability issues, but I believe that was when Oracle started to implode the Lustre group so things sort of stalled. I'll take 75% of the blame for that if we assign 25% to Larry Ellison :-) >This isn't strictly correct. It would be possible to change the libcfs >portability layer to export the same API as the Linux kernel to MacOS >and Windows. This would simplify getting the client into the Linux >kernel, but still allow a native client on MacOS. Well ... that shifts the burden to cross-platform people basically having to re-implment the Linux kernel. For some things, that's possible without too much pain. For other things, it's not. --Ken From kenh at cmf.nrl.navy.mil Fri Mar 16 14:46:22 2012 From: kenh at cmf.nrl.navy.mil (Ken Hornstein) Date: Fri, 16 Mar 2012 10:46:22 -0400 Subject: [Lustre-devel] [wc-discuss] Re: [Twg] Lustre and cross-platform portability In-Reply-To: Message-ID: <201203161446.q2GEkNMO005460@hedwig.cmf.nrl.navy.mil> >Also fuse client will able to run on any OS have a FUSE porting that is >any BSD, OpenSolaris, MacOS, in additional to the windows. That is >easy way to maintain a single client for many OS. It is, unfortunately, not quite that simple. I can't claim to be a FUSE expert, but I've been paying attention to it on other platforms. From what I can tell, FUSE works great on Linux, but on other platforms the support is iffy. Also, it's not quite implemented the same on other operating systems as it is on Linux, making porting a Linux FUSE module to other platforms not trivial; from what I've seen, this is due to the Linux filesystem interface versus the vnode interface used by every Unix except Linux (and this is part of what makes Lustre hard to port). I guess what I'm saying is that don't fall into the underwear gnomes trap of thinking: 1) Get liblustre working with FUSE 2) ??? 3) Lustre client everywhere! It might make it easier, but I doubt it will make it easy. --Ken From lee at sandia.gov Fri Mar 16 16:03:36 2012 From: lee at sandia.gov (Ward, Lee) Date: Fri, 16 Mar 2012 16:03:36 +0000 Subject: [Lustre-devel] [EXTERNAL] Lustre and cross-platform portability In-Reply-To: <5609A4E0-2356-400F-9D53-F71B7007338C@whamcloud.com> References: <5609A4E0-2356-400F-9D53-F71B7007338C@whamcloud.com> Message-ID: On Mar 14, 2012, at 6:31 PM, Andreas Dilger wrote: > Whamcloud and EMC are jointly investigating how to be able to contribute the Lustre client code into the upstream Linux kernel. > > As a prerequisite to this, EMC is working to clean up the Lustre client code to better match the kernel coding style, and one of the anticipated major obstacles to upstream kernel submission is the heavy use of code abstraction via libcfs for portability to other operating systems (most notably MacOS and WinNT, but also for liblustre, and potentially *BSD). > > I have no information that the WinNT project will ever be released by Oracle, and as yet there has not been any code released from the MacOS port, so the libcfs portability layer is potentially exacting a high cost in code maintenance and complexity (CLIO being a prime example) for no apparent benefit. Similarly, the liblustre client needs a portability layer for userspace, and suffers from the same apparent lack of interest or users. > > I'd like to get some feedback from the Lustre community about removing the libcfs abstraction entirely, or possibly restructuring it to look like the Linux kernel API, and having the other platforms code against it as a Linux portability layer, like ZFS on Linux uses the Solaris Portability Layer (SPL) to avoid changing the core ZFS code. A related topic is whether it would be better to replace all cfs_* functions with standard Linux kernel functions en-masse, or migrate away from cfs_* functions slowly? > > Also, we're planning on deprecating the liblustre client code, due to lack of interest/usage. The current code is in disrepair, and we've been keeping it around for years without any benefit, and while I was one of the strongest advocates for keeping it in our back pocket in case of future needs, I don't see that materializing in the future. Relatively true I think, unfortunately. In the past, we provided direct support of Lustre for processes running on light-weight kernels via liblustre. I am aware that DOE/NNSA (more than just Sandia) believes light-weight kernels are the future but it seems that it may be quite a while, yet, before we would be forced into that choice. I don't see NNSA having some sort of heart-attack over your obfuscating liblustre then. --Lee > > The liblustre code would be left in the tree for now, in case someone from the community is interested to get it working and maintain it, and it may be updated on a best effort basis. If nobody steps forward to do this work, the liblustre code would be deleted from the development branch in a year or so. > > > Unfortunately, after starting this thread, I may not be able to reply to questions in a timely manner due to vacation. I look forward to a thread that concludes with unanimous agreement from all parties. :-) > > Cheers, Andreas > -- > Andreas Dilger Whamcloud, Inc. > Principal Lustre Engineer http://www.whamcloud.com/ > > > > > _______________________________________________ > Lustre-devel mailing list > Lustre-devel at lists.lustre.org > http://lists.lustre.org/mailman/listinfo/lustre-devel > From alexey_lyashkov at xyratex.com Sat Mar 17 10:42:48 2012 From: alexey_lyashkov at xyratex.com (Alexey Lyashkov) Date: Sat, 17 Mar 2012 14:42:48 +0400 Subject: [Lustre-devel] [wc-discuss] [Twg] Lustre and cross-platform portability In-Reply-To: <201203161446.q2GEkNMO005460@hedwig.cmf.nrl.navy.mil> References: <201203161446.q2GEkNMO005460@hedwig.cmf.nrl.navy.mil> Message-ID: Trust me. I (with two friends) write a FUSE client for a FreeBSD in past. Most issues related to a porting libcfs/libsysio to FreeBSD, but anyway patch isn''t huge ~200kb. I have plan to send that patch in near time, as 2.3 landing window open. On Mar 16, 2012, at 18:46, Ken Hornstein wrote: >> Also fuse client will able to run on any OS have a FUSE porting that is >> any BSD, OpenSolaris, MacOS, in additional to the windows. That is >> easy way to maintain a single client for many OS. > > It is, unfortunately, not quite that simple. > > I can't claim to be a FUSE expert, but I've been paying attention > to it on other platforms. From what I can tell, FUSE works great > on Linux, but on other platforms the support is iffy. Also, it's > not quite implemented the same on other operating systems as it is > on Linux, making porting a Linux FUSE module to other platforms not > trivial; from what I've seen, this is due to the Linux filesystem > interface versus the vnode interface used by every Unix except Linux > (and this is part of what makes Lustre hard to port). > > I guess what I'm saying is that don't fall into the underwear gnomes > trap of thinking: > > 1) Get liblustre working with FUSE > 2) ??? > 3) Lustre client everywhere! > > It might make it easier, but I doubt it will make it easy. > > --Ken From greg.matthews at diamond.ac.uk Fri Mar 16 10:11:23 2012 From: greg.matthews at diamond.ac.uk (Gregory Matthews) Date: Fri, 16 Mar 2012 10:11:23 +0000 Subject: [Lustre-devel] [wc-discuss] Re: [Twg] Lustre and cross-platform portability In-Reply-To: <4F624851.6030707@iu.edu> References: <201203151845.q2FIjcXV029439@hedwig.cmf.nrl.navy.mil> <4F624851.6030707@iu.edu> Message-ID: <4F6311CB.8040506@diamond.ac.uk> On 15/03/12 19:51, Joshua Walgenbach wrote: > For my part, a Lustre client on Windows or OS X would be used mostly > for visualization of data, rather than being computed against so a > slower user space implementation would be more than sufficient. > There are a few applications that are using an SMB exported Lustre > filesystem for data collection, but those applications are similarly > low bandwidth. It would be nice to remove the SMB server in the > middle. why bother having a windows client if you lose the performance? We have windows based detectors and proprietary windows based analysis software that would definitely benefit from higher performance access to lustre file systems but replacing existing CIFS servers for no gain seems a bit pointless. I understand the problems that a native MS client would have, without buy-in from Microsoft it would be a nightmare to keep the MS tree and the Linux tree in sync. One possible future workaround proposed by Whamcloud at last years LUG is pNFS. GREG > > - -Josh -- Greg Matthews 01235 778658 Senior Computer Systems Administrator Diamond Light Source, Oxfordshire, UK -- This e-mail and any attachments may contain confidential, copyright and or privileged material, and are for the use of the intended addressee only. If you are not the intended addressee or an authorised recipient of the addressee please notify us of receipt by returning the e-mail and do not use, copy, retain, distribute or disclose the information in or attached to the e-mail. Any opinions expressed within this e-mail are those of the individual and not necessarily of Diamond Light Source Ltd. Diamond Light Source Ltd. cannot guarantee that this e-mail or any attachments are free from viruses and we cannot accept liability for any damage which you may sustain as a result of software viruses which may be transmitted in or with the message. Diamond Light Source Limited (company no. 4375679). Registered in England and Wales with its registered office at Diamond House, Harwell Science and Innovation Campus, Didcot, Oxfordshire, OX11 0DE, United Kingdom From Allen.Todd at sig.com Fri Mar 16 15:06:04 2012 From: Allen.Todd at sig.com (Todd, Allen) Date: Fri, 16 Mar 2012 15:06:04 +0000 Subject: [Lustre-devel] [wc-discuss] Re: [Twg] Lustre and cross-platform portability In-Reply-To: <4F6311CB.8040506@diamond.ac.uk> References: <201203151845.q2FIjcXV029439@hedwig.cmf.nrl.navy.mil> <4F624851.6030707@iu.edu> <4F6311CB.8040506@diamond.ac.uk> Message-ID: <097F86FD722A2445B248BC51CC5DB88D1702BC@xchmbbal504.ds.susq.com> On Friday, March 16, 2012 6:11 AM, Gregory Matthews wrote: > why bother having a windows client if you lose the performance? We have > windows based detectors and proprietary windows based analysis software > that would definitely benefit from higher performance access to lustre > file systems but replacing existing CIFS servers for no gain seems a bit > pointless. >From the perspective of my firm, the benefit of a windows lustre client (native or fuse-based), even one that performs at 10% or 20% of the linux client, is the improved scalability that it offers. Our current solution uses 4 samba gateways per hundred windows servers to achieve acceptable bandwidth, but that bandwidth can be cut to an unacceptable trickle if a large wave of native linux clients simultaneously accesses the filesystem. We have repeatedly asked our Microsoft HPC contacts to intervene to either fund a native windows client or to get oracle to release the existing one, since scalable storage is a big hole in the Microsoft HPC toolkit. Obviously, nothing has come out of that. It seems Microsoft is banking on pNFS, eventually working in this space. Allen Todd ________________________________ IMPORTANT: The information contained in this email and/or its attachments is confidential. If you are not the intended recipient, please notify the sender immediately by reply and immediately delete this message and all its attachments. Any review, use, reproduction, disclosure or dissemination of this message or any attachment by an unintended recipient is strictly prohibited. Neither this message nor any attachment is intended as or should be construed as an offer, solicitation or recommendation to buy or sell any security or other financial instrument. Neither the sender, his or her employer nor any of their respective affiliates makes any warranties as to the completeness or accuracy of any of the information contained herein or that this message or any of its attachments is free of viruses. From Nathan_Rutman at xyratex.com Wed Mar 21 18:29:19 2012 From: Nathan_Rutman at xyratex.com (Nathan Rutman) Date: Wed, 21 Mar 2012 11:29:19 -0700 Subject: [Lustre-devel] [wc-discuss] Re: [Twg] Lustre and cross-platform portability In-Reply-To: <097F86FD722A2445B248BC51CC5DB88D1702BC@xchmbbal504.ds.susq.com> References: <201203151845.q2FIjcXV029439@hedwig.cmf.nrl.navy.mil> <4F624851.6030707@iu.edu> <4F6311CB.8040506@diamond.ac.uk> <097F86FD722A2445B248BC51CC5DB88D1702BC@xchmbbal504.ds.susq.com> Message-ID: <73AED5C780AE05478241DB067651A92102F108DF@XYUS-EX22.xyus.xyratex.com> On Mar 16, 2012, at 8:06 AM, Todd, Allen wrote: > > On Friday, March 16, 2012 6:11 AM, Gregory Matthews wrote: >> why bother having a windows client if you lose the performance? We have >> windows based detectors and proprietary windows based analysis software >> that would definitely benefit from higher performance access to lustre >> file systems but replacing existing CIFS servers for no gain seems a bit >> pointless. 1. Re-exporting Lustre via CIFS or NFS isn't scalable to very large numbers of Windows clients 2. Re-exporting Lustre via CIFS or NFS can have coherency problems when multiple re-exporters are involved 3. Wide-striped file access would likely have greater performance on a native client than via a re-exported single pipe, for some value of "wide". > >> From the perspective of my firm, the benefit of a windows lustre client (native or fuse-based), even one that performs at 10% or 20% of the linux client, is the improved scalability that it offers. Our current solution uses 4 samba gateways per hundred windows servers to achieve acceptable bandwidth, but that bandwidth can be cut to an unacceptable trickle if a large wave of native linux clients simultaneously accesses the filesystem. > > We have repeatedly asked our Microsoft HPC contacts to intervene to either fund a native windows client or to get oracle to release the existing one, since scalable storage is a big hole in the Microsoft HPC toolkit. Obviously, nothing has come out of that. It seems Microsoft is banking on pNFS, eventually working in this space. > > Allen Todd > > > > > ________________________________ > > IMPORTANT: The information contained in this email and/or its attachments is confidential. If you are not the intended recipient, please notify the sender immediately by reply and immediately delete this message and all its attachments. Any review, use, reproduction, disclosure or dissemination of this message or any attachment by an unintended recipient is strictly prohibited. Neither this message nor any attachment is intended as or should be construed as an offer, solicitation or recommendation to buy or sell any security or other financial instrument. Neither the sender, his or her employer nor any of their respective affiliates makes any warranties as to the completeness or accuracy of any of the information contained herein or that this message or any of its attachments is free of viruses. > _______________________________________________ > Lustre-devel mailing list > Lustre-devel at lists.lustre.org > http://lists.lustre.org/mailman/listinfo/lustre-devel From kelly.zhang at emc.com Thu Mar 22 08:08:54 2012 From: kelly.zhang at emc.com (kelly.zhang at emc.com) Date: Thu, 22 Mar 2012 04:08:54 -0400 Subject: [Lustre-devel] Some questions about Lustre test configuration Message-ID: Hi all, I have some questions about Lustre test configuration, would somebody help on this? Thanks a lot. 1. Seen from the test sets of Maloo, typically four nodes are used: "Client1, Client2, MDS1, OSS(includes 7 OSTs)". So in a normal regression testing, we can also follow this, right? When four nodes are used, what value do you set for the following two variables in file cfg/local.sh: mdsfailover_HOST and ostfailover_HOST 2. I see that in the PDF "Lustre 2.2 Test Plan", these are some links introducing about the test configuration. Like the following one: Regression Testing Use auster to run automated regression tests with the following configurations. http://wiki.whamcloud.com/display/ENG/Auster . But we failed to access this kind of link. Is this URL public to users outside Whamcloud? Thanks & Best Regards, Kelly Zhang(EMC) -------------- next part -------------- An HTML attachment was scrubbed... URL: From rread at whamcloud.com Thu Mar 22 17:28:11 2012 From: rread at whamcloud.com (Robert Read) Date: Thu, 22 Mar 2012 10:28:11 -0700 Subject: [Lustre-devel] [wc-discuss] Some questions about Lustre test configuration In-Reply-To: References: Message-ID: <165941E6-9AA2-490C-B5F1-04F75A8BE680@whamcloud.com> Hi, On Mar 22, 2012, at 1:08 , wrote: > Hi all, > > I have some questions about Lustre test configuration, would somebody help on this? Thanks a lot. > > 1. Seen from the test sets of Maloo, typically four nodes are used: “Client1, Client2, MDS1, OSS(includes 7 OSTs)”. > So in a normal regression testing, we can also follow this, right? > When four nodes are used, what value do you set for the following two variables in file cfg/local.sh: > mdsfailover_HOST and ostfailover_HOST In the this configuration, I believe the failover hosts should be set to nonfailover hosts: mdsfailover_HOST=${mds_HOST} ostfailover_HOST=${ost_HOST} This will allow the recovery tests to do simulated failover by ummounting and and mounting the targets on the same node to trigger Lustre recovery. > > 2. I see that in the PDF “Lustre 2.2 Test Plan”, these are some links introducing about the test configuration. Like the following one: > > Regression Testing > Use auster to run automated regression tests with the following configurations. > http://wiki.whamcloud.com/display/ENG/Auster . > > But we failed to access this kind of link. Is this URL public to users outside Whamcloud? It wasn't (oops), but I just moved it so it it is now accessible to everyone here: http://wiki.whamcloud.com/display/PUB/Auster cheers, robert > > Thanks & Best Regards, > Kelly Zhang(EMC) > -------------- next part -------------- An HTML attachment was scrubbed... URL: From kelly.zhang at emc.com Fri Mar 23 12:55:06 2012 From: kelly.zhang at emc.com (kelly.zhang at emc.com) Date: Fri, 23 Mar 2012 08:55:06 -0400 Subject: [Lustre-devel] [wc-discuss] Some questions about Lustre test configuration In-Reply-To: <165941E6-9AA2-490C-B5F1-04F75A8BE680@whamcloud.com> References: <165941E6-9AA2-490C-B5F1-04F75A8BE680@whamcloud.com> Message-ID: Got it. Thank you so much, Robert. Best Regards, Kelly Zhang(EMC) From: Robert Read [mailto:rread at whamcloud.com] Sent: 2012年3月23日 1:28 To: Zhang, Kelly Cc: wc-discuss at whamcloud.com; lustre-devel at lists.lustre.org; Tang, Haiying; Liu, Xuezhao; Peng, Tao Subject: Re: [wc-discuss] Some questions about Lustre test configuration Hi, On Mar 22, 2012, at 1:08 , > > wrote: Hi all, I have some questions about Lustre test configuration, would somebody help on this? Thanks a lot. 1. Seen from the test sets of Maloo, typically four nodes are used: “Client1, Client2, MDS1, OSS(includes 7 OSTs)”. So in a normal regression testing, we can also follow this, right? When four nodes are used, what value do you set for the following two variables in file cfg/local.sh: mdsfailover_HOST and ostfailover_HOST In the this configuration, I believe the failover hosts should be set to nonfailover hosts: mdsfailover_HOST=${mds_HOST} ostfailover_HOST=${ost_HOST} This will allow the recovery tests to do simulated failover by ummounting and and mounting the targets on the same node to trigger Lustre recovery. 2. I see that in the PDF “Lustre 2.2 Test Plan”, these are some links introducing about the test configuration. Like the following one: Regression Testing Use auster to run automated regression tests with the following configurations. http://wiki.whamcloud.com/display/ENG/Auster . But we failed to access this kind of link. Is this URL public to users outside Whamcloud? It wasn't (oops), but I just moved it so it it is now accessible to everyone here: http://wiki.whamcloud.com/display/PUB/Auster cheers, robert Thanks & Best Regards, Kelly Zhang(EMC) -------------- next part -------------- An HTML attachment was scrubbed... URL: From shay at opensfs.org Tue Mar 27 19:02:50 2012 From: shay at opensfs.org (Shay Seager) Date: Tue, 27 Mar 2012 09:02:50 -1000 Subject: [Lustre-devel] LUG is just around the corner, are you ready? Message-ID: Hello All, LUG 2012 is less than a month away; April 23rd-April 25th. We recommend you fly in Sunday April 22nd in the morning because we have some great events for you on Sunday: April 22, 2012 2:00-5:00pm the Benchmarking Work Group will be holding our first face to face meeting. The “Benchmarking Work Group” will focus on identifying and defining I/O workloads for the various Lustre markets, and then define IO generation benchmarking tools that best emulates those workloads. You are invited to help contribute to this important initiative. Pre LUG 2012 Party Sponsored by DataDirect Networks and Whamcloud The annual Lustre User Group is being held in Austin, TX, this year, with all the great Lustre developers, users and vendors in attendance. If you’re coming, you know some of the best connections are made outside of the talks. DDN and Whamcloud are providing beers & wine to help get it started. Come to Zax Restaurant & Bar, right next to the Hyatt Regency where LUG will be held, to kick off the week in a relaxed atmosphere. No hype, no pressure, just lots of local beers, wine and Lustre superstars. We’re closing the restaurant down, it’s just us from 7pm – 10pm. Hope to see you there! Location: Zax Restaurant & Bar 312 Barton Springs Rd, Austin, TX 78704 (across from the Hyatt Regency) Date/Time: Sun, April 22, 7-10pm RSVP: Are you kidding? Just come on by. On Wednesday we will also have 3 events hosted by OpenSFS, everyone is encouraged to attend, we recommend that you set your flights for Wednesday evening or Thursday morning (note, there are government rate rooms on Wednesday night, so book them now before they are all gone): 1pm – 2pm OpenSFS General Meeting 2pm-3pm OpenSFS Technical Working Group Meeting 3pm-4pm OpenSFS Community Development Working Group Meeting Check out our website for the whole program http://www.opensfs.org/lug/program If you have not registered your ticket, your hotel room, or your shuttle follow this link http://www.opensfs.org/lug/registration for all the resources you need to get discounted room rates and shuttle services. At LUG we will have 2 break out rooms that will be available 24-7 throughout the event and are available for private meetings and break-out sessions. Each room holds 20-30 people. If you would like to reserve room space, please reply to this e-mail (Shay Seager) with your preferred time/date. We want to make sure that this is the best LUG you have experienced, so please reply to this e-mail (to Shay Seager) to let us know if you have any dietary or special needs. (note - our menu already accommodates special diets such as vegan, vegetarian, paleo, and atkins) We also want to thank our generous sponsors: Bright Computing, Bull, Cray, DDN, Dell, EMC, Intel, Net App, RAID Inc., SGI, Terascala, Whamcloud, Xyratex. Best, Shay - - - Shay Seager Open SFS Secretary www.opensfs.org (925) 290-7641 shay at opensfs.org -------------- next part -------------- An HTML attachment was scrubbed... URL: From Roman_Grigoryev at xyratex.com Fri Mar 30 07:40:16 2012 From: Roman_Grigoryev at xyratex.com (Roman Grigoryev) Date: Fri, 30 Mar 2012 11:40:16 +0400 Subject: [Lustre-devel] [Twg] your opinion about testing improvements In-Reply-To: <4F745E90.2000001@xyratex.com> References: <4F745E90.2000001@xyratex.com> Message-ID: <4F756360.1000108@xyratex.com> (Sorry for cross posting, I haven't get answers in twg). Hi all, I'm working in testing team in Xyratex. After some time which I(and our team) have spent on testing and automation activities I would like try to ask community opinion about two problems and suggestion in testing. This not closed list of testing problems but I think it is good enough for start discussion. Problem 1 Currently Lustre and test are living in one code space and build in one time,and often have specific dependencies between test and code. This situation directly affect 1) interoperability testing between different version. (because testing is started from client which have different test framework then server and client remotely execute test framework as their own. just copying tests for equalization could not work with big difference between versions) 2) it is not simple execute(especially in automation) testing for test. F.e. a bug is fixed, the test on it added. Executing the test on an old revision(probably on a previous release) should show failed test result. But with big difference between versions where fixed and where execute test-framework can fail to start. Possible solution: split Lustre and lustre tests in code and build levels. It means that lustre and tests will not be connected on code revision, only by logic, f.e. via keywords. Also should be added in same time an abstraction level in test framework which allows to execute lustre utils from different version of lustre. Problem 2 (to avoid term problems, I call there: sanity = test suite, 130 = test, 130c and 130a = test cases) Different test cases, ended with letter(f.e. 130c), have an different idea of dependencies. Some test cases have dependences to previous test cases, some don't have. All they now can be executed with "ONLY" parameter and all they have separated item in result yaml file as just separated tests( which doesn't have test cases ended with letter, f.e. sanity 129). Also, tests which have testcases and don't have their own body can be execute with ONLY parameter( but doesn't have their special result). So, logically, all test which can be execute via using ONLY must be not depended to other tests. But we have test which depended. Moreover, some developers prefer to consider testcases as step of full one test. What is entities which I call "testcases" and "test" from your point of view? Answer of this question affect automated test execution and test development, and maybe ask some test-framework changes. -- Thanks, Roman