Hi All I love wiki''s. Allowed me to upload the lustrefuse documentation directly to clusterfs. https://mail.clusterfs.com/wikis/lustre/fuse Allows you to mount a lustre file system WITHOUT a patched kernel and WITHOUT lustre kernel modules. All done using liblustre. It needs a LOT of work, performance is pretty poor. Hopefully someone will take it to heart, make this a great way for workstations (not a good solution for cluster nodes) to mount lustre file systems. Oh, the documentation could do with some work. Stu. -- Dr Stuart Midgley sdm900@gmail.com
As it builds around liblustre, does it require cray XT3 (or the like) to work? It would sound more interesting if that''s avoidable. Weikuan Stuart Midgley wrote:> Hi All > > I love wiki''s. Allowed me to upload the lustrefuse documentation > directly to clusterfs. > > https://mail.clusterfs.com/wikis/lustre/fuse > > Allows you to mount a lustre file system WITHOUT a patched kernel and > WITHOUT lustre kernel modules. All done using liblustre. > > It needs a LOT of work, performance is pretty poor. Hopefully someone > will take it to heart, make this a great way for workstations (not a > good solution for cluster nodes) to mount lustre file systems. Oh, the > documentation could do with some work. > > Stu. > > > -- > Dr Stuart Midgley > sdm900@gmail.com > > > _______________________________________________ > Lustre-discuss mailing list > Lustre-discuss@clusterfs.com > https://mail.clusterfs.com/mailman/listinfo/lustre-discuss > >
On Feb 09, 2007 08:49 -0500, Weikuan Yu wrote:> As it builds around liblustre, does it require cray XT3 (or the like) to > work? It would sound more interesting if that''s avoidable.No, it is possible to use liblustre without XT3. For liblustre testing we use liblustre.so as an LD_PRELOAD library running under Linux. Cheers, Andreas -- Andreas Dilger Principal Software Engineer Cluster File Systems, Inc.
Andreas Dilger wrote:> On Feb 09, 2007 08:49 -0500, Weikuan Yu wrote: >> As it builds around liblustre, does it require cray XT3 (or the like) to >> work? It would sound more interesting if that''s avoidable. > > No, it is possible to use liblustre without XT3. For liblustre testing > we use liblustre.so as an LD_PRELOAD library running under Linux.Very good to know that. It has been a long time since the last time I tried liblustre over linux, using lustre-1.2-lanl I guess. It got built fine, but no success in running liblustre back then. Presumably my fault or lack of accesses to compatible packages. Stuart, could you please indicate which version of lustre builds fine for liblustre? And the version of sysio that is compatible with it? If liblustre would just work over linux as you indicated on the webpage, please confirm. It might help if a specific sentence is added on the webpage indicating the instructions work for linux. Many thanks, Weikuan> > Cheers, Andreas > -- > Andreas Dilger > Principal Software Engineer > Cluster File Systems, Inc. > >
I think you will find that the documentation makes it pretty clear that this works on stock standard linux (I tested against Centos4.4). As also stated in the documentation, the build was tested against 1.5.97 (1.6b7). I suspect the same code should work against 1.4 liblustre as well. Though, the patches may have to be applied by hand in those cases. I''ll be interested to see if anyone else gets it working and whether it is a project that should be continued. On 2/10/07, Weikuan Yu <weikuan.yu@gmail.com> wrote:> > > Andreas Dilger wrote: > > On Feb 09, 2007 08:49 -0500, Weikuan Yu wrote: > >> As it builds around liblustre, does it require cray XT3 (or the like) to > >> work? It would sound more interesting if that''s avoidable. > > > > No, it is possible to use liblustre without XT3. For liblustre testing > > we use liblustre.so as an LD_PRELOAD library running under Linux. > > Very good to know that. It has been a long time since the last time I tried > liblustre over linux, using lustre-1.2-lanl I guess. It got built fine, but > no success in running liblustre back then. Presumably my fault or lack of > accesses to compatible packages. > > Stuart, could you please indicate which version of lustre builds fine for > liblustre? And the version of sysio that is compatible with it? If liblustre > would just work over linux as you indicated on the webpage, please > confirm. It might help if a specific sentence is added on the webpage > indicating the instructions work for linux. > > Many thanks, > Weikuan-- Dr Stuart Midgley sdm900@gmail.com
On Feb 09, 2007 14:07 +0900, Stuart Midgley wrote:> I love wiki''s. Allowed me to upload the lustrefuse documentation > directly to clusterfs. > > https://mail.clusterfs.com/wikis/lustre/fuse > > Allows you to mount a lustre file system WITHOUT a patched kernel and > WITHOUT lustre kernel modules. All done using liblustre.Very interesting work. I haven''t had a chance to play with FUSE yet, but if it can work with Lustre it definitely must be pretty functional... Note that in 1.6 one of the major motivations for having a Lustre FUSE is going away - kernels 2.6.16 and beyond can run Lustre clients without any patches. While there is still some benefit to patching the kernel (improved performance for a few use cases, better diagnostics, etc) this is not required on the client. You do still need to compile Lustre modules against the currently installed kernel. It is still required to patch the kernel for Lustre servers to run. Cheers, Andreas -- Andreas Dilger Principal Software Engineer Cluster File Systems, Inc.
FUSE also runs on MacOSX... which is my major motivation for this work. http://code.google.com/p/macfuse/ If I could get liblustre to compile on macosx, then that would be fantastic :) It certainly looks like it should be possible. FUSE also runs on BSD systems... Stu. On 2/13/07, Andreas Dilger <adilger@clusterfs.com> wrote:> On Feb 09, 2007 14:07 +0900, Stuart Midgley wrote: > > I love wiki''s. Allowed me to upload the lustrefuse documentation > > directly to clusterfs. > > > > https://mail.clusterfs.com/wikis/lustre/fuse > > > > Allows you to mount a lustre file system WITHOUT a patched kernel and > > WITHOUT lustre kernel modules. All done using liblustre. > > Very interesting work. I haven''t had a chance to play with FUSE yet, > but if it can work with Lustre it definitely must be pretty functional... > > Note that in 1.6 one of the major motivations for having a Lustre FUSE > is going away - kernels 2.6.16 and beyond can run Lustre clients without > any patches. While there is still some benefit to patching the kernel > (improved performance for a few use cases, better diagnostics, etc) this > is not required on the client. You do still need to compile Lustre modules > against the currently installed kernel. > > It is still required to patch the kernel for Lustre servers to run. > > > Cheers, Andreas > -- > Andreas Dilger > Principal Software Engineer > Cluster File Systems, Inc. > >-- Dr Stuart Midgley sdm900@gmail.com
On Mon, 12 Feb 2007, Andreas Dilger wrote:> Note that in 1.6 one of the major motivations for having a Lustre FUSE > is going away - kernels 2.6.16 and beyond can run Lustre clients without > any patches. While there is still some benefit to patching the kernel > (improved performance for a few use cases, better diagnostics, etc) this > is not required on the client. You do still need to compile Lustre modules > against the currently installed kernel.>From some earlier posts I recall that 2.6.15 plus one patch (I don''tremember which, but I poked at the Ubuntu guys so it got included in the Ubuntu Dapper 2.6.15 kernel back then) would be enough to use patchless client, is this still true? Searching for "patchless" in the Lustre wiki doesn''t match any page, and since this is of interest for a lot of us it would be nice to have the facts documented somewhere other than in the middle of mail threads :) Requirements, caveats, eventual special build instructions would be of interest. /Nikke -- -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Niklas Edmundsson, Admin @ {acc,hpc2n}.umu.se | nikke@hpc2n.umu.se --------------------------------------------------------------------------- I''d love to, but I''m worried about my vertical hold. =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
Niklas Edmundsson wrote:> Searching for "patchless" in the Lustre wiki doesn''t match any page, > and since this is of interest for a lot of us it would be nice to have > the facts documented somewhere other than in the middle of mail > threads :) Requirements, caveats, eventual special build instructions > would be of interest.I think that''s a great idea, and perhaps a "what kernels are supported" page as well. I did find this, which is a little out of date, but has the right spirit: https://mail.clusterfs.com/wikis/lustre/LustreStatusonLinux26 pmg, not sure who this should fall to, but I think it would be very useful.
On Feb 13, 2007 09:09 +0900, Stu Midgley wrote:> FUSE also runs on MacOSX... which is my major motivation for this work. > > http://code.google.com/p/macfuse/Now THAT is very interesting.> If I could get liblustre to compile on macosx, then that would be > fantastic :) It certainly looks like it should be possible. FUSE > also runs on BSD systems...There was some work to get liblustre going on AIX, so there is at least a vestige of cross-platform support. One major problem with AIX was the lack of a "syscall()" function in the libc that allowed liblustre to intercept the caller''s syscalls and redirect them to the OS instead of recursing. The other problem is that liblustre is not at all thread-safe. I haven''t had a chance to look through your patches, but I''ll do my best to get at them and land what I can. Cheers, Andreas -- Andreas Dilger Principal Software Engineer Cluster File Systems, Inc.
On Tue, 2007-02-13 at 18:10, Niklas Edmundsson wrote:> On Mon, 12 Feb 2007, Andreas Dilger wrote: > > > Note that in 1.6 one of the major motivations for having a Lustre FUSE > > is going away - kernels 2.6.16 and beyond can run Lustre clients without > > any patches. While there is still some benefit to patching the kernel > > (improved performance for a few use cases, better diagnostics, etc) this > > is not required on the client. You do still need to compile Lustre modules > > against the currently installed kernel. > > >From some earlier posts I recall that 2.6.15 plus one patch (I don''t > remember which, but I poked at the Ubuntu guys so it got included in > the Ubuntu Dapper 2.6.15 kernel back then) would be enough to use > patchless client, is this still true? >some info can be found in bugzilla (this general place for posting patches). support for for build with 2.6.18-2.6.19 vanila kernel currently in tree. support for build with 2.6.20 and RHEL5/fc6 kernels in bugzilla https://bugzilla.lustre.org/show_bug.cgi?id=11647 -- Alexey Lyashkov <shadow@clusterfs.com> Beaver team
On Wed, 14 Feb 2007, Alexey Lyashkov wrote:>>> Note that in 1.6 one of the major motivations for having a Lustre FUSE >>> is going away - kernels 2.6.16 and beyond can run Lustre clients without >>> any patches. While there is still some benefit to patching the kernel >>> (improved performance for a few use cases, better diagnostics, etc) this >>> is not required on the client. You do still need to compile Lustre modules >>> against the currently installed kernel. >> >>> From some earlier posts I recall that 2.6.15 plus one patch (I don''t >> remember which, but I poked at the Ubuntu guys so it got included in >> the Ubuntu Dapper 2.6.15 kernel back then) would be enough to use >> patchless client, is this still true? >> > some info can be found in bugzilla (this general place for posting > patches). support for for build with 2.6.18-2.6.19 vanila kernel > currently in tree. > support for build with 2.6.20 and RHEL5/fc6 kernels in bugzilla > https://bugzilla.lustre.org/show_bug.cgi?id=11647Searching for patchless in the bugzilla doesn''t that much useful information... Seriously, this habit of saying "it''s in the bugzilla" as an excuse for not documenting stuff is getting a bit annoying. The thing closest to an effort of collecting various information in a usable manner seems to be the wiki, and even though it should be rather easy to edit it seems to be hopelessly out of date. The front page shows all sorts of stuff that''s probably obsolete, but useful stuff that''s actually up to date (like the mountconf docco) isn''t listed there. Yes, it will take some efforts to get the wiki up to speed but I think it will be worth the effort. /Nikke -- -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Niklas Edmundsson, Admin @ {acc,hpc2n}.umu.se | nikke@hpc2n.umu.se --------------------------------------------------------------------------- Not tonight dear, I have a Modem!!! =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
On Wed, 2007-02-14 at 12:42, Niklas Edmundsson wrote:> On Wed, 14 Feb 2007, Alexey Lyashkov wrote: > > >>> Note that in 1.6 one of the major motivations for having a Lustre FUSE > >>> is going away - kernels 2.6.16 and beyond can run Lustre clients without > >>> any patches. While there is still some benefit to patching the kernel > >>> (improved performance for a few use cases, better diagnostics, etc) this > >>> is not required on the client. You do still need to compile Lustre modules > >>> against the currently installed kernel. > >> > >>> From some earlier posts I recall that 2.6.15 plus one patch (I don''t > >> remember which, but I poked at the Ubuntu guys so it got included in > >> the Ubuntu Dapper 2.6.15 kernel back then) would be enough to use > >> patchless client, is this still true? > >> > > some info can be found in bugzilla (this general place for posting > > patches). support for for build with 2.6.18-2.6.19 vanila kernel > > currently in tree. > > support for build with 2.6.20 and RHEL5/fc6 kernels in bugzilla > > https://bugzilla.lustre.org/show_bug.cgi?id=11647 > > Searching for patchless in the bugzilla doesn''t that much useful > information... >i basic it`s bugs - 11647, 11271, 10194. also nfs related bugs also addressed to patchless - 10796. patchless client testing started by QA team and results can be published in near future. As for me - patchless client passed all basic tests and some stress testing and show it`s stable. My test run with 2.6.19, 2.6.20-rc7, RHEL5 beta2/FC6 kernel. -- Alexey Lyashkov <shadow@clusterfs.com> Beaver team
Niklas Edmundsson wrote:> > Searching for patchless in the bugzilla doesn''t that much useful > information... > > Seriously, this habit of saying "it''s in the bugzilla" as an excuse > for not documenting stuff is getting a bit annoying. The thing closest > to an effort of collecting various information in a usable manner > seems to be the wiki, and even though it should be rather easy to edit > it seems to be hopelessly out of date. The front page shows all sorts > of stuff that''s probably obsolete, but useful stuff that''s actually up > to date (like the mountconf docco) isn''t listed there. > > Yes, it will take some efforts to get the wiki up to speed but I think > it will be worth the effort.I agree with you completely. Of course, there is plenty of other work for us to do... But we made you a special page: https://mail.clusterfs.com/wikis/lustre/PatchlessClient
On Wed, 14 Feb 2007, Nathaniel Rutman wrote:>> Searching for patchless in the bugzilla doesn''t that much useful >> information... >> >> Seriously, this habit of saying "it''s in the bugzilla" as an excuse for not >> documenting stuff is getting a bit annoying. The thing closest to an effort >> of collecting various information in a usable manner seems to be the wiki, >> and even though it should be rather easy to edit it seems to be hopelessly >> out of date. The front page shows all sorts of stuff that''s probably >> obsolete, but useful stuff that''s actually up to date (like the mountconf >> docco) isn''t listed there. >> >> Yes, it will take some efforts to get the wiki up to speed but I think it >> will be worth the effort. > > I agree with you completely. Of course, there is plenty of other work for us > to do... > But we made you a special page: > https://mail.clusterfs.com/wikis/lustre/PatchlessClientGreat! Just what I was looking for. Thanks! /Nikke -- -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Niklas Edmundsson, Admin @ {acc,hpc2n}.umu.se | nikke@hpc2n.umu.se --------------------------------------------------------------------------- Old frogs never die...but they do croak. =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
On ons, 2007-02-14 at 13:06 -0800, Nathaniel Rutman wrote:> Niklas Edmundsson wrote: > > > > Searching for patchless in the bugzilla doesn''t that much useful > > information... > > > > Seriously, this habit of saying "it''s in the bugzilla" as an excuse > > for not documenting stuff is getting a bit annoying. The thing closest > > to an effort of collecting various information in a usable manner > > seems to be the wiki, and even though it should be rather easy to edit > > it seems to be hopelessly out of date. The front page shows all sorts > > of stuff that''s probably obsolete, but useful stuff that''s actually up > > to date (like the mountconf docco) isn''t listed there. > > > > Yes, it will take some efforts to get the wiki up to speed but I think > > it will be worth the effort. > > I agree with you completely. Of course, there is plenty of other work > for us to do... > But we made you a special page: > https://mail.clusterfs.com/wikis/lustre/PatchlessClientAre there any test suite that should be run to "certify" the patchless client for other (distribution specific) kernels? So that they can be added to the wiki too? /torkel
Bj?rn Torkelsson wrote:> On ons, 2007-02-14 at 13:06 -0800, Nathaniel Rutman wrote: > >> Niklas Edmundsson wrote: >> >>> Searching for patchless in the bugzilla doesn''t that much useful >>> information... >>> >>> Seriously, this habit of saying "it''s in the bugzilla" as an excuse >>> for not documenting stuff is getting a bit annoying. The thing closest >>> to an effort of collecting various information in a usable manner >>> seems to be the wiki, and even though it should be rather easy to edit >>> it seems to be hopelessly out of date. The front page shows all sorts >>> of stuff that''s probably obsolete, but useful stuff that''s actually up >>> to date (like the mountconf docco) isn''t listed there. >>> >>> Yes, it will take some efforts to get the wiki up to speed but I think >>> it will be worth the effort. >>> >> I agree with you completely. Of course, there is plenty of other work >> for us to do... >> But we made you a special page: >> https://mail.clusterfs.com/wikis/lustre/PatchlessClient >> > > Are there any test suite that should be run to "certify" the patchless > client for other (distribution specific) kernels? So that they can be > added to the wiki too? >We run a full suite of tests against each of these kernels -- but I have no objection to adding a "user reported" section that lists which kernels have been tried, and problems/successes associated. If you''re building from source, the acceptance-small.sh suite under lustre/tests gives pretty good coverage, although that''s intended to test servers also. At the minimum, sanity.sh should be able to be run on a client. Start your patchless client, then just /lustre/tests# sh sanity.sh
On Thu, 15 Feb 2007, Nathaniel Rutman wrote:>> Are there any test suite that should be run to "certify" the patchless >> client for other (distribution specific) kernels? So that they can be >> added to the wiki too? >> > We run a full suite of tests against each of these kernels -- but I have no > objection to adding a "user reported" section that lists which kernels have > been tried, and problems/successes associated. If you''re building from > source, the acceptance-small.sh suite under lustre/tests gives pretty good > coverage, although that''s intended to test servers also.Hmm. I can''t find acceptance-small.sh in the 1.5.97 tarball at least...> At the minimum, > sanity.sh should be able to be run on a client. > Start your patchless client, then just > /lustre/tests# sh sanity.shActually, env MOUNT=/path/to/your/filesystem sh sanity.sh, otherwise it will create a bunch of files in /mnt/lustre, and all lustre-specific tests will fail ;) By the way, I don''t think that sanity.sh has been sanitized to support patchless clients... I''m getting a lot of: ./sanity.sh: line 117: [: patchless: integer expression expected which seems to make it skip all tests that checks for a lustre kernel version. I suspect that the correct approach is to apply all tests to patchless clients, not skip them. Also, there are a number of funny dependencies... For example, I can''t figure out where it should get socketserver and socketclient from. On a side note, usleep seems to have been depreceated in modern distros. Use something like sleep 0.0005 instead. /Nikke -- -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Niklas Edmundsson, Admin @ {acc,hpc2n}.umu.se | nikke@hpc2n.umu.se --------------------------------------------------------------------------- I never met a chocolate I didn''t like. - Deanna =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
On Fri, 16 Feb 2007, Niklas Edmundsson wrote:>> At the minimum, sanity.sh should be able to be run on a client. >> Start your patchless client, then just >> /lustre/tests# sh sanity.sh > > Actually, env MOUNT=/path/to/your/filesystem sh sanity.sh, otherwise it will > create a bunch of files in /mnt/lustre, and all lustre-specific tests will > fail ;) > > By the way, I don''t think that sanity.sh has been sanitized to support > patchless clients... I''m getting a lot of: > ./sanity.sh: line 117: [: patchless: integer expression expected > which seems to make it skip all tests that checks for a lustre kernel > version. I suspect that the correct approach is to apply all tests to > patchless clients, not skip them. > > Also, there are a number of funny dependencies... For example, I can''t figure > out where it should get socketserver and socketclient from. > > On a side note, usleep seems to have been depreceated in modern distros. Use > something like sleep 0.0005 instead.After hacking around the above problems (always saying that the lustre kernel version is good enough, installing dependencies, fixing paths, and editing cfg/local.sh) I''m down to this list of failed sanity.sh tests: These are due to using stuff that doesn''t exist: ./sanity.sh: FAIL: test_54a ./sanity.sh: FAIL: test_54a exit with rc=255 due to: ./sanity.sh: line 2172: socketserver: command not found ./sanity.sh: line 2173: socketclient: command not found ./sanity.sh: FAIL: test_60 exit with rc=127 due to: sh: run-llog.sh: No such file or directory ./sanity.sh: FAIL: test_64b exit with rc=127 due to: sh: oos.sh: No such file or directory These tests I don''t really understand why/how they should work. My wild guess is that sysctl -w lustre.fail_loc=0x217 should force a failure of some kind, but doesn''t. Should I care? ./sanity.sh: FAIL: test_69 write succeeded, expect -ENOENT ./sanity.sh: FAIL: test_69 read succeeded, expect -ENOENT To conclude, I think that sanity.sh needs some work before it can be used to easily verify that a client seems sane. /Nikke -- -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Niklas Edmundsson, Admin @ {acc,hpc2n}.umu.se | nikke@hpc2n.umu.se --------------------------------------------------------------------------- Travelling at the speed of light is bad for your age =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
Niklas Edmundsson wrote:> On Fri, 16 Feb 2007, Niklas Edmundsson wrote: > >>> At the minimum, sanity.sh should be able to be run on a client. >>> Start your patchless client, then just >>> /lustre/tests# sh sanity.sh >> >> Actually, env MOUNT=/path/to/your/filesystem sh sanity.sh, otherwise >> it will create a bunch of files in /mnt/lustre, and all >> lustre-specific tests will fail ;) >> >> By the way, I don''t think that sanity.sh has been sanitized to >> support patchless clients... I''m getting a lot of: >> ./sanity.sh: line 117: [: patchless: integer expression expected >> which seems to make it skip all tests that checks for a lustre kernel >> version. I suspect that the correct approach is to apply all tests to >> patchless clients, not skip them. >>right. I''ll add a [ $GOT_VER == "patchless"] && return 0>> Also, there are a number of funny dependencies... For example, I >> can''t figure out where it should get socketserver and socketclient from. >> >> On a side note, usleep seems to have been depreceated in modern >> distros. Use something like sleep 0.0005 instead. > > After hacking around the above problems (always saying that the lustre > kernel version is good enough, installing dependencies, fixing paths, > and editing cfg/local.sh) I''m down to this list of failed sanity.sh > tests: > > These are due to using stuff that doesn''t exist: > ./sanity.sh: FAIL: test_54a > ./sanity.sh: FAIL: test_54a exit with rc=255 > due to: > ./sanity.sh: line 2172: socketserver: command not found > ./sanity.sh: line 2173: socketclient: command not found > > ./sanity.sh: FAIL: test_60 exit with rc=127 > due to: > sh: run-llog.sh: No such file or directory > > ./sanity.sh: FAIL: test_64b exit with rc=127 > due to: > sh: oos.sh: No such file or directory >Yes, we should add checks to those.> > These tests I don''t really understand why/how they should work. My > wild guess is that sysctl -w lustre.fail_loc=0x217 should force a > failure of some kind, but doesn''t. Should I care? > ./sanity.sh: FAIL: test_69 write succeeded, expect -ENOENT > ./sanity.sh: FAIL: test_69 read succeeded, expect -ENOENT >Bug 11565 - it''s all marked private and hard to change now, but essentially it''s a bad test: "hmm, actually it just looks like a bad check for remote osts; test should be skipped in these cases. signing in a fix..."> > To conclude, I think that sanity.sh needs some work before it can be > used to easily verify that a client seems sane.Ok, thanks for the feedback.
Nathaniel Rutman wrote:> Niklas Edmundsson wrote: >> On Fri, 16 Feb 2007, Niklas Edmundsson wrote: >> >>>> At the minimum, sanity.sh should be able to be run on a client. >>>> Start your patchless client, then just >>>> /lustre/tests# sh sanity.sh >>> >>> Actually, env MOUNT=/path/to/your/filesystem sh sanity.sh, otherwise >>> it will create a bunch of files in /mnt/lustre, and all >>> lustre-specific tests will fail ;) >>> >>> By the way, I don''t think that sanity.sh has been sanitized to >>> support patchless clients... I''m getting a lot of: >>> ./sanity.sh: line 117: [: patchless: integer expression expected >>> which seems to make it skip all tests that checks for a lustre >>> kernel version. I suspect that the correct approach is to apply all >>> tests to patchless clients, not skip them. >>> > right. I''ll add a [ $GOT_VER == "patchless"] && return 0 >>> Also, there are a number of funny dependencies... For example, I >>> can''t figure out where it should get socketserver and socketclient >>> from. >>> >>> On a side note, usleep seems to have been depreceated in modern >>> distros. Use something like sleep 0.0005 instead. >> >> After hacking around the above problems (always saying that the >> lustre kernel version is good enough, installing dependencies, fixing >> paths, and editing cfg/local.sh) I''m down to this list of failed >> sanity.sh tests: >> >> These are due to using stuff that doesn''t exist: >> ./sanity.sh: FAIL: test_54a >> ./sanity.sh: FAIL: test_54a exit with rc=255 >> due to: >> ./sanity.sh: line 2172: socketserver: command not found >> ./sanity.sh: line 2173: socketclient: command not found >> >> ./sanity.sh: FAIL: test_60 exit with rc=127 >> due to: >> sh: run-llog.sh: No such file or directory >> >> ./sanity.sh: FAIL: test_64b exit with rc=127 >> due to: >> sh: oos.sh: No such file or directory >> > Yes, we should add checks to those. >> >> These tests I don''t really understand why/how they should work. My >> wild guess is that sysctl -w lustre.fail_loc=0x217 should force a >> failure of some kind, but doesn''t. Should I care? >> ./sanity.sh: FAIL: test_69 write succeeded, expect -ENOENT >> ./sanity.sh: FAIL: test_69 read succeeded, expect -ENOENT >> > Bug 11565 - it''s all marked private and hard to change now, but > essentially it''s a bad test: > "hmm, actually it just looks like a bad check for remote osts; test > should be skipped in these cases. signing in a fix..." > >> >> To conclude, I think that sanity.sh needs some work before it can be >> used to easily verify that a client seems sane. > Ok, thanks for the feedback.Attached the latest version here. Any tests that are new since the beta may fail, since we add tests when we fix bugs. -------------- next part -------------- A non-text attachment was scrubbed... Name: sanity.sh Type: application/x-shellscript Size: 114940 bytes Desc: not available Url : http://mail.clusterfs.com/pipermail/lustre-discuss/attachments/20070216/6c2ca6e6/sanity-0001.bin