Re: [Lustre-discuss] New wc-discuss Lustre Mailing List
Hi, We've received feedback that some people are unwilling to join the wc-discuss list because they believe it requires using a gmail mail address. Luckily, this is not the case. It is possible to subscribe to wc-discuss (or any google group for that matter) using a non-gmail address. The key step is to to create a google (not gmail) account using your own email address. There are "create an account now links" on google login pages, or this link should take you to the sign up screen where you can use an already existing account: https://www.google.com/accounts/SignUpWidget Once created, your new account will work like any other web service account associated with your email address, and will allow you to sign up for google groups like wc-discuss. cheers, robert On Jun 29, 2011, at 12:01 , Andreas Dilger wrote: > Hi, > I'd like to announce the creation of a new mailing list for discussing > Lustre releases from Whamcloud. We will also continue to monitor and > participate on the existing lustre.org mailing lists, but we consider > it prudent to host a separate list from lustre.org due to uncertainty > regarding the long-term plans for lustre.org. > > Subscription information and archives are available at: > > https://groups.google.com/a/whamcloud.com/group/wc-discuss/ > > > Cheers, Andreas > -- > Andreas Dilger > Principal Engineer > Whamcloud, Inc. > > > > ___ > Lustre-discuss mailing list > Lustre-discuss@lists.lustre.org > http://lists.lustre.org/mailman/listinfo/lustre-discuss ___ Lustre-discuss mailing list Lustre-discuss@lists.lustre.org http://lists.lustre.org/mailman/listinfo/lustre-discuss
Re: [Lustre-discuss] Does lustre 1.8 stop update and maintenance?
Hi, I cannot comment about Oracle's plans regarding Lustre, but Whamcloud does intend to continue supporting 1.8.x for some time. You can see activity related to 1.8.x (as well as 2.1) in http://jira.whamcloud.com. cheers, robert read Whamcloud, Inc On Mar 1, 2011, at 4:48 , Larry wrote: > Hi, all > > Does lustre 1.8 stop update and maintenance? I have not seen any > updates for a long time. Only Whamcloud releases the Lustre 2.1. Does > it mean Oracle freeze the development of lustre? > ___ > Lustre-discuss mailing list > Lustre-discuss@lists.lustre.org > http://lists.lustre.org/mailman/listinfo/lustre-discuss ___ Lustre-discuss mailing list Lustre-discuss@lists.lustre.org http://lists.lustre.org/mailman/listinfo/lustre-discuss
Re: [Lustre-discuss] Lustre community build server
Hi, On Dec 16, 2010, at 9:42 , DEGREMONT Aurelien wrote: > Hi > > Robert Read a écrit : >> Hi Aurélien, >> >> Yes, we've noticed Hudson's support for testing is not quite what we need, >> so we're planning to use Hudson to trigger our testing system, but not >> necessarily to manage it. We'd definitely be interested in learning more >> about your experiences, though. > I do not know what you mean by triggering your testing system. But here is > what I set up. I mean that once the build is complete we will notify the test system that new build is ready to be picked up and tested. We haven't yet implemented that part of it. > Hudson has only 1 slave node dedicated to testing Lustre 2. > Hudson will launch a shell script through ssh to it. > > This script: > - retrieves Lustre source (managed by Hudson git plugin) > - compiles it. > - launches acceptance-small with several parameters. > - acceptance-small will connect to other nodes dedicated for these tests. > > acc-sm have been patched: > - to be more error resilient (does not stop at first failure) > - to generate a test report in JUNIT format. > > Hudson fetch the junit report and parse it thanks to its plugin. > Hudson can display in its interface all tests successes and failures. > > Everything goes fine as long as: > - the testsuite leaves the node in a good shape. It is difficult to have a > automatic way to put the node back. Currently, we need to manualy fix that. > - Hudson does not know about the other nodes used by acc-sm. And so can > trigger tests even if some sattelites nodes are unavailable. > > How is you do this on your side? We don't plan to use Hudson to manage our testing results as I don't think it would scale very well for all the testing we might do for each build. We're currently building a more custom results server that's similar (in spirit at least) to the kinds of tools we had at Oracle. We'll make it available once it's in presentable form. Actually, our first step was to replace the acceptance-small.sh driver script with one that has a more sensible user interface for running the standard tests. Since the test-framework.sh on master has already been changed to produce test results in yaml format, the new script collects these with the logs, and is capable of submitting them to the test results server. Currently this is being run manually, though. Automating the test execution and connecting all the pieces will be next step. cheers, robert > > > Aurélien > >> robert >> >> >> >> >> On Dec 16, 2010, at 1:22 , DEGREMONT Aurelien wrote: >> >> >>> Hi Robert, >>> >>> That's very interesting. >>> At CEA we also have a Hudson platform and I'm running acceptance-small for >>> several Lustre branches in it. Hudson is a great tool but it was not design >>> to test tools that run kernel-space that can crash your nodes or, at least, >>> put your kernel in a bad shape. I will be very interested to share Hudson >>> experience testing Lustre and see how you've configured it for your own >>> tests. >>> >>> >>> Aurélien >>> >>> Robert Read a écrit : >>> >>>> Hi, >>>> >>>> As I mentioned the other day, Whamcloud is hosting a Hudson build server >>>> and producing snapshot builds for Centos 5.x (and Ubuntu 10.4 when it >>>> works) for both 1.8.x and 2.x branches. Our intention is for this to be a >>>> resource for the Lustre community to find recent Lustre packages for >>>> variety of Linux distributions. Early next year we'll connect this to our >>>> test system so at least some of the packages can be tested, as well. >>>> >>>> We would be interested in hearing from anyone that would like to >>>> participate producing builds. Hudson is an distributed system, and it's >>>> easy to add more build nodes, even behind firewalls (some of us are >>>> running build VMs on our home machines). If you would like add another >>>> distribution or architecture we don't have yet, or even one we do have >>>> (the more the merrier), we'd be happy to work with you to do that. Please >>>> contact me if you are interested. cheers, >>>> robert >>>> >>>> >>>> >>>> >>>> ___ >>>> Lustre-discuss mailing list >>>> Lustre-discuss@lists.lustre.org >>>> http://lists.lustre.org/mailman/listinfo/lustre-discuss >>>> >> >> > ___ Lustre-discuss mailing list Lustre-discuss@lists.lustre.org http://lists.lustre.org/mailman/listinfo/lustre-discuss
Re: [Lustre-discuss] Lustre community build server
Hi Aurélien, Yes, we've noticed Hudson's support for testing is not quite what we need, so we're planning to use Hudson to trigger our testing system, but not necessarily to manage it. We'd definitely be interested in learning more about your experiences, though. robert On Dec 16, 2010, at 1:22 , DEGREMONT Aurelien wrote: > Hi Robert, > > That's very interesting. > At CEA we also have a Hudson platform and I'm running acceptance-small for > several Lustre branches in it. Hudson is a great tool but it was not design > to test tools that run kernel-space that can crash your nodes or, at least, > put your kernel in a bad shape. I will be very interested to share Hudson > experience testing Lustre and see how you've configured it for your own tests. > > > Aurélien > > Robert Read a écrit : >> Hi, >> >> As I mentioned the other day, Whamcloud is hosting a Hudson build server and >> producing snapshot builds for Centos 5.x (and Ubuntu 10.4 when it works) for >> both 1.8.x and 2.x branches. Our intention is for this to be a resource for >> the Lustre community to find recent Lustre packages for variety of Linux >> distributions. Early next year we'll connect this to our test system so at >> least some of the packages can be tested, as well. >> >> We would be interested in hearing from anyone that would like to participate >> producing builds. Hudson is an distributed system, and it's easy to add more >> build nodes, even behind firewalls (some of us are running build VMs on our >> home machines). If you would like add another distribution or architecture >> we don't have yet, or even one we do have (the more the merrier), we'd be >> happy to work with you to do that. Please contact me if you are interested. >> >> cheers, >> robert >> >> >> >> >> ___ >> Lustre-discuss mailing list >> Lustre-discuss@lists.lustre.org >> http://lists.lustre.org/mailman/listinfo/lustre-discuss >> > ___ Lustre-discuss mailing list Lustre-discuss@lists.lustre.org http://lists.lustre.org/mailman/listinfo/lustre-discuss
[Lustre-discuss] Lustre community build server
Hi, As I mentioned the other day, Whamcloud is hosting a Hudson build server and producing snapshot builds for Centos 5.x (and Ubuntu 10.4 when it works) for both 1.8.x and 2.x branches. Our intention is for this to be a resource for the Lustre community to find recent Lustre packages for variety of Linux distributions. Early next year we'll connect this to our test system so at least some of the packages can be tested, as well. We would be interested in hearing from anyone that would like to participate producing builds. Hudson is an distributed system, and it's easy to add more build nodes, even behind firewalls (some of us are running build VMs on our home machines). If you would like add another distribution or architecture we don't have yet, or even one we do have (the more the merrier), we'd be happy to work with you to do that. Please contact me if you are interested. cheers, robert ___ Lustre-discuss mailing list Lustre-discuss@lists.lustre.org http://lists.lustre.org/mailman/listinfo/lustre-discuss
Re: [Lustre-discuss] Question on versions, who is going to support what, etc.
On Dec 14, 2010, at 9:13 , Joe Landman wrote: > On 12/14/2010 12:09 PM, Andreas Dilger wrote: >> The 1.8 branch is in "maintenance mode" and will only be getting bug >> fixes. All new development is being done on the 2.x branch. >> >> We are finalizing the patches being landed on the Git master branch >> in anticipation of the upcoming 2.1 release, so testing and feedback >> of this branch is very welcome at this stage. A few mature "feature" >> patches are still being considered, but at this stage it is largely >> bug fixing only until the 2.1 branch is released. >> >> There are weekly build tags being created, that are suitable for >> external testing. My understanding is that build 8 (v2_0_58_0, IIRC) >> performed quite well, and a performance regression is being >> investigated in build 9 (v2_0_59_0). > > Greetings Andreas > > Thanks! We are doing RPM builds from clones of the git trees now. I > wanted to understand where 1.8.x was headed, and see if we should have > multiple build processes going on. I presume the OpenSFS and other > folks are also converged around 2.x? Hopefully? Hi Joe, Whamcloud is supporting both 1.8 and 2.x, and our development efforts are concentrating on 2.x. We're also building rpms for both 1.8 and 2.x on our Hudson server here: http://build.whamcloud.com/ cheers, robert > > Regards > > Joe > > > -- > Joseph Landman, Ph.D > Founder and CEO > Scalable Informatics Inc. > email: land...@scalableinformatics.com > web : http://scalableinformatics.com >http://scalableinformatics.com/sicluster > phone: +1 734 786 8423 x121 > fax : +1 866 888 3112 > cell : +1 734 612 4615 > ___ > Lustre-discuss mailing list > Lustre-discuss@lists.lustre.org > http://lists.lustre.org/mailman/listinfo/lustre-discuss ___ Lustre-discuss mailing list Lustre-discuss@lists.lustre.org http://lists.lustre.org/mailman/listinfo/lustre-discuss
Re: [Lustre-discuss] kernel: BUG: soft lockup - CPU stuck for 10s! with lustre 1.8.4
Hi Peter, Perhaps the link got mangled by your mail client? (It does have some seemingly unusual characters for an URL.) My interpretation of Gabriele's reply is that the problem occurred even with statahead disabled, so in that case this patch might be worth trying. robert On Sep 17, 2010, at 10:18 , Peter Jones wrote: > The URL does not work for me, but if it is a statahead issue then surely > turning statahead off would be a simple workaround to avoid having to > apply a patch. > > Fan Yong wrote: >> On 9/14/10 8:55 PM, Gabriele Paciucci wrote: >> >>> I have the same problem, I put the statahead_max to 0 !!! >>> >> In fact, I have made a patch for statahead related issues (including >> this one) against lustre-1.8, which is in inspection. >> http://review.whamcloud.com/#change,2 >> If possible, you can try such patch. >> >> Cheers, >> -- >> Nasf >> >> >> > ___ > Lustre-discuss mailing list > Lustre-discuss@lists.lustre.org > http://lists.lustre.org/mailman/listinfo/lustre-discuss ___ Lustre-discuss mailing list Lustre-discuss@lists.lustre.org http://lists.lustre.org/mailman/listinfo/lustre-discuss
Re: [Lustre-discuss] Multi-Role/Tasking MDS/OSS Hosts
Hi, On Sep 17, 2010, at 12:48 , Bernd Schubert wrote: > On Friday, September 17, 2010, Andreas Dilger wrote: >> On 2010-09-17, at 12:42, Jonathan B. Horen wrote: >>> We're trying to architect a Lustre setup for our group, and want to >>> leverage our available resources. In doing so, we've come to consider >>> multi-purposing several hosts, so that they'll function simultaneously >>> as MDS & OSS. >> >> You can't do this and expect recovery to work in a robust manner. The >> reason is that the MDS is a client of the OSS, and if they are both on the >> same node that crashes, the OSS will wait for the MDS "client" to >> reconnect and will time out recovery of the real clients. > > Well, that is some kind of design problem. Even on separate nodes it can > easily happen, that both MDS and OSS fail, for example power outage of the > storage rack. In my experience situations like that happen frequently... > > I think some kind a pre-connection would be required, where a client can tell > a server, that it was rebooted and that the server shall not to wait any > longer for it. Actually, shouldn't be that difficult, as already different > connection flags exist. So if the client contacts a server and ask for an > initial connection, the server could check for that NID and then immediately > abort recovery for that client. This is an interesting idea, but NID is not ideal as this wouldn't be compatible with multiple mounts on the same node. Not very useful in production, perhaps, but very useful for testing. Another option would be to hash the mount point pathname (and some other data, such as the NID) and use this as the client uuid. Then the client uuid would be persistent across reboots and the server would rely on flags to detect if this was a reconnect or a new connection after a reboot or remount. robert ___ Lustre-discuss mailing list Lustre-discuss@lists.lustre.org http://lists.lustre.org/mailman/listinfo/lustre-discuss
Re: [Lustre-discuss] Multi-Role/Tasking MDS/OSS Hosts
Hi, On Sep 17, 2010, at 14:49 , Bernd Schubert wrote: > Hello Cory, > > On 09/17/2010 11:31 PM, Cory Spitz wrote: >> Hi, Bernd. >> >> On 09/17/2010 02:48 PM, Bernd Schubert wrote: >>> On Friday, September 17, 2010, Andreas Dilger wrote: On 2010-09-17, at 12:42, Jonathan B. Horen wrote: > We're trying to architect a Lustre setup for our group, and want to > leverage our available resources. In doing so, we've come to consider > multi-purposing several hosts, so that they'll function simultaneously > as MDS & OSS. You can't do this and expect recovery to work in a robust manner. The reason is that the MDS is a client of the OSS, and if they are both on the same node that crashes, the OSS will wait for the MDS "client" to reconnect and will time out recovery of the real clients. >>> >>> Well, that is some kind of design problem. Even on separate nodes it can >>> easily happen, that both MDS and OSS fail, for example power outage of the >>> storage rack. In my experience situations like that happen frequently... >>> >> >> I think that just argues that the MDS should be on a separate UPS. > > well, there is not only a single reason. Next hardware issue is that > maybe an IB switch fails. And then have also seen cascading Lustre > failures. It starts with an LBUG on the OSS, which triggers another > problem on the MDS... > Also, for us this actually will become a real problem, which cannot be > easily solved. So this issue will become a DDN priority. There is always a possibility that multiple failures will occur, and this possibility can be reduced depending on one's resources. The point here is simply that a configuration with an mds and oss on the same node will guarantee multiple failures and aborted OSS recovery when that node fails. cheers, robert ___ Lustre-discuss mailing list Lustre-discuss@lists.lustre.org http://lists.lustre.org/mailman/listinfo/lustre-discuss
Re: [Lustre-discuss] Local Northern California Lustre Users Group
Yes, I remember discussing this back at the LUG too, and it sounds good to me. I agree that an evening meeting would probably be better in general. robert On Aug 4, 2010, at 10:06 AM, D. Marc Stearman wrote: > I think I was one of those suggesting the same thing. I think a lunch > time meeting is fine for folks on the Peninsula, or in the South Bay, > but for those of us in the far East Bay it could take an hour to get > there. I was thinking a monthly meeting sometime in the evening for > dinner/drinks would work well. > > -Marc > > > D. Marc Stearman > Lustre Operations Lead > m...@llnl.gov > 925.423.9670 > Pager: 1.888.203.0641 > > > > > On Jun 11, 2010, at 3:54 PM, Sebastian Gutierrez wrote: > >> Hello, >> >> While at LUG 2010, a few of us mentioned that we would be interested >> in a local LUG (LLUG?) in the bay area. We discussed that it may be >> a good idea to meet up about once a month to discuss issues and >> solutions. If you are still interested I am able to provide the >> initial meeting spot for our meeting. >> >> I am offering Stanford as our first meeting spot. If we can settle >> on a date we can start meeting either at the end of the month or >> early next month. I was thinking we could meet on the second Monday >> or Wednesday of each month, during lunch. >> >> What I need: a date that a majority could agree upon, or I can >> choose a date. Once we decide on a date I will set up a RSVP due date. >> >> My rough outline of the time would be: >> >> 1. Current updates, if any >> 2. Someone present an issue >> 3. We discuss solutions >> 4. goto 2 >> >> Cheers, >> Sebastian >> >> ___ >> Lustre-discuss mailing list >> Lustre-discuss@lists.lustre.org >> http://*lists.lustre.org/mailman/listinfo/lustre-discuss >> > > ___ > Lustre-discuss mailing list > Lustre-discuss@lists.lustre.org > http://lists.lustre.org/mailman/listinfo/lustre-discuss ___ Lustre-discuss mailing list Lustre-discuss@lists.lustre.org http://lists.lustre.org/mailman/listinfo/lustre-discuss
Re: [Lustre-discuss] Lustre-1.9.210: mkfs.ldiskfs?
On Jul 1, 2009, at 10:03 , Josephine Palencia wrote: > > OS: Centos 5.3, x86_64 > Kernel: 2.6.18-128.1.6 > > [r...@attractor ~]# cat /proc/fs/lustre/version > lustre: 1.9.210 > .. > > Looking for mkfs.ldiskfs during mkfs.lustre? > Did a find on previous working lustre-1.9 working and didn't find one. > Ps advice. > What configure options did you use when you built lustre? I think "-- with-ldiskfsprogs" will configure lustre to use these names, however the standard version the e2fs utils doesn't use this naming scheme. This would be used, for instance, if you needed to have both the original and ldiskfs version of e2fsutils installed at the same time. robert > [r...@attractor ~]# mkfs.lustre --fsname=jwan0 --mdt --mgs /dev/hdc1 > >Permanent disk data: > Target: jwan0-MDT > Index: unassigned > Lustre FS: jwan0 > Mount type: ldiskfs > Flags: 0x75 > (MDT MGS needs_index first_time update ) > Persistent mount opts: errors=remount-ro,iopen_nopriv,user_xattr > Parameters: > > checking for existing Lustre data: not found > device size = 19085MB > 2 6 18 > formatting backing filesystem ldiskfs on /dev/hdc1 > target name jwan0-MDT > 4k blocks 0 > options-J size=400 -i 4096 -I 512 -q -O > dir_index,uninit_groups -F > mkfs_cmd = mkfs.ldiskfs -j -b 4096 -L jwan0-MDT -J size=400 -i > 4096 > -I 512 -q -O dir_index,uninit_groups -F /dev/hdc1 >sh: mkfs.ldiskfs: command not found > > mkfs.lustre FATAL: Unable to build fs /dev/hdc1 (32512) > > mkfs.lustre FATAL: mkfs failed 32512 > > > Thanks, > josephin > ___ > Lustre-discuss mailing list > Lustre-discuss@lists.lustre.org > http://lists.lustre.org/mailman/listinfo/lustre-discuss ___ Lustre-discuss mailing list Lustre-discuss@lists.lustre.org http://lists.lustre.org/mailman/listinfo/lustre-discuss
Re: [Lustre-discuss] MDS Recovery: which client
On Feb 27, 2009, at 09:54 , Andreas Dilger wrote: > On Feb 27, 2009 14:16 +0100, Thomas Roth wrote: >> just to repeat my question without further surrounding facts and >> doubts; >> >> How can I find out which client is currently being recovered? (If the >> MDS is in recovery at that moment) >> How to find out which client is not recoverable (if recovery gets >> stuck)? >> >> The MDS seems to know, because during it is waiting for such a >> client - >> I'd like to know, too. > > Good question, and I don't think there is a good answer. There is a > patch > developed recently to put the recovery state of each client into / > proc, > but I'm not sure where it landed yet. I _think_ this would allow > you to > do "grep RECOVERING /proc/fs/lustre/mds/*/exports/*/import_state" or > similar. > > Robert, do you recall the bug and/or state of the per-client export > stats? I don't recall any bug for per-client export stats. As of 1.6.6 there is now a file in proc for per-import stats, but those are on the client, eg: [r...@client1 tests]# cat /proc/fs/lustre/mdc/*/import import: lustre-MDT-mdc-cf4f3e00 target: lustre-mdt_u...@10.0.1.180@tcp state: FULL inflight: 0 unregistering: 0 conn_cnt: 2 generation: 1 inval_cnt: 0 last_replay_transno: 0 peer_committed_transno: 0 last_trasno_checked: 0 flags: replayable pingable robert > > > Cheers, Andreas > -- > Andreas Dilger > Sr. Staff Engineer, Lustre Group > Sun Microsystems of Canada, Inc. > ___ Lustre-discuss mailing list Lustre-discuss@lists.lustre.org http://lists.lustre.org/mailman/listinfo/lustre-discuss
[Lustre-discuss] new lustre management tools
Hi, It has come to our attention that Lustre is occasionally found to be difficult to configure and manage. To address this, we are exploring options for improving our configuration tools for Lustre, including replacing lustre_config completely. However, we want to engage our user community as much as possible in this effort, since that help ensure the tools we end up with will be a good fit for those who use it the most. For instance, the new tool "Shine" (CEA's rewrite of Bull's admin tools) looks very promising and I encourage everyone interested in this to check it out: http://shine-wiki.async.eu/wiki/ Home. Does anyone know of other tools or efforts underway to build one? Ideally, I'd like to concentrate efforts on one solution, and declare this to be the "official" tool. On related note, what do people use to monitor Lustre? Of course there is LMT (http://sourceforge.net/projects/lmt/), and I've heard reports of others using nagios and/or ganglia, as well. Anything else? Should we start documenting these on a "best practices" wiki page? cheers, robert ___ Lustre-discuss mailing list Lustre-discuss@lists.lustre.org http://lists.lustre.org/mailman/listinfo/lustre-discuss
Re: [Lustre-discuss] Lustre and Xen
On Oct 6, 2008, at 16:03 , Andreas Dilger wrote: > On Oct 04, 2008 10:33 -0500, Daniel Ferber wrote: >> I have two questions: >> >> 1. On the OSS/OST side, can one run Lustre as a server on a system >> running a >> Xen kernel? >> >> 2. Conversely: is the lustre client compatible with Xen kernel >> machines? > > Note that "work" and "perform well" are two completely different > issues. > While CPU virtualization is quite efficient these days, IO > virtualization > is not necessarily very fast at all. > > I haven't benchmarked IO on Xen in a long time, but I'd expect a pretty reasonable percentage of native IO at this point. Not quite as efficient as cpu virtualization, of course, but I wouldn't necessarily say not very fast either. robert ___ Lustre-discuss mailing list Lustre-discuss@lists.lustre.org http://lists.lustre.org/mailman/listinfo/lustre-discuss
Re: [Lustre-discuss] Lustre and Xen
On Oct 4, 2008, at 08:33 , Daniel Ferber wrote: I have two questions: 1. On the OSS/OST side, can one run Lustre as a server on a system running a Xen kernel? 2. Conversely: is the lustre client compatible with Xen kernel machines? The answer to both questions is yes - I routinely test Lustre servers and clients on Xen using a RHEL 5 kernel with our patches and configured as a Xen guest. I have not tried a patchless client on a RHEL 5 Xen kernel yet, but I would expect that to work if you built our modules for it. robert Thanks much, Dan -- Dan Ferber, [EMAIL PROTECTED] +1 612-486-5167 (Office) +1 651-356-9481 (Cell x29704 (Sun Internal) ___ Lustre-discuss mailing list Lustre-discuss@lists.lustre.org http://lists.lustre.org/mailman/listinfo/lustre-discuss ___ Lustre-discuss mailing list Lustre-discuss@lists.lustre.org http://lists.lustre.org/mailman/listinfo/lustre-discuss
Re: [Lustre-discuss] How to find currently running version of lustre?
If the modules are loaded, then you can look here: cat /proc/fs/lustre/version robert On Aug 4, 2008, at 20:03 , Alex Lee wrote: > Silly question. > > How do you find out what version of lustre is currently running? > > On kernel I know you can just look at uname but as for the software > itself I have no clue. I guess I could check what rpm package was > installed but there must be other ways. > > -Alex > ___ > Lustre-discuss mailing list > Lustre-discuss@lists.lustre.org > http://lists.lustre.org/mailman/listinfo/lustre-discuss ___ Lustre-discuss mailing list Lustre-discuss@lists.lustre.org http://lists.lustre.org/mailman/listinfo/lustre-discuss
