From green at whamcloud.com Mon Apr 2 03:08:42 2012 From: green at whamcloud.com (Oleg Drokin) Date: Sun, 1 Apr 2012 23:08:42 -0400 Subject: [Lustre-devel] [Twg] your opinion about testing improvements In-Reply-To: <4F756360.1000108@xyratex.com> References: <4F745E90.2000001@xyratex.com> <4F756360.1000108@xyratex.com> Message-ID: <8F4579BA-FE5F-46C3-AC95-998E1195BD89@whamcloud.com> Hello! On Mar 30, 2012, at 3:40 AM, Roman Grigoryev wrote: > 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. I am not quite sure why would you want to constantly fail a test that is known not to work with a particular release due to a missing bugfix. I think it's enough if a developer (or somebody else) runs the test manually once on an unfixed codebase to make sure the test does without the fix. The issue of running older release against a newer one is a real one, but the truth is, when you run e.g. 1.8 vs 2.x, it's not just the tests that are different, the init code is different too, so it's not just a matter of separating tests subdir in its own repository. On our side we just note known broken tests for such configurations and ignore the failures for the lack of better solution. > 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. Ideally dependencies should be eliminated (in my opinion, anyway). Bye, Oleg -- Oleg Drokin Senior Software Engineer Whamcloud, Inc. From adilger at whamcloud.com Mon Apr 2 05:33:00 2012 From: adilger at whamcloud.com (Andreas Dilger) Date: Sun, 1 Apr 2012 23:33:00 -0600 Subject: [Lustre-devel] [Twg] your opinion about testing improvements In-Reply-To: <8F4579BA-FE5F-46C3-AC95-998E1195BD89@whamcloud.com> References: <4F745E90.2000001@xyratex.com> <4F756360.1000108@xyratex.com> <8F4579BA-FE5F-46C3-AC95-998E1195BD89@whamcloud.com> Message-ID: On 2012-04-01, at 9:08 PM, Oleg Drokin wrote: > On Mar 30, 2012, at 3:40 AM, Roman Grigoryev wrote: >> 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. > > I am not quite sure why would you want to constantly fail a test that is known not to work with a particular release due to a missing bugfix. > I think it's enough if a developer (or somebody else) runs the test manually once on an unfixed codebase to make sure the test does without the fix. I think it makes sense to be able to skip a test that is failing for versions of Lustre older than X, for cases where the test is exercising some fix on the server. We _do_ run interoperability tests and hit these failures, and it is much better to skip the test with a clear message instead of marking the test as failed. Probably the easiest solution is for such tests to explicitly check the version of the server, with a new helper function like "skip_old_version" or similar. Tests that are checking new features (as opposed to bugs) should normally be able to check via "lctl get_param {mdc,osc}.*.connect_flags" output whether the server supports a given feature or not. > The issue of running older release against a newer one is a real one, but the truth is, when you run e.g. 1.8 vs 2.x, it's not just the tests that are different, the init code is different too, so it's not just a matter of separating tests subdir in its own repository. > On our side we just note known broken tests for such configurations and ignore the failures for the lack of better solution. As mentioned earlier - the presence of known failing tests causes confusion, and it would be better to annotate these tests in a clear manner by skipping them instead of just knowing that they will fail. >> 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. > > Ideally dependencies should be eliminated (in my opinion, anyway). Agreed - all of the sub-tests should be able to run independently, even though they are normally run in order. Cheers, Andreas -- Andreas Dilger Whamcloud, Inc. Principal Lustre Engineer http://www.whamcloud.com/ From Roman_Grigoryev at xyratex.com Mon Apr 2 09:43:53 2012 From: Roman_Grigoryev at xyratex.com (Roman Grigoryev) Date: Mon, 02 Apr 2012 13:43:53 +0400 Subject: [Lustre-devel] [Twg] your opinion about testing improvements In-Reply-To: References: <4F745E90.2000001@xyratex.com> <4F756360.1000108@xyratex.com> <8F4579BA-FE5F-46C3-AC95-998E1195BD89@whamcloud.com> Message-ID: <4F7974D9.3010003@xyratex.com> On 04/02/2012 09:33 AM, Andreas Dilger wrote: > On 2012-04-01, at 9:08 PM, Oleg Drokin wrote: >> On Mar 30, 2012, at 3:40 AM, Roman Grigoryev wrote: >>> 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. >> >> I am not quite sure why would you want to constantly fail a test >> that is known not to work with a particular release due to a >> missing bugfix. I think it's enough if a developer (or somebody >> else) runs the test manually once on an unfixed codebase to make >> sure the test does without the fix. There can be more then one reason to execute tests which expectedly failed and I don't mean an obligation to execute these tests every time but mean an execution on automated platform in specific cases. The main problem now is compatibility testing(see below Oleg). Also there is problematic connection between tests code and lustre code taking into account consideration that test exclusion is done in test code. > > I think it makes sense to be able to skip a test that is failing for > versions of Lustre older than X, for cases where the test is > exercising some fix on the server. We _do_ run interoperability > tests and hit these failures, and it is much better to skip the test > with a clear message instead of marking the test as failed. Absolutely agree with You about skipping(maybe is good idea to somehow mark is as not skipped but "incompatible"?). > > Probably the easiest solution is for such tests to explicitly check > the version of the server, with a new helper function like > "skip_old_version" or similar. Maybe we can use just use some kind of keywords to say to framework just ignore new tests on old setups. I think adding more logic on test level isn't so good when this new logic process meta information. Test can just have an attribute which can be processed by a test-framework. > > Tests that are checking new features (as opposed to bugs) should > normally be able to check via "lctl get_param > {mdc,osc}.*.connect_flags" output whether the server supports a given > feature or not. But situation when you are executing new tests on a old server could be when you install in old lusre new tests. Oleg described below situation when it is pretty hard to execute new tests(2.x) on old clients (1.8.x). > >> The issue of running older release against a newer one is a real >> one, but the truth is, when you run e.g. 1.8 vs 2.x, it's not just >> the tests that are different, the init code is different too, so >> it's not just a matter of separating tests subdir in its own >> repository. Oleg, i'm answering there because You are in 'To' I used term "test-framework" for init code, and I agree with you about reasons. My tests separating idea is mostly not for code tree but for logical separating, mostly in build,dependency and versioning( but separating in code tree force to do it too). I think, it will be good to have lusre_tests version 1.2.3 and set on any lustre version. I think it can be interesting also for developers who do fixes for old or his own branches to simply get new tests ready for them. >> On our side we just note known broken tests for such >> configurations and ignore the failures for the lack of better >> solution. Could you please publish the list? > > As mentioned earlier - the presence of known failing tests causes > confusion, and it would be better to annotate these tests in a clear > manner by skipping them instead of just knowing that they will fail. > >>> 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. >> >> Ideally dependencies should be eliminated (in my opinion, anyway). > > Agreed - all of the sub-tests should be able to run independently, > even though they are normally run in order. Maybe it is a good idea to define and publish rules like this: 1) test(test scenario) must have only number name (1,2,3..110...999) 2) test cases (test step) must have number+char index (1f,2,b...99c) Test can be executed via ONLY. Test cases can be execute only as part of test. Tests must be independent. Test cases can have dependencies. Test define init, cleanup which are executing before and after test cases (not before-after very test case but full group). I think, these rules can somehow fix current situation with dependences without many changes in tests. -- Thanks, Roman From chris at whamcloud.com Tue Apr 3 00:26:57 2012 From: chris at whamcloud.com (Chris Gearing) Date: Tue, 03 Apr 2012 01:26:57 +0100 Subject: [Lustre-devel] Lustre-devel Digest, Vol 72, Issue 17 In-Reply-To: References: Message-ID: <4F7A43D1.5000209@whamcloud.com> Hi Roman, > 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. The situation here is exactly the same as exists with the source code. When we run interop tests the test system runs test scripts belonging to the server version against those belonging to the client version. So we might use 1.8.7 client scripts against 2.2 server scripts. These scripts need to inter-operate in exactly the same way that the Lustre source code itself needs to interoperate. If people find cases where this does not happen then they raise bugs against Lustre and these are fixed using the same processes as any other Lustre bug. This means people across the community investing effort to rectify the incompatibilities and then posting patches for review, test and inclusion in the product. Of course in a perfect world we would be back at the point where 1.8.7 and 2.x forked and never allow the interoperability issues in the test scripts to creep in, but the reality is the issues do exist and effort does needs to be spent resolving them. I am 100% sure that the resolution of the relatively few incompatibilities is infinitely easier than attempting to take the 1.8, 2.1 and 2.2 test scripts and produce an independent one size fits all solution. We currently track each failing test in Jira, see here http://jira.whamcloud.com/browse/LU-1193 for an example. If others find issues in their testing then they should create Jira issues to track them and if possible post patches to resolve them. > > > 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. > I think you highlight a very good point here that we don't really know enough about the test contents, their prerequisites or other dependencies. I would suggest that many attempts have been made over the years to use naming conventions, numeric ordering or other similar mechanisms to track such behaviour. What we need to make sense of the 1000+ test cases we have is an extensible knowledge-base of information that can grow overtime to become a rich source of information that can be used to allow automated systems as well as developers to confidently use the tests in the most flexible way possible. Because of the nature of Lustre we need to find a way that keeps this knowledge within the public domain, provides for use to expand the range of things we store about each test and provides for both people and machines to access it with equal ease. One reasonable proposal is to add a comment block at the start of each test script and subtest within that script that lists the test name, short and long description that includes what the test is supposed to be doing, what bug (if any) it was originally added for, what part of the code it is intended to cover, prerequisites (filesystem initialization, min/max number of clients, OSTs, MDTs it can test with, etc) in a machine readable format that it not only documents the test today but that can be expanded in the future. Once we have an agreement on an initial format for this comment block, the development community can work to populate it for each subtest and improve the understanding and usefulness of all existing tests. Thanks Chris Gearing Sr. Software Engineer Quality Engineering Whamcloud Inc From Roman_Grigoryev at xyratex.com Tue Apr 3 06:07:00 2012 From: Roman_Grigoryev at xyratex.com (Roman Grigoryev) Date: Tue, 03 Apr 2012 10:07:00 +0400 Subject: [Lustre-devel] your opinion about testing improvements (was Lustre-devel Digest, Vol 72, Issue 17) In-Reply-To: <4F7A43D1.5000209@whamcloud.com> References: <4F7A43D1.5000209@whamcloud.com> Message-ID: <4F7A9384.80707@xyratex.com> Hi Chris, Thank you for answer ( I have cut part of my original message): >> 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. ...... >> 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. > The situation here is exactly the same as exists with the source code. > When we run interop tests the test system runs test scripts belonging to > the server version against those belonging to the client version. So we > might use 1.8.7 client scripts against 2.2 server scripts. These scripts > need to inter-operate in exactly the same way that the Lustre source > code itself needs to interoperate. Yes, it is. But I don't see why we should use old test base for interoperability testing? Between 1.8.7 and 2.x tests was fixed and also as test framework was changed. For getting same test coverage for old features we should backport new fixes in test to old (maybe already frozen) code. Also, as results, we have different tests sets for compatibility testing. For 1.8.7 it will one, for 2.1 - other. Only a part of differences shows difference between code base for one feature set. (F.e. we see on special 1.8.7 branch failures which already fixed in 2.x code.) > > If people find cases where this does not happen then they raise bugs > against Lustre and these are fixed using the same processes as any other > Lustre bug. This means people across the community investing effort to > rectify the incompatibilities and then posting patches for review, test > and inclusion in the product. Of course in a perfect world we would be > back at the point where 1.8.7 and 2.x forked and never allow the > interoperability issues in the test scripts to creep in, but the reality > is the issues do exist and effort does needs to be spent resolving them. > I am 100% sure that the resolution of the relatively few > incompatibilities is infinitely easier than attempting to take the 1.8, > 2.1 and 2.2 test scripts and produce an independent one size fits all > solution. > I agree that there is a lot of work on test framework abstraction layer also on adding simple filtering procedure and setting keywords. But having one test base give us good possibility just setup an actual test package on all nodes and have somehow predict executed test set. Also, in this letter below, we discuss test/test framework changes. If we will have separated tests between version package then benefits from new tests descriptors we be accessible for all previous system too. In other case we could create incompatible improvements. > We currently track each failing test in Jira, see here > http://jira.whamcloud.com/browse/LU-1193 for an example. If others find > issues in their testing then they should create Jira issues to track > them and if possible post patches to resolve them. Thanks for this link. Do you have any keyword or attribute for interoperability failures? > >> >> >> Problem 2 >> >> (to avoid term problems, I call there: sanity = test suite, 130 = test, >> 130c and 130a = test cases) >> ... >> Answer of this question affect automated test execution and test >> development, and maybe ask some test-framework changes. >> > I think you highlight a very good point here that we don't really know > enough about the test contents, their prerequisites or other > dependencies. I would suggest that many attempts have been made over the > years to use naming conventions, numeric ordering or other similar > mechanisms to track such behaviour. > > What we need to make sense of the 1000+ test cases we have is an > extensible knowledge-base of information that can grow overtime to > become a rich source of information that can be used to allow automated > systems as well as developers to confidently use the tests in the most > flexible way possible. > > Because of the nature of Lustre we need to find a way that keeps this > knowledge within the public domain, provides for use to expand the range > of things we store about each test and provides for both people and > machines to access it with equal ease. > > One reasonable proposal is to add a comment block at the start of each > test script and subtest within that script that lists the test name, > short and long description that includes what the test is supposed to be > doing, what bug (if any) it was originally added for, what part of the > code it is intended to cover, prerequisites (filesystem initialization, > min/max number of clients, OSTs, MDTs it can test with, etc) in a > machine readable format that it not only documents the test today but > that can be expanded in the future. I agree, it is very important to separating meta information and test body. Internally in Xyratex, we use external scripts and descriptors which somehow add same possibility(per-test timeouts, keywords...). > > Once we have an agreement on an initial format for this comment block, > the development community can work to populate it for each subtest and > improve the understanding and usefulness of all existing tests. I absolutely agree that we need agreement to start any work on test improvements. How can we initiate this process? Maybe good first step is creating glossary to use and terms and based on these terms fix tests? Also, what do you think about a possible simple solutions for decreasing dependence problem which is currently pretty painful for us: 1) test(test scenario) must have only number name (1,2,3..110...999) 2) test cases (test step) must have number+char index (1f,2,b...99c) Only Test can be executed via ONLY. Test cases can be execute only as part of test. Thanks, Roman From chris at whamcloud.com Tue Apr 3 14:21:36 2012 From: chris at whamcloud.com (Chris Gearing) Date: Tue, 03 Apr 2012 15:21:36 +0100 Subject: [Lustre-devel] your opinion about testing improvements (was Lustre-devel Digest, Vol 72, Issue 17) In-Reply-To: <4F7A9384.80707@xyratex.com> References: <4F7A43D1.5000209@whamcloud.com> <4F7A9384.80707@xyratex.com> Message-ID: <4F7B0770.8050308@whamcloud.com> On 03/04/2012 07:07, Roman Grigoryev wrote: > Hi Chris, > Thank you for answer ( I have cut part of my original message): >> When we run interop tests the test system runs test scripts belonging to >> the server version against those belonging to the client version. So we >> might use 1.8.7 client scripts against 2.2 server scripts. These scripts >> need to inter-operate in exactly the same way that the Lustre source >> code itself needs to interoperate. > Yes, it is. But I don't see why we should use old test base for > interoperability testing? Between 1.8.7 and 2.x tests was fixed and also > as test framework was changed. For getting same test coverage for old > features we should backport new fixes in test to old (maybe already > frozen) code. > Also, as results, we have different tests sets for compatibility > testing. For 1.8.7 it will one, for 2.1 - other. Only a part of > differences shows difference between code base for one feature set. > (F.e. we see on special 1.8.7 branch failures which already fixed in 2.x > code.) > We don't have a single script because the tests are at times very tightly coupled to the Lustre version. There were a lot of changes between 1.8.x and 2.x and a lot of corresponding changes to the test scripts. Where the tests are the same and bugs were found in the 2.x test scripts these should have been backported to the 1.8.x test scripts if this was not done then we should do it for inclusion into the 1.8.8 release. The notion of making 'master' scripts work with with all versions is obviously possible but it is a very significant task and given that the scripts themselves are written in a language (sic) that does not provide structure a single script strategy is likely to create many more 'interoperability issues' than it fixes. Also it's worth considering that we have best part of a 1000 discrete changes, whenever a test is re-engineered the test itself must be proven to detect failure as well as success. i.e. If someone produced a version independent test set that passed all versions we would not know that the process was a success, we would need to check that each re-engineered test 'failed' appropriately for each Lustre version, this is a big task that I doubt can be properly achieved in bash. So in summary the best solution given what we have today is to back port fixes to the test scripts as we back port fixes to the code. This is an investment in time and requires the same discipline to test as we have for coding. A single set of scripts that caters for all versions appears I believe like an easy solution but actually would require huge investment that would be better spent developing a modern test framework and infrastructure that can support Lustre for the next ten years. > >>> >>> Problem 2 >>> >>> (to avoid term problems, I call there: sanity = test suite, 130 = test, >>> 130c and 130a = test cases) >>> > ... > >>> Answer of this question affect automated test execution and test >>> development, and maybe ask some test-framework changes. >>> >> I think you highlight a very good point here that we don't really know >> enough about the test contents, their prerequisites or other >> dependencies. I would suggest that many attempts have been made over the >> years to use naming conventions, numeric ordering or other similar >> mechanisms to track such behaviour. >> ... >> One reasonable proposal is to add a comment block at the start of each >> test script and subtest within that script that lists the test name, >> short and long description that includes what the test is supposed to be >> doing, what bug (if any) it was originally added for, what part of the >> code it is intended to cover, prerequisites (filesystem initialization, >> min/max number of clients, OSTs, MDTs it can test with, etc) in a >> machine readable format that it not only documents the test today but >> that can be expanded in the future. > I agree, it is very important to separating meta information and test body. > Internally in Xyratex, we use external scripts and descriptors which > somehow add same possibility(per-test timeouts, keywords...). > >> Once we have an agreement on an initial format for this comment block, >> the development community can work to populate it for each subtest and >> improve the understanding and usefulness of all existing tests. > I absolutely agree that we need agreement to start any work on test > improvements. How can we initiate this process? Maybe good first step is > creating glossary to use and terms and based on these terms fix tests? > > Also, what do you think about a possible simple solutions for decreasing > dependence problem which is currently pretty painful for us: > > 1) test(test scenario) must have only number name (1,2,3..110...999) > 2) test cases (test step) must have number+char index (1f,2,b...99c) > > Only Test can be executed via ONLY. > Test cases can be execute only as part of test. I don't think there is a problem with this simple solution in that it does no harm as long as you applied any changes to all the branches that are applicable. At the same time I will draft a possible meta data format that includes the extensible metadata within the source in a way that maximizes its value both today and in the future, we can then review, revise and then agree that format on Lustre-Devel, although I'll mail you privately so you can have input before that. It may actually be the case that some work has occurred on this topic previously and if so we can leverage that. Thanks Chris Gearing Sr. Software Engineer Quality Engineering Whamcloud Inc From Nathan_Rutman at xyratex.com Wed Apr 4 21:24:01 2012 From: Nathan_Rutman at xyratex.com (Nathan Rutman) Date: Wed, 4 Apr 2012 14:24:01 -0700 Subject: [Lustre-devel] your opinion about testing improvements (was Lustre-devel Digest, Vol 72, Issue 17) In-Reply-To: <4F7B0770.8050308@whamcloud.com> References: <4F7A43D1.5000209@whamcloud.com> <4F7A9384.80707@xyratex.com> <4F7B0770.8050308@whamcloud.com> Message-ID: <73AED5C780AE05478241DB067651A92102F1091C@XYUS-EX22.xyus.xyratex.com> On Apr 3, 2012, at 7:21 AM, Chris Gearing wrote: > On 03/04/2012 07:07, Roman Grigoryev wrote: >> Hi Chris, >> Thank you for answer ( I have cut part of my original message): >>> When we run interop tests the test system runs test scripts belonging to >>> the server version against those belonging to the client version. So we >>> might use 1.8.7 client scripts against 2.2 server scripts. These scripts >>> need to inter-operate in exactly the same way that the Lustre source >>> code itself needs to interoperate. >> Yes, it is. But I don't see why we should use old test base for >> interoperability testing? Between 1.8.7 and 2.x tests was fixed and also >> as test framework was changed. For getting same test coverage for old >> features we should backport new fixes in test to old (maybe already >> frozen) code. >> Also, as results, we have different tests sets for compatibility >> testing. For 1.8.7 it will one, for 2.1 - other. Only a part of >> differences shows difference between code base for one feature set. >> (F.e. we see on special 1.8.7 branch failures which already fixed in 2.x >> code.) >> > We don't have a single script because the tests are at times very > tightly coupled to the Lustre version. There were a lot of changes > between 1.8.x and 2.x and a lot of corresponding changes to the test > scripts. Where the tests are the same and bugs were found in the 2.x > test scripts these should have been backported to the 1.8.x test scripts > if this was not done then we should do it for inclusion into the 1.8.8 > release. > > The notion of making 'master' scripts work with with all versions is > obviously possible but it is a very significant task and given that the > scripts themselves are written in a language (sic) that does not provide > structure a single script strategy is likely to create many more > 'interoperability issues' than it fixes. > > Also it's worth considering that we have best part of a 1000 discrete > changes, whenever a test is re-engineered the test itself must be proven > to detect failure as well as success. i.e. If someone produced a version > independent test set that passed all versions we would not know that the > process was a success, we would need to check that each re-engineered > test 'failed' appropriately for each Lustre version, this is a big task > that I doubt can be properly achieved in bash. > > So in summary the best solution given what we have today is to back port > fixes to the test scripts as we back port fixes to the code. This is an > investment in time and requires the same discipline to test as we have > for coding. A single set of scripts that caters for all versions appears > I believe like an easy solution but actually would require huge > investment that would be better spent developing a modern test framework > and infrastructure that can support Lustre for the next ten years. I agree on this last point -- is that something that OpenSFS should spearhead? Roman has pointed out some of the limitations with the current test framework, Robert Read has pointed out the poor/redundant coverage of many of the existing tests; is it time to start from scratch? Is there a more evolutionary approach we can/should use? > >> >>>> >>>> Problem 2 >>>> >>>> (to avoid term problems, I call there: sanity = test suite, 130 = test, >>>> 130c and 130a = test cases) >>>> >> ... >> >>>> Answer of this question affect automated test execution and test >>>> development, and maybe ask some test-framework changes. >>>> >>> I think you highlight a very good point here that we don't really know >>> enough about the test contents, their prerequisites or other >>> dependencies. I would suggest that many attempts have been made over the >>> years to use naming conventions, numeric ordering or other similar >>> mechanisms to track such behaviour. >>> ... >>> One reasonable proposal is to add a comment block at the start of each >>> test script and subtest within that script that lists the test name, >>> short and long description that includes what the test is supposed to be >>> doing, what bug (if any) it was originally added for, what part of the >>> code it is intended to cover, prerequisites (filesystem initialization, >>> min/max number of clients, OSTs, MDTs it can test with, etc) in a >>> machine readable format that it not only documents the test today but >>> that can be expanded in the future. >> I agree, it is very important to separating meta information and test body. >> Internally in Xyratex, we use external scripts and descriptors which >> somehow add same possibility(per-test timeouts, keywords...). >> >>> Once we have an agreement on an initial format for this comment block, >>> the development community can work to populate it for each subtest and >>> improve the understanding and usefulness of all existing tests. >> I absolutely agree that we need agreement to start any work on test >> improvements. How can we initiate this process? Maybe good first step is >> creating glossary to use and terms and based on these terms fix tests? >> >> Also, what do you think about a possible simple solutions for decreasing >> dependence problem which is currently pretty painful for us: >> >> 1) test(test scenario) must have only number name (1,2,3..110...999) >> 2) test cases (test step) must have number+char index (1f,2,b...99c) >> >> Only Test can be executed via ONLY. >> Test cases can be execute only as part of test. > I don't think there is a problem with this simple solution in that it > does no harm as long as you applied any changes to all the branches that > are applicable. At the same time I will draft a possible meta data > format that includes the extensible metadata within the source in a way > that maximizes its value both today and in the future, we can then > review, revise and then agree that format on Lustre-Devel, although I'll > mail you privately so you can have input before that. It may actually be > the case that some work has occurred on this topic previously and if so > we can leverage that. > > Thanks > > Chris Gearing > Sr. Software Engineer > Quality Engineering > Whamcloud Inc > _______________________________________________ > Lustre-devel mailing list > Lustre-devel at lists.lustre.org > http://lists.lustre.org/mailman/listinfo/lustre-devel From Alexander_Lezhoev at xyratex.com Thu Apr 5 08:40:16 2012 From: Alexander_Lezhoev at xyratex.com (Alexander Lezhoev) Date: Thu, 05 Apr 2012 12:40:16 +0400 Subject: [Lustre-devel] [Twg] your opinion about testing improvements (was Lustre-devel Digest, Vol 72, Issue 17) In-Reply-To: <4F7B0770.8050308@whamcloud.com> References: <4F7A43D1.5000209@whamcloud.com> <4F7A9384.80707@xyratex.com> <4F7B0770.8050308@whamcloud.com> Message-ID: <4F7D5A70.8040006@xyratex.com> Hi Chris, I completely agree that the test-framework must be significantly revised. We have some plans to improve it and I think, it would be useful to share our ideas and visions of this task. Really we considered the separation of tests and Lustre code as a part of the framework improvement. So I think, we need to share our approaches and develop a conception which would be satisfactory for all. What do you think about opening a discussion about new test-framework? -- Alexander Lezhoev. Morpheus test team. Xyratex. On 04/03/2012 06:21 PM, Chris Gearing wrote: > > We don't have a single script because the tests are at times very > tightly coupled to the Lustre version. There were a lot of changes > between 1.8.x and 2.x and a lot of corresponding changes to the test > scripts. Where the tests are the same and bugs were found in the 2.x > test scripts these should have been backported to the 1.8.x test > scripts if this was not done then we should do it for inclusion into > the 1.8.8 release. > > The notion of making 'master' scripts work with with all versions is > obviously possible but it is a very significant task and given that > the scripts themselves are written in a language (sic) that does not > provide structure a single script strategy is likely to create many > more 'interoperability issues' than it fixes. > > Also it's worth considering that we have best part of a 1000 discrete > changes, whenever a test is re-engineered the test itself must be > proven to detect failure as well as success. i.e. If someone produced > a version independent test set that passed all versions we would not > know that the process was a success, we would need to check that each > re-engineered test 'failed' appropriately for each Lustre version, > this is a big task that I doubt can be properly achieved in bash. > > So in summary the best solution given what we have today is to back > port fixes to the test scripts as we back port fixes to the code. This > is an investment in time and requires the same discipline to test as > we have for coding. A single set of scripts that caters for all > versions appears I believe like an easy solution but actually would > require huge investment that would be better spent developing a modern > test framework and infrastructure that can support Lustre for the next > ten years. > From bzzz.tomas at gmail.com Thu Apr 5 10:38:30 2012 From: bzzz.tomas at gmail.com (Alex Tomas) Date: Thu, 5 Apr 2012 14:38:30 +0400 Subject: [Lustre-devel] [Twg] your opinion about testing improvements (was Lustre-devel Digest, Vol 72, Issue 17) In-Reply-To: <4F7D5A70.8040006@xyratex.com> References: <4F7A43D1.5000209@whamcloud.com> <4F7A9384.80707@xyratex.com> <4F7B0770.8050308@whamcloud.com> <4F7D5A70.8040006@xyratex.com> Message-ID: while technically this is possible, the framework will have to support different versions of Lustre because in some cases they implement functionality different ways with different side effects (often used in t-f). which kind of contradicts with the original idea ? thanks, Alex On Thu, Apr 5, 2012 at 12:40 PM, Alexander Lezhoev wrote: > Hi Chris, > > I completely agree that the test-framework must be significantly revised. We > have some plans to improve it and I think, it would be useful to share our > ideas and visions of this task. Really we considered the separation of tests > and Lustre code as a part of the framework improvement. So I think, we need > to share our approaches and develop a conception which would be satisfactory > for all. What do you think about opening a discussion about new > test-framework? > > -- > Alexander Lezhoev. > Morpheus test team. > Xyratex. > > > > > On 04/03/2012 06:21 PM, Chris Gearing wrote: >> >> >> We don't have a single script because the tests are at times very tightly >> coupled to the Lustre version. There were a lot of changes between 1.8.x and >> 2.x and a lot of corresponding changes to the test scripts. Where the tests >> are the same and bugs were found in the 2.x test scripts these should have >> been backported to the 1.8.x test scripts if this was not done then we >> should do it for inclusion into the 1.8.8 release. >> >> The notion of making 'master' scripts work with with all versions is >> obviously possible but it is a very significant task and given that the >> scripts themselves are written in a language (sic) that does not provide >> structure a single script strategy is likely to create many more >> 'interoperability issues' than it fixes. >> >> Also it's worth considering that we have best part of a 1000 discrete >> changes, whenever a test is re-engineered the test itself must be proven to >> detect failure as well as success. i.e. If someone produced a version >> independent test set that passed all versions we would not know that the >> process was a success, we would need to check that each re-engineered test >> 'failed' appropriately for each Lustre version, this is a big task that I >> doubt can be properly achieved in bash. >> >> So in summary the best solution given what we have today is to back port >> fixes to the test scripts as we back port fixes to the code. This is an >> investment in time and requires the same discipline to test as we have for >> coding. A single set of scripts that caters for all versions appears I >> believe like an easy solution but actually would require huge investment >> that would be better spent developing a modern test framework and >> infrastructure that can support Lustre for the next ten years. >> > > > _______________________________________________ > twg mailing list > twg at lists.opensfs.org > http://lists.opensfs.org/listinfo.cgi/twg-opensfs.org From philippe.deniel at cea.fr Fri Apr 6 13:44:43 2012 From: philippe.deniel at cea.fr (DENIEL Philippe) Date: Fri, 06 Apr 2012 15:44:43 +0200 Subject: [Lustre-devel] Who does setfsuid() work with quota in LUSTRE ? Message-ID: <4F7EF34B.60006@cea.fr> Hi, I am developing a NFS Server (NFS-Ganesha, see http://nfs-ganesha.sf.net) in user space with a LUSTRE backend. The daemon runs as root, but for NFS requesy processing, I use setfsuid() and setfsgid() (for setting "fs credentials") before operating on the LUSTRE backend, using jointly the liblustreapi and POSIX calls from the glibc. In fact, this approach works well as long as quotas are not concerned. Inode quota works fine : if a user exceed inode hard limit, he got (via NFS) a "Disk Quota exceeded" error. That's OK. Quotas on data behave on a stranger way : the written blocks are taken in account for increasing "used blocks" for that user, and a expiration date appear as the soft limite is passed, but the user can continue writing beyond the hard limit. At the beginning, I had files opened with fsuid=0 and then written with fsuid=non-root, I thought the fd remember the user that created it. So I wrote this small program: #include #include #include #include #include #include #include #include #include #define SIZE 10240 #define MOI 500 int main( int argc, char * argv[] ) { char * buff = NULL ; int fd =0 ; buff = malloc( SIZE ) ; fd = open( argv[1], O_CREAT|O_RDWR, 0644 ) ; printf( "buff=%p, errno=%u\n", buff, errno ) ; printf( "fd = %d\n", fd ) ; setfsuid( MOI ) ; printf( "bytes written = %d, errno=%u\n", write( fd, buff, SIZE ), errno ) ; printf( "fsync:%d errno=%u\n", fsync( fd ), errno ) ; printf( "close:%d errno=%u\n", close( fd ), errno ) ; } If run as non-root user whose quota are exceeded (a user that should get EDQUOT on every write operation), I got this message: buff=0x1e22010, errno=0 fd = 3 bytes written = -1, errno=0 fsync:-1 errno=122 close:0 errno=122 That really makes sense (setfsuid has no effect here). I am just a bit surprised that write() set errno to 0 but writes nothing, letting fsync()/close() return EDQUOT(122) Then I run the program as root, I saw that display: buff=0xee8010, errno=0 fd = 3 bytes written = 10240, errno=0 fsync:0 errno=0 close:0 errno=0 As you see, the IO was successful. At the same time, "lfs quota -u " showed that the counter of used block for that user incresased. I then changed my program to have the setfsuid() called BEFORE the open is made. The test code was then looking like this: #include #include #include #include #include #include #include #include #include #define SIZE 10240 #define MOI 500 int main( int argc, char * argv[] ) { char * buff = NULL ; int fd =0 ; buff = malloc( SIZE ) ; *setfsuid( MOI ) ;* fd = open( argv[1], O_CREAT|O_RDWR, 0644 ) ; printf( "buff=%p, errno=%u\n", buff, errno ) ; printf( "fd = %d\n", fd ) ; printf( "bytes written = %d, errno=%u\n", write( fd, buff, SIZE ), errno ) ; printf( "fsync:%d errno=%u\n", fsync( fd ), errno ) ; printf( "close:%d errno=%u\n", close( fd ), errno ) ; } And I ran the same test on new files, both as root and non-root (user with uid=500). I got exactly the same message as above. It seems like setfsuid() as lesser impact on block quota. This is really messy for my application. Do you have any idea of what happened and/or what I could do to have write() returning EDQUOT after setfsuid() ? I am currently using lustre-2-1-0 RPMS. Regards Philippe From chris at whamcloud.com Mon Apr 9 00:04:09 2012 From: chris at whamcloud.com (Chris Gearing) Date: Mon, 9 Apr 2012 01:04:09 +0100 Subject: [Lustre-devel] your opinion about testing improvements (was Lustre-devel Digest, Vol 72, Issue 17) In-Reply-To: <73AED5C780AE05478241DB067651A92102F1091C@XYUS-EX22.xyus.xyratex.com> References: <4F7A43D1.5000209@whamcloud.com> <4F7A9384.80707@xyratex.com> <4F7B0770.8050308@whamcloud.com> <73AED5C780AE05478241DB067651A92102F1091C@XYUS-EX22.xyus.xyratex.com> Message-ID: Hi Nathan, Please excuse the lack of included context but I think it's fair to say that the current test-framework and scripts are at the end of their evolutionary life and that whilst they will be required to fulfil a role in test for the foreseeable future what is required is a vastly more capable and scalable approach to testing Lustre in particular and massively parallel exascale file systems in general. Thanks Chris -------------- next part -------------- An HTML attachment was scrubbed... URL: From Nathan_Rutman at xyratex.com Mon Apr 9 22:54:13 2012 From: Nathan_Rutman at xyratex.com (Nathan Rutman) Date: Mon, 9 Apr 2012 15:54:13 -0700 Subject: [Lustre-devel] your opinion about testing improvements (was Lustre-devel Digest, Vol 72, Issue 17) In-Reply-To: References: <4F7A43D1.5000209@whamcloud.com> <4F7A9384.80707@xyratex.com> <4F7B0770.8050308@whamcloud.com> <73AED5C780AE05478241DB067651A92102F1091C@XYUS-EX22.xyus.xyratex.com> Message-ID: <73AED5C780AE05478241DB067651A92102F10939@XYUS-EX22.xyus.xyratex.com> Agreed. We started a conversation on the last TWG call about this; I was waiting for John Carrier's meeting minutes to carry on that conversation. On Apr 8, 2012, at 5:04 PM, Chris Gearing wrote: Hi Nathan, Please excuse the lack of included context but I think it's fair to say that the current test-framework and scripts are at the end of their evolutionary life and that whilst they will be required to fulfil a role in test for the foreseeable future what is required is a vastly more capable and scalable approach to testing Lustre in particular and massively parallel exascale file systems in general. Thanks Chris -------------- next part -------------- An HTML attachment was scrubbed... URL: From Nathan_Rutman at xyratex.com Wed Apr 11 16:57:16 2012 From: Nathan_Rutman at xyratex.com (Nathan Rutman) Date: Wed, 11 Apr 2012 09:57:16 -0700 Subject: [Lustre-devel] Orion HLD Message-ID: <73AED5C780AE05478241DB067651A92102F1094A@XYUS-EX22.xyus.xyratex.com> Can anyone point me to the Orion HLD please? From Nathan_Rutman at xyratex.com Wed Apr 11 23:00:40 2012 From: Nathan_Rutman at xyratex.com (Nathan Rutman) Date: Wed, 11 Apr 2012 16:00:40 -0700 Subject: [Lustre-devel] your opinion about testing improvements (was Lustre-devel Digest, Vol 72, Issue 17) In-Reply-To: <4F7B0770.8050308@whamcloud.com> References: <4F7A43D1.5000209@whamcloud.com> <4F7A9384.80707@xyratex.com> <4F7B0770.8050308@whamcloud.com> Message-ID: <73AED5C780AE05478241DB067651A92102F10954@XYUS-EX22.xyus.xyratex.com> On the 4/5 TWG concall we discussed this further, and came up with 5 items that we would like to address. discussion: Xyratex started by suggesting that the test suite included with every Lustre release needed reworking. This led to a group conversation that focused on the following areas: 1) refactor unused tests Test scripts have grown unwieldly and do not form a coherent test package. As a result, there are some tests that are used regularly and others that ineffective and skipped. We should remove the unused tests. 2) create single test suite Each release has its own test suite and assumes that the client and server will use the same test version. It is becoming common today to have different client/server versions. In this case, it is unclear which tests from which release package should be used. Instead, we should have a single test suite that accommodates different combinations of client and server versions. 3) extract individual tests from the scripts Many of the tests are run as a suite. There needs to be some mechanism to allow running components of the suite independently. To do this, we will need to make clear the dependencies of the subtests so that users know a test can be run only after another component of the test has executed. Also mentioned was the need for a common header on all test results to facilitate post-processing. 4) client failure shouldn't stop the tests The goal is never to have test failures, nonethelees failures currently can stall test progress. The suites need to be written to allow for client failures. 5) increase code coverage There are new tests that we should consider adding to the Lustre suite in order to increase code coverage. Suggestions were xfstest and some of the MPI tests. Obviously this is not as bold as Chris' statement, which, by the way, I am happy to entertain as well. Do others have anything to add to the list above, or thoughts on proceeding with a completely new architecture? On Apr 8, 2012, at 5:04 PM, Chris Gearing wrote: Hi Nathan, Please excuse the lack of included context but I think it's fair to say that the current test-framework and scripts are at the end of their evolutionary life and that whilst they will be required to fulfil a role in test for the foreseeable future what is required is a vastly more capable and scalable approach to testing Lustre in particular and massively parallel exascale file systems in general. Thanks Chris On Apr 3, 2012, at 7:21 AM, Chris Gearing wrote: On 03/04/2012 07:07, Roman Grigoryev wrote: Hi Chris, Thank you for answer ( I have cut part of my original message): When we run interop tests the test system runs test scripts belonging to the server version against those belonging to the client version. So we might use 1.8.7 client scripts against 2.2 server scripts. These scripts need to inter-operate in exactly the same way that the Lustre source code itself needs to interoperate. Yes, it is. But I don't see why we should use old test base for interoperability testing? Between 1.8.7 and 2.x tests was fixed and also as test framework was changed. For getting same test coverage for old features we should backport new fixes in test to old (maybe already frozen) code. Also, as results, we have different tests sets for compatibility testing. For 1.8.7 it will one, for 2.1 - other. Only a part of differences shows difference between code base for one feature set. (F.e. we see on special 1.8.7 branch failures which already fixed in 2.x code.) We don't have a single script because the tests are at times very tightly coupled to the Lustre version. There were a lot of changes between 1.8.x and 2.x and a lot of corresponding changes to the test scripts. Where the tests are the same and bugs were found in the 2.x test scripts these should have been backported to the 1.8.x test scripts if this was not done then we should do it for inclusion into the 1.8.8 release. The notion of making 'master' scripts work with with all versions is obviously possible but it is a very significant task and given that the scripts themselves are written in a language (sic) that does not provide structure a single script strategy is likely to create many more 'interoperability issues' than it fixes. Also it's worth considering that we have best part of a 1000 discrete changes, whenever a test is re-engineered the test itself must be proven to detect failure as well as success. i.e. If someone produced a version independent test set that passed all versions we would not know that the process was a success, we would need to check that each re-engineered test 'failed' appropriately for each Lustre version, this is a big task that I doubt can be properly achieved in bash. So in summary the best solution given what we have today is to back port fixes to the test scripts as we back port fixes to the code. This is an investment in time and requires the same discipline to test as we have for coding. A single set of scripts that caters for all versions appears I believe like an easy solution but actually would require huge investment that would be better spent developing a modern test framework and infrastructure that can support Lustre for the next ten years. Problem 2 (to avoid term problems, I call there: sanity = test suite, 130 = test, 130c and 130a = test cases) ... Answer of this question affect automated test execution and test development, and maybe ask some test-framework changes. I think you highlight a very good point here that we don't really know enough about the test contents, their prerequisites or other dependencies. I would suggest that many attempts have been made over the years to use naming conventions, numeric ordering or other similar mechanisms to track such behaviour. ... One reasonable proposal is to add a comment block at the start of each test script and subtest within that script that lists the test name, short and long description that includes what the test is supposed to be doing, what bug (if any) it was originally added for, what part of the code it is intended to cover, prerequisites (filesystem initialization, min/max number of clients, OSTs, MDTs it can test with, etc) in a machine readable format that it not only documents the test today but that can be expanded in the future. I agree, it is very important to separating meta information and test body. Internally in Xyratex, we use external scripts and descriptors which somehow add same possibility(per-test timeouts, keywords...). Once we have an agreement on an initial format for this comment block, the development community can work to populate it for each subtest and improve the understanding and usefulness of all existing tests. I absolutely agree that we need agreement to start any work on test improvements. How can we initiate this process? Maybe good first step is creating glossary to use and terms and based on these terms fix tests? Also, what do you think about a possible simple solutions for decreasing dependence problem which is currently pretty painful for us: 1) test(test scenario) must have only number name (1,2,3..110...999) 2) test cases (test step) must have number+char index (1f,2,b...99c) Only Test can be executed via ONLY. Test cases can be execute only as part of test. I don't think there is a problem with this simple solution in that it does no harm as long as you applied any changes to all the branches that are applicable. At the same time I will draft a possible meta data format that includes the extensible metadata within the source in a way that maximizes its value both today and in the future, we can then review, revise and then agree that format on Lustre-Devel, although I'll mail you privately so you can have input before that. It may actually be the case that some work has occurred on this topic previously and if so we can leverage that. Thanks Chris Gearing Sr. Software Engineer Quality Engineering Whamcloud Inc _______________________________________________ Lustre-devel mailing list Lustre-devel at lists.lustre.org http://lists.lustre.org/mailman/listinfo/lustre-devel -------------- next part -------------- An HTML attachment was scrubbed... URL: From ambreen.rasheed at gmail.com Wed Apr 18 06:13:17 2012 From: ambreen.rasheed at gmail.com (Ambreen Khan) Date: Wed, 18 Apr 2012 16:13:17 +1000 Subject: [Lustre-devel] Lustre 2.0 RPMS Message-ID: Hi I have been desperately searching for lustre 2.0 packages as I would like to install them on my CentOS 6.2 set up. However, I always get redirected to the oracle download page, and I cannot find lustre there www.oracle.com/technetwork/indexes/downloads/index.html Can you please guide me on how I can download the rpms. I would really like to test this clustering file system in my new project, but so far I haven't got any luck in installing lustre on CentOS 6.2. Best Regards Ambreen -------------- next part -------------- An HTML attachment was scrubbed... URL: From morrone2 at llnl.gov Wed Apr 18 17:24:03 2012 From: morrone2 at llnl.gov (Christopher J. Morrone) Date: Wed, 18 Apr 2012 10:24:03 -0700 Subject: [Lustre-devel] Lustre 2.0 RPMS In-Reply-To: References: Message-ID: <4F8EF8B3.2030608@llnl.gov> Here is a good starting point: http://wiki.whamcloud.com/display/PUB/Lustre+Releases You will probably want the latest "maintenance release", which is 2.1.1. Chris On 04/17/2012 11:13 PM, Ambreen Khan wrote: > Hi > > I have been desperately searching for lustre 2.0 packages as I would like to install them on my CentOS 6.2 set up. However, I always get redirected to the oracle download page, and I cannot find lustre there > > www.oracle.com/technetwork/indexes/downloads/index.html > > Can you please guide me on how I can download the rpms. I would really like to test this clustering file system in my new project, but so far I haven't got any luck in installing lustre on CentOS 6.2. > > Best Regards > Ambreen > From laisiyao at whamcloud.com Wed Apr 25 07:05:46 2012 From: laisiyao at whamcloud.com (Lai Siyao) Date: Wed, 25 Apr 2012 15:05:46 +0800 Subject: [Lustre-devel] rename in Changelog Message-ID: Rename record in Changelog is different from other operations, it's split into two records: RNMFRM and RNMTO. This makes Changelog analysis hard because these two records may not be consecutive and several renames may occur at the same time. I'm not clear why it's designed to be so, except that RNMTO is needed because for DNE (distributed namespace) the rename target may reside on another MDS, and a separate RNMTO record is needed. But even with this it's fine to store all information in a RENME record, but leave the information of whether rename removes the last hardlink of the target file (if it exists) in RNMTO record. I tried to add a field spfid in struct changelog_rec to store source parent fid, and pack both source (if has) and target names into record. Normally the record size if sizeof(fid) larger than before, and it can be differentiated according to version. The test result looks good, but I want to know whether anyone oppose to this? If not, I'll make the change and make it changelog version 2. Cheers, - Lai -------------- next part -------------- An HTML attachment was scrubbed... URL: From Nathan_Rutman at xyratex.com Wed Apr 25 16:36:08 2012 From: Nathan_Rutman at xyratex.com (Nathan Rutman) Date: Wed, 25 Apr 2012 09:36:08 -0700 Subject: [Lustre-devel] rename in Changelog In-Reply-To: References: Message-ID: <73AED5C780AE05478241DB067651A92102F109CD@XYUS-EX22.xyus.xyratex.com> it wasn't done that way in the first place because the record size in an llog is fixed, so any size increase is multiplied by the number of records, so fewer records can be stored. Splitting the rename into two was the unfortunate casualty of that goal. On Apr 25, 2012, at 2:05 AM, Lai Siyao wrote: > Rename record in Changelog is different from other operations, it's split into > two records: RNMFRM and RNMTO. This makes Changelog analysis hard > because these two records may not be consecutive and several renames > may occur at the same time. > > I'm not clear why it's designed to be so, except that RNMTO is needed > because for DNE (distributed namespace) the rename target may reside on > another MDS, and a separate RNMTO record is needed. But even with this > it's fine to store all information in a RENME record, but leave the information of > whether rename removes the last hardlink of the target file (if it exists) in > RNMTO record. > > I tried to add a field spfid in struct changelog_rec to store source parent fid, > and pack both source (if has) and target names into record. Normally the > record size if sizeof(fid) larger than before, and it can be differentiated > according to version. The test result looks good, but I want to know whether > anyone oppose to this? If not, I'll make the change and make it changelog > version 2. > > Cheers, > - Lai > > > _______________________________________________ > Lustre-devel mailing list > Lustre-devel at lists.lustre.org > http://lists.lustre.org/mailman/listinfo/lustre-devel From mike.tappro at gmail.com Wed Apr 25 18:06:43 2012 From: mike.tappro at gmail.com (Mikhail Pershin) Date: Wed, 25 Apr 2012 22:06:43 +0400 Subject: [Lustre-devel] rename in Changelog In-Reply-To: <73AED5C780AE05478241DB067651A92102F109CD@XYUS-EX22.xyus.xyratex.com> References: <73AED5C780AE05478241DB067651A92102F109CD@XYUS-EX22.xyus.xyratex.com> Message-ID: On Wed, 25 Apr 2012 20:36:08 +0400, Nathan Rutman wrote: > it wasn't done that way in the first place because the record size in an > llog is fixed, > so any size increase is multiplied by the number of records, so fewer > records > can be stored. Splitting the rename into two was the unfortunate > casualty of that goal. This is true if we are using the same record for all operations and Lai did so by adding extra field. But I'd note that fixed size is not mandatory thing but good to have. Moreover, changelog records are naturally not fixed size because contain name which size is not fixed. So I suppose rename was done in two parts just as simpler way to go because required no additional changes in processing, etc. Also, IIRC, CL_EXT appeared even later than CL_RENAME itself. To avoid space consuming we can just introduce extended 'changelog_ext_rec' for rename. It is not the problem to create such changelogs but requires processing tools to be aware about that, is that a big problem or acceptable? > > On Apr 25, 2012, at 2:05 AM, Lai Siyao wrote: > >> Rename record in Changelog is different from other operations, it's >> split into >> two records: RNMFRM and RNMTO. This makes Changelog analysis hard >> because these two records may not be consecutive and several renames >> may occur at the same time. >> >> I'm not clear why it's designed to be so, except that RNMTO is needed >> because for DNE (distributed namespace) the rename target may reside on >> another MDS, and a separate RNMTO record is needed. But even with this >> it's fine to store all information in a RENME record, but leave the >> information of >> whether rename removes the last hardlink of the target file (if it >> exists) in >> RNMTO record. >> >> I tried to add a field spfid in struct changelog_rec to store source >> parent fid, >> and pack both source (if has) and target names into record. Normally the >> record size if sizeof(fid) larger than before, and it can be >> differentiated >> according to version. The test result looks good, but I want to know >> whether >> anyone oppose to this? If not, I'll make the change and make it >> changelog >> version 2. >> >> Cheers, >> - Lai >> >> >> _______________________________________________ >> Lustre-devel mailing list >> Lustre-devel at lists.lustre.org >> http://lists.lustre.org/mailman/listinfo/lustre-devel > _______________________________________________ > Lustre-devel mailing list > Lustre-devel at lists.lustre.org > http://lists.lustre.org/mailman/listinfo/lustre-devel From laisiyao at whamcloud.com Thu Apr 26 01:05:20 2012 From: laisiyao at whamcloud.com (Lai Siyao) Date: Thu, 26 Apr 2012 09:05:20 +0800 Subject: [Lustre-devel] rename in Changelog In-Reply-To: References: <73AED5C780AE05478241DB067651A92102F109CD@XYUS-EX22.xyus.xyratex.com> Message-ID: Mike, you're right, only rename needs to use the new version of changelog format; and it will be unpacked in liblustreapi, the user space tool will not even notice it. On Thu, Apr 26, 2012 at 2:06 AM, Mikhail Pershin wrote: > On Wed, 25 Apr 2012 20:36:08 +0400, Nathan Rutman < > Nathan_Rutman at xyratex.com> wrote: > > it wasn't done that way in the first place because the record size in an >> llog is fixed, >> so any size increase is multiplied by the number of records, so fewer >> records >> can be stored. Splitting the rename into two was the unfortunate >> casualty of that goal. >> > > This is true if we are using the same record for all operations and Lai > did so by adding extra field. But I'd note that fixed size is not mandatory > thing but good to have. Moreover, changelog records are naturally not fixed > size because contain name which size is not fixed. So I suppose rename was > done in two parts just as simpler way to go because required no additional > changes in processing, etc. Also, IIRC, CL_EXT appeared even later than > CL_RENAME itself. > > To avoid space consuming we can just introduce extended > 'changelog_ext_rec' for rename. It is not the problem to create such > changelogs but requires processing tools to be aware about that, is that a > big problem or acceptable? > > > >> On Apr 25, 2012, at 2:05 AM, Lai Siyao wrote: >> >> Rename record in Changelog is different from other operations, it's >>> split into >>> two records: RNMFRM and RNMTO. This makes Changelog analysis hard >>> because these two records may not be consecutive and several renames >>> may occur at the same time. >>> >>> I'm not clear why it's designed to be so, except that RNMTO is needed >>> because for DNE (distributed namespace) the rename target may reside on >>> another MDS, and a separate RNMTO record is needed. But even with this >>> it's fine to store all information in a RENME record, but leave the >>> information of >>> whether rename removes the last hardlink of the target file (if it >>> exists) in >>> RNMTO record. >>> >>> I tried to add a field spfid in struct changelog_rec to store source >>> parent fid, >>> and pack both source (if has) and target names into record. Normally the >>> record size if sizeof(fid) larger than before, and it can be >>> differentiated >>> according to version. The test result looks good, but I want to know >>> whether >>> anyone oppose to this? If not, I'll make the change and make it changelog >>> version 2. >>> >>> Cheers, >>> - Lai >>> >>> >>> ______________________________**_________________ >>> Lustre-devel mailing list >>> Lustre-devel at lists.lustre.org >>> http://lists.lustre.org/**mailman/listinfo/lustre-devel >>> >> ______________________________**_________________ >> Lustre-devel mailing list >> Lustre-devel at lists.lustre.org >> http://lists.lustre.org/**mailman/listinfo/lustre-devel >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: From tao.peng at emc.com Fri Apr 27 02:23:52 2012 From: tao.peng at emc.com (tao.peng at emc.com) Date: Thu, 26 Apr 2012 22:23:52 -0400 Subject: [Lustre-devel] [wc-discuss] Re: Lustre and cross-platform portability In-Reply-To: <5A40CBC5-F91A-4F34-8209-0C216CCE8A5D@dilger.ca> References: <5609A4E0-2356-400F-9D53-F71B7007338C@whamcloud.com> <5A40CBC5-F91A-4F34-8209-0C216CCE8A5D@dilger.ca> Message-ID: Hi Andreas, Thank you very much for bringing it up in LUG and getting all these positive support from community. > -----Original Message----- > From: Andreas Dilger [mailto:aedilger at gmail.com] > Sent: Friday, April 27, 2012 7:48 AM > To: wc-discuss > Cc: Lustre Devel; lustre-discuss discuss > Subject: [wc-discuss] Re: Lustre and cross-platform portability > > To revive this thread, based on discussion at the LUG TWG: > - there was general consensus that cleaning up the Lustre client > (and server) code was very desirable to do > - migrating libcfs to emulate the Linux kernel APIs is also usable. > Ken mentioned that there is relatively little conflict between > the Linux kernel and the MacOS kernel, and the same for WinNT, so > they could use the same function names as Linux without problems. I created LU-1346 (http://jira.whamcloud.com/browse/LU-1346) to track libcfs cleanup work. > - there was no objection to converting the Lustre code from spaces > to tabs. My proposal was that build/checkpatch.pl could require > tabs immediately, and new patches should be submitted with tabs > on all new/modified lines (and optionally all lines on small > functions to avoid messy formatting). This will avoid issues > with current patches in flight, and also avoid "git annotate" > showing the jumbo replace-all-spaces-with-tabs patch for every > line in Lustre, and I think a good fraction of lines will be > updated in the next 9-12 months or more. As we approach the > actual time for upstream kernel submission is close, then we can > make a final effort to clean up remaining lines in idle code > (which will also be unlikely to conflict with existing work). While tabs are the main coding style difference between Lustre and kernel, there are a few minor change that is needed as well. I think we need to do following to match kernel coding style: 1. Lustre uses expandtab while kernel requires tabs 2. Lustre has vim syntax rules in most source files, which need to be removed 3. Lustre uses a slightly different comment style, which need to be changed to kernel style I created LU-1347 (http://jira.whamcloud.com/browse/LU-1347) to track the coding style changes. > > There is some hope that the kernel maintainers will not require > all of the Lustre macros to be removed, but we can deal with this > on a case-by-case basis. > IMO, we can divide macros to three groups (or more?): 1. Old kernel support macros, kernel maintainers are clear that they won't accept it. 2. For macros to mark out server code, kernel maintainers can accept it. But I think we need to make sure we don't do it too intrusive. 3. Lustre feature macros, we can convert them to Kconfig macros. Cheers, Tao > Cheers, Andreas > > On 2012-03-14, at 7: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, > > [revised] and the MacOS client needs significant work to update it to the latest version of Lustre, > and to get it landed into the Lustre repo, > > > 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/ > > > > > > > > > > > Cheers, Andreas > > > > > From adilger at whamcloud.com Fri Apr 27 03:54:17 2012 From: adilger at whamcloud.com (Andreas Dilger) Date: Thu, 26 Apr 2012 21:54:17 -0600 Subject: [Lustre-devel] [wc-discuss] Re: Lustre and cross-platform portability In-Reply-To: References: <5609A4E0-2356-400F-9D53-F71B7007338C@whamcloud.com> <5A40CBC5-F91A-4F34-8209-0C216CCE8A5D@dilger.ca> Message-ID: <1B1F8162-5FC6-4038-810A-EA219EE3BC84@whamcloud.com> On 2012-04-26, at 20:23, wrote: > Thank you very much for bringing it up in LUG and getting all these positive support from community. Tao, Yes it does look promising. >> To revive this thread, based on discussion at the LUG TWG: >> - there was general consensus that cleaning up the Lustre client >> (and server) code was very desirable to do >> - migrating libcfs to emulate the Linux kernel APIs is also usable. >> Ken mentioned that there is relatively little conflict between >> the Linux kernel and the MacOS kernel, and the same for WinNT, so >> they could use the same function names as Linux without problems. > I created LU-1346 (http://jira.whamcloud.com/browse/LU-1346) to track libcfs cleanup work. OK >> - there was no objection to converting the Lustre code from spaces >> to tabs. My proposal was that build/checkpatch.pl could require >> tabs immediately, and new patches should be submitted with tabs >> on all new/modified lines (and optionally all lines on small >> functions to avoid messy formatting). This will avoid issues >> with current patches in flight, and also avoid "git annotate" >> showing the jumbo replace-all-spaces-with-tabs patch for every >> line in Lustre, and I think a good fraction of lines will be >> updated in the next 9-12 months or more. As we approach the >> actual time for upstream kernel submission is close, then we can >> make a final effort to clean up remaining lines in idle code >> (which will also be unlikely to conflict with existing work). > While tabs are the main coding style difference between Lustre and kernel, there are a few minor change that is needed as well. I think we need to do following to match kernel coding style: > 1. Lustre uses expandtab while kernel requires tabs Right. > 2. Lustre has vim syntax rules in most source files, which need to be removed They should be replaced with explicit vim and enacts syntax rules that have the kernel indent style instead. If we could get syntax rules that embodied more of the coding style than just indentation, that would be even better. > 3. Lustre uses a slightly different comment style, which need to be changed to kernel style This is DOxygen style formatting. I had forgotten about this. We had in the past used this inline formatting for producing some documentation, but I'd need to ask about whether there is still a need for this today. In the meantime, please leave the comment style as-is. > I created LU-1347 (http://jira.whamcloud.com/browse/LU-1347) to track the coding style changes. > >> There is some hope that the kernel maintainers will not require >> all of the Lustre macros to be removed, but we can deal with this >> on a case-by-case basis. >> > IMO, we can divide macros to three groups (or more?): > 1. Old kernel support macros, kernel maintainers are clear that they won't accept it. Yes, but we need to maintain this in the external Lustre tree for years after Lustre would be accepted into mainline, since it would not be in vendor kernels (which a majority of Lustre users would be using). For such compat macros we need to make an effort to keep the upstream code as close as possible to the external tree, so patches have the most chance of applying. > 2. For macros to mark out server code, kernel maintainers can accept it. But I think we need to make sure we don't do it too intrusive. Sure, and we also need to make sure the ongoing maintenance effort to keep the code working is not too much either. I'm OK with incremental patches that more cleanly split the client and server code (structures, headers, etc) if that improves the code structure and readability. > 3. Lustre feature macros, we can convert them to Kconfig macros. Sure. Note that some of them may be obsolete, so before you spend too much time cleaning them up, please post a list to Jira. Maybe some of them can be dropped entirely. >> On 2012-03-14, at 7: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, >> >> [revised] and the MacOS client needs significant work to update it to the latest version of Lustre, >> and to get it landed into the Lustre repo, >> >>> 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/ >>> >>> >>> >>> >> >> >> Cheers, Andreas >> >> >> >> >> > From tao.peng at emc.com Fri Apr 27 10:15:38 2012 From: tao.peng at emc.com (tao.peng at emc.com) Date: Fri, 27 Apr 2012 06:15:38 -0400 Subject: [Lustre-devel] [wc-discuss] Re: Lustre and cross-platform portability In-Reply-To: <1B1F8162-5FC6-4038-810A-EA219EE3BC84@whamcloud.com> References: <5609A4E0-2356-400F-9D53-F71B7007338C@whamcloud.com> <5A40CBC5-F91A-4F34-8209-0C216CCE8A5D@dilger.ca> <1B1F8162-5FC6-4038-810A-EA219EE3BC84@whamcloud.com> Message-ID: Hi Andreas, > -----Original Message----- > From: Andreas Dilger [mailto:adilger at whamcloud.com] > Sent: Friday, April 27, 2012 11:54 AM > To: Peng, Tao > Cc: ; ; > Subject: Re: [wc-discuss] Re: Lustre and cross-platform portability > > On 2012-04-26, at 20:23, wrote: > > Thank you very much for bringing it up in LUG and getting all these positive support from community. > > Tao, > Yes it does look promising. > > >> To revive this thread, based on discussion at the LUG TWG: > >> - there was general consensus that cleaning up the Lustre client > >> (and server) code was very desirable to do > >> - migrating libcfs to emulate the Linux kernel APIs is also usable. > >> Ken mentioned that there is relatively little conflict between > >> the Linux kernel and the MacOS kernel, and the same for WinNT, so > >> they could use the same function names as Linux without problems. > > I created LU-1346 (http://jira.whamcloud.com/browse/LU-1346) to track libcfs cleanup work. > > OK > > >> - there was no objection to converting the Lustre code from spaces > >> to tabs. My proposal was that build/checkpatch.pl could require > >> tabs immediately, and new patches should be submitted with tabs > >> on all new/modified lines (and optionally all lines on small > >> functions to avoid messy formatting). This will avoid issues > >> with current patches in flight, and also avoid "git annotate" > >> showing the jumbo replace-all-spaces-with-tabs patch for every > >> line in Lustre, and I think a good fraction of lines will be > >> updated in the next 9-12 months or more. As we approach the > >> actual time for upstream kernel submission is close, then we can > >> make a final effort to clean up remaining lines in idle code > >> (which will also be unlikely to conflict with existing work). > > While tabs are the main coding style difference between Lustre and kernel, there are a few minor > change that is needed as well. I think we need to do following to match kernel coding style: > > 1. Lustre uses expandtab while kernel requires tabs > > Right. > > > 2. Lustre has vim syntax rules in most source files, which need to be removed > > They should be replaced with explicit vim and enacts syntax rules that have the kernel indent style > instead. If we could get syntax rules that embodied more of the coding style than just indentation, > that would be even better. > But we do need to remove them before submitting to kernel, right? And if we enforce checkpatch.pl on every patch applied, IMHO there is not much benefit to have syntax rules on every file, not to mention that it is explicitly forbidden in kernel coding style (Documentation/CodingStyle, Chapter 18: Editor modelines and other cruft). BTW, instead of just enabling tabs, how about changing checkpatch.pl to latest kernel version to make sure all future patches follow kernel coding styles? > > 3. Lustre uses a slightly different comment style, which need to be changed to kernel style > > This is DOxygen style formatting. I had forgotten about this. We had in the past used this inline > formatting for producing some documentation, but I'd need to ask about whether there is still a need > for this today. In the meantime, please leave the comment style as-is. > OK. > > > I created LU-1347 (http://jira.whamcloud.com/browse/LU-1347) to track the coding style changes. > > > >> There is some hope that the kernel maintainers will not require > >> all of the Lustre macros to be removed, but we can deal with this > >> on a case-by-case basis. > >> > > IMO, we can divide macros to three groups (or more?): > > 1. Old kernel support macros, kernel maintainers are clear that they won't accept it. > > Yes, but we need to maintain this in the external Lustre tree for years after Lustre would be accepted > into mainline, since it would not be in vendor kernels (which a majority of Lustre users would be > using). > > For such compat macros we need to make an effort to keep the upstream code as close as possible to the > external tree, so patches have the most chance of applying. > I agree. We should minimize maintenance effort for it. And as you suggested, we can put as many of these compat macros into places like linux_compat.h as possible and have Lustre code use latest kernel APIs, so that most maintenance effort for old kernel support would be to keep linux_compat.h uptodate. For compact macros that cannot be cleaned up this way, we will have to pay the extra efforts. And of course the cleanup will be an incremental process and macros will be dealt with in a case-by-case basis. > > 2. For macros to mark out server code, kernel maintainers can accept it. But I think we need to make > sure we don't do it too intrusive. > > Sure, and we also need to make sure the ongoing maintenance effort to keep the code working is not too > much either. > > I'm OK with incremental patches that more cleanly split the client and server code (structures, > headers, etc) if that improves the code structure and readability. > I agree that we can do some incremental patches to split client and server code. But I hope we only do it when it is trivial and simple. IMHO if we want to entirely split client/server code, it will be large code structure change. Since kernel maintainers already agreed on HAVE_SERVER_SUPPORT, how about we keep going that way at first? And we can make some split wherever it is simple and clear. And we will try to make code structure as clear/readable as possible. Then when we summit code for review, if kernel maintainers still don't like it, we do the large restructuring. Does it make sense? > > 3. Lustre feature macros, we can convert them to Kconfig macros. > > Sure. Note that some of them may be obsolete, so before you spend too much time cleaning them up, > please post a list to Jira. Maybe some of them can be dropped entirely. > Thanks. I will do as you suggested when it comes to converting them to Kconfig macros. Cheers, Tao > >> On 2012-03-14, at 7: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, > >> > >> [revised] and the MacOS client needs significant work to update it to the latest version of Lustre, > >> and to get it landed into the Lustre repo, > >> > >>> 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/ > >>> > >>> > >>> > >>> > >> > >> > >> Cheers, Andreas > >> > >> > >> > >> > >> > > From Roman_Grigoryev at xyratex.com Fri Apr 27 10:25:56 2012 From: Roman_Grigoryev at xyratex.com (Roman Grigoryev) Date: Fri, 27 Apr 2012 14:25:56 +0400 Subject: [Lustre-devel] [Lustre-discuss] [wc-discuss] Re: Lustre and cross-platform portability In-Reply-To: References: <5609A4E0-2356-400F-9D53-F71B7007338C@whamcloud.com> <5A40CBC5-F91A-4F34-8209-0C216CCE8A5D@dilger.ca> <1B1F8162-5FC6-4038-810A-EA219EE3BC84@whamcloud.com> Message-ID: <4F9A7434.6060300@xyratex.com> Tao,Andreas,all, What is your plan in test/test framework changes from the point of view of integration to kernel? As i know, kernel.org has his own test infrastructure and his own test framework. I'm sorry if it's incorrect place for this question. Thanks, Roman On 04/27/2012 02:15 PM, tao.peng at emc.com wrote: > Hi Andreas, > >> -----Original Message----- >> From: Andreas Dilger [mailto:adilger at whamcloud.com] >> Sent: Friday, April 27, 2012 11:54 AM >> To: Peng, Tao >> Cc: ; ; >> Subject: Re: [wc-discuss] Re: Lustre and cross-platform portability >> >> On 2012-04-26, at 20:23, wrote: >>> Thank you very much for bringing it up in LUG and getting all these positive support from community. >> >> Tao, >> Yes it does look promising. >> >>>> To revive this thread, based on discussion at the LUG TWG: >>>> - there was general consensus that cleaning up the Lustre client >>>> (and server) code was very desirable to do >>>> - migrating libcfs to emulate the Linux kernel APIs is also usable. >>>> Ken mentioned that there is relatively little conflict between >>>> the Linux kernel and the MacOS kernel, and the same for WinNT, so >>>> they could use the same function names as Linux without problems. >>> I created LU-1346 (http://jira.whamcloud.com/browse/LU-1346) to track libcfs cleanup work. >> >> OK >> >>>> - there was no objection to converting the Lustre code from spaces >>>> to tabs. My proposal was that build/checkpatch.pl could require >>>> tabs immediately, and new patches should be submitted with tabs >>>> on all new/modified lines (and optionally all lines on small >>>> functions to avoid messy formatting). This will avoid issues >>>> with current patches in flight, and also avoid "git annotate" >>>> showing the jumbo replace-all-spaces-with-tabs patch for every >>>> line in Lustre, and I think a good fraction of lines will be >>>> updated in the next 9-12 months or more. As we approach the >>>> actual time for upstream kernel submission is close, then we can >>>> make a final effort to clean up remaining lines in idle code >>>> (which will also be unlikely to conflict with existing work). >>> While tabs are the main coding style difference between Lustre and kernel, there are a few minor >> change that is needed as well. I think we need to do following to match kernel coding style: >>> 1. Lustre uses expandtab while kernel requires tabs >> >> Right. >> >>> 2. Lustre has vim syntax rules in most source files, which need to be removed >> >> They should be replaced with explicit vim and enacts syntax rules that have the kernel indent style >> instead. If we could get syntax rules that embodied more of the coding style than just indentation, >> that would be even better. >> > But we do need to remove them before submitting to kernel, right? And if we enforce checkpatch.pl on every patch applied, IMHO there is not much benefit to have syntax rules on every file, not to mention that it is explicitly forbidden in kernel coding style (Documentation/CodingStyle, Chapter 18: Editor modelines and other cruft). > > BTW, instead of just enabling tabs, how about changing checkpatch.pl to latest kernel version to make sure all future patches follow kernel coding styles? > >>> 3. Lustre uses a slightly different comment style, which need to be changed to kernel style >> >> This is DOxygen style formatting. I had forgotten about this. We had in the past used this inline >> formatting for producing some documentation, but I'd need to ask about whether there is still a need >> for this today. In the meantime, please leave the comment style as-is. >> > OK. > >> >>> I created LU-1347 (http://jira.whamcloud.com/browse/LU-1347) to track the coding style changes. >>> >>>> There is some hope that the kernel maintainers will not require >>>> all of the Lustre macros to be removed, but we can deal with this >>>> on a case-by-case basis. >>>> >>> IMO, we can divide macros to three groups (or more?): >>> 1. Old kernel support macros, kernel maintainers are clear that they won't accept it. >> >> Yes, but we need to maintain this in the external Lustre tree for years after Lustre would be accepted >> into mainline, since it would not be in vendor kernels (which a majority of Lustre users would be >> using). >> >> For such compat macros we need to make an effort to keep the upstream code as close as possible to the >> external tree, so patches have the most chance of applying. >> > I agree. We should minimize maintenance effort for it. And as you suggested, we can put as many of these compat macros into places like linux_compat.h as possible and have Lustre code use latest kernel APIs, so that most maintenance effort for old kernel support would be to keep linux_compat.h uptodate. For compact macros that cannot be cleaned up this way, we will have to pay the extra efforts. And of course the cleanup will be an incremental process and macros will be dealt with in a case-by-case basis. > >>> 2. For macros to mark out server code, kernel maintainers can accept it. But I think we need to make >> sure we don't do it too intrusive. >> >> Sure, and we also need to make sure the ongoing maintenance effort to keep the code working is not too >> much either. >> >> I'm OK with incremental patches that more cleanly split the client and server code (structures, >> headers, etc) if that improves the code structure and readability. >> > I agree that we can do some incremental patches to split client and server code. But I hope we only do it when it is trivial and simple. IMHO if we want to entirely split client/server code, it will be large code structure change. Since kernel maintainers already agreed on HAVE_SERVER_SUPPORT, how about we keep going that way at first? And we can make some split wherever it is simple and clear. And we will try to make code structure as clear/readable as possible. Then when we summit code for review, if kernel maintainers still don't like it, we do the large restructuring. Does it make sense? > >>> 3. Lustre feature macros, we can convert them to Kconfig macros. >> >> Sure. Note that some of them may be obsolete, so before you spend too much time cleaning them up, >> please post a list to Jira. Maybe some of them can be dropped entirely. >> > Thanks. I will do as you suggested when it comes to converting them to Kconfig macros. > > Cheers, > Tao > >>>> On 2012-03-14, at 7: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, >>>> >>>> [revised] and the MacOS client needs significant work to update it to the latest version of Lustre, >>>> and to get it landed into the Lustre repo, >>>> >>>>> 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/ >>>>> >>>>> >>>>> >>>>> >>>> >>>> >>>> Cheers, Andreas >>>> >>>> >>>> >>>> >>>> >>> > > _______________________________________________ > Lustre-discuss mailing list > Lustre-discuss at lists.lustre.org > http://lists.lustre.org/mailman/listinfo/lustre-discuss From tao.peng at emc.com Fri Apr 27 12:33:34 2012 From: tao.peng at emc.com (tao.peng at emc.com) Date: Fri, 27 Apr 2012 08:33:34 -0400 Subject: [Lustre-devel] [Lustre-discuss] [wc-discuss] Re: Lustre and cross-platform portability In-Reply-To: <4F9A7434.6060300@xyratex.com> References: <5609A4E0-2356-400F-9D53-F71B7007338C@whamcloud.com> <5A40CBC5-F91A-4F34-8209-0C216CCE8A5D@dilger.ca> <1B1F8162-5FC6-4038-810A-EA219EE3BC84@whamcloud.com> , <4F9A7434.6060300@xyratex.com> Message-ID: Hi Roman, Not sure if I misunderstand your question, but we won't push lustre/tests/* files to kernel. We only push client code and any tests will be executed out side of kernel. Cheers, Tao ________________________________________ From: Roman Grigoryev [Roman_Grigoryev at xyratex.com] Sent: Friday, April 27, 2012 6:25 PM To: Peng, Tao Cc: adilger at whamcloud.com; wc-discuss at whamcloud.com; lustre-discuss at lists.lustre.org; lustre-devel at lists.lustre.org Subject: Re: [Lustre-discuss] [wc-discuss] Re: Lustre and cross-platform portability Tao,Andreas,all, What is your plan in test/test framework changes from the point of view of integration to kernel? As i know, kernel.org has his own test infrastructure and his own test framework. I'm sorry if it's incorrect place for this question. Thanks, Roman On 04/27/2012 02:15 PM, tao.peng at emc.com wrote: > Hi Andreas, > >> -----Original Message----- >> From: Andreas Dilger [mailto:adilger at whamcloud.com] >> Sent: Friday, April 27, 2012 11:54 AM >> To: Peng, Tao >> Cc: ; ; >> Subject: Re: [wc-discuss] Re: Lustre and cross-platform portability >> >> On 2012-04-26, at 20:23, wrote: >>> Thank you very much for bringing it up in LUG and getting all these positive support from community. >> >> Tao, >> Yes it does look promising. >> >>>> To revive this thread, based on discussion at the LUG TWG: >>>> - there was general consensus that cleaning up the Lustre client >>>> (and server) code was very desirable to do >>>> - migrating libcfs to emulate the Linux kernel APIs is also usable. >>>> Ken mentioned that there is relatively little conflict between >>>> the Linux kernel and the MacOS kernel, and the same for WinNT, so >>>> they could use the same function names as Linux without problems. >>> I created LU-1346 (http://jira.whamcloud.com/browse/LU-1346) to track libcfs cleanup work. >> >> OK >> >>>> - there was no objection to converting the Lustre code from spaces >>>> to tabs. My proposal was that build/checkpatch.pl could require >>>> tabs immediately, and new patches should be submitted with tabs >>>> on all new/modified lines (and optionally all lines on small >>>> functions to avoid messy formatting). This will avoid issues >>>> with current patches in flight, and also avoid "git annotate" >>>> showing the jumbo replace-all-spaces-with-tabs patch for every >>>> line in Lustre, and I think a good fraction of lines will be >>>> updated in the next 9-12 months or more. As we approach the >>>> actual time for upstream kernel submission is close, then we can >>>> make a final effort to clean up remaining lines in idle code >>>> (which will also be unlikely to conflict with existing work). >>> While tabs are the main coding style difference between Lustre and kernel, there are a few minor >> change that is needed as well. I think we need to do following to match kernel coding style: >>> 1. Lustre uses expandtab while kernel requires tabs >> >> Right. >> >>> 2. Lustre has vim syntax rules in most source files, which need to be removed >> >> They should be replaced with explicit vim and enacts syntax rules that have the kernel indent style >> instead. If we could get syntax rules that embodied more of the coding style than just indentation, >> that would be even better. >> > But we do need to remove them before submitting to kernel, right? And if we enforce checkpatch.pl on every patch applied, IMHO there is not much benefit to have syntax rules on every file, not to mention that it is explicitly forbidden in kernel coding style (Documentation/CodingStyle, Chapter 18: Editor modelines and other cruft). > > BTW, instead of just enabling tabs, how about changing checkpatch.pl to latest kernel version to make sure all future patches follow kernel coding styles? > >>> 3. Lustre uses a slightly different comment style, which need to be changed to kernel style >> >> This is DOxygen style formatting. I had forgotten about this. We had in the past used this inline >> formatting for producing some documentation, but I'd need to ask about whether there is still a need >> for this today. In the meantime, please leave the comment style as-is. >> > OK. > >> >>> I created LU-1347 (http://jira.whamcloud.com/browse/LU-1347) to track the coding style changes. >>> >>>> There is some hope that the kernel maintainers will not require >>>> all of the Lustre macros to be removed, but we can deal with this >>>> on a case-by-case basis. >>>> >>> IMO, we can divide macros to three groups (or more?): >>> 1. Old kernel support macros, kernel maintainers are clear that they won't accept it. >> >> Yes, but we need to maintain this in the external Lustre tree for years after Lustre would be accepted >> into mainline, since it would not be in vendor kernels (which a majority of Lustre users would be >> using). >> >> For such compat macros we need to make an effort to keep the upstream code as close as possible to the >> external tree, so patches have the most chance of applying. >> > I agree. We should minimize maintenance effort for it. And as you suggested, we can put as many of these compat macros into places like linux_compat.h as possible and have Lustre code use latest kernel APIs, so that most maintenance effort for old kernel support would be to keep linux_compat.h uptodate. For compact macros that cannot be cleaned up this way, we will have to pay the extra efforts. And of course the cleanup will be an incremental process and macros will be dealt with in a case-by-case basis. > >>> 2. For macros to mark out server code, kernel maintainers can accept it. But I think we need to make >> sure we don't do it too intrusive. >> >> Sure, and we also need to make sure the ongoing maintenance effort to keep the code working is not too >> much either. >> >> I'm OK with incremental patches that more cleanly split the client and server code (structures, >> headers, etc) if that improves the code structure and readability. >> > I agree that we can do some incremental patches to split client and server code. But I hope we only do it when it is trivial and simple. IMHO if we want to entirely split client/server code, it will be large code structure change. Since kernel maintainers already agreed on HAVE_SERVER_SUPPORT, how about we keep going that way at first? And we can make some split wherever it is simple and clear. And we will try to make code structure as clear/readable as possible. Then when we summit code for review, if kernel maintainers still don't like it, we do the large restructuring. Does it make sense? > >>> 3. Lustre feature macros, we can convert them to Kconfig macros. >> >> Sure. Note that some of them may be obsolete, so before you spend too much time cleaning them up, >> please post a list to Jira. Maybe some of them can be dropped entirely. >> > Thanks. I will do as you suggested when it comes to converting them to Kconfig macros. > > Cheers, > Tao > >>>> On 2012-03-14, at 7: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, >>>> >>>> [revised] and the MacOS client needs significant work to update it to the latest version of Lustre, >>>> and to get it landed into the Lustre repo, >>>> >>>>> 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/ >>>>> >>>>> >>>>> >>>>> >>>> >>>> >>>> Cheers, Andreas >>>> >>>> >>>> >>>> >>>> >>> > > _______________________________________________ > Lustre-discuss mailing list > Lustre-discuss at lists.lustre.org > http://lists.lustre.org/mailman/listinfo/lustre-discuss From adilger at whamcloud.com Fri Apr 27 20:23:32 2012 From: adilger at whamcloud.com (Andreas Dilger) Date: Fri, 27 Apr 2012 14:23:32 -0600 Subject: [Lustre-devel] [wc-discuss] Re: Lustre and cross-platform portability In-Reply-To: References: <5609A4E0-2356-400F-9D53-F71B7007338C@whamcloud.com> <5A40CBC5-F91A-4F34-8209-0C216CCE8A5D@dilger.ca> <1B1F8162-5FC6-4038-810A-EA219EE3BC84@whamcloud.com> Message-ID: <424DA9EC-3CC6-4BD5-9A17-FECE362CE91E@whamcloud.com> On 2012-04-27, at 4:15 AM, wrote: > Andreas Dilger wrote: >> On 2012-04-26, at 20:23, wrote: >>> 2. Lustre has vim syntax rules in most source files, which need >>> to be removed >> >> They should be replaced with explicit vim and enacts syntax rules that have the kernel indent style instead. If we could get syntax rules that embodied more of the coding style than just indentation, that would be even better. >> > But we do need to remove them before submitting to kernel, right? And if we enforce checkpatch.pl on every patch applied, IMHO there is not much benefit to have syntax rules on every file, not to mention that it is explicitly forbidden in kernel coding style (Documentation/CodingStyle, Chapter 18: Editor modelines and other cruft). > > BTW, instead of just enabling tabs, how about changing checkpatch.pl to latest kernel version to make sure all future patches follow kernel coding styles? The Lustre checkpatch.pl is already based on the kernel one, but with some small modifications. It will default to checking for spaces vs. tabs, default to "--no-tree", does not require signoffs (since this is added at commit time after the patch is checked). One other change is to allow no spaces after commas in function parameters if the line is 79 or 80 columns long. That avoids a line wrap for just a couple of characters. I have no objection to updating to a newer version of checkpatch.pl if it improves the checking. Please run it against >>> IMO, we can divide macros to three groups (or more?): >>> 1. Old kernel support macros, kernel maintainers are clear that they won't accept it. > >>> 2. For macros to mark out server code, kernel maintainers can accept it. But I think we need to make sure we don't do it too intrusive. >> >> Sure, and we also need to make sure the ongoing maintenance effort to keep the code working is not too much either. >> >> I'm OK with incremental patches that more cleanly split the client and server code (structures, headers, etc) if that improves the code structure and readability. > > I agree that we can do some incremental patches to split client and server code. But I hope we only do it when it is trivial and simple. IMHO if we want to entirely split client/server code, it will be large code structure change. Since kernel maintainers already agreed on HAVE_SERVER_SUPPORT, how about we keep going that way at first? By all means, we can stick with HAVE_SERVER_SUPPORT for now. I was just commenting that I'm not against other changes if they improve the code in the long run. Cheers, Andreas -- Andreas Dilger Whamcloud, Inc. Principal Lustre Engineer http://www.whamcloud.com/ From liang at whamcloud.com Sat Apr 28 08:59:47 2012 From: liang at whamcloud.com (Liang Zhen) Date: Sat, 28 Apr 2012 16:59:47 +0800 Subject: [Lustre-devel] [wc-discuss] Re: Lustre and cross-platform portability In-Reply-To: <5A40CBC5-F91A-4F34-8209-0C216CCE8A5D@dilger.ca> References: <5609A4E0-2356-400F-9D53-F71B7007338C@whamcloud.com> <5A40CBC5-F91A-4F34-8209-0C216CCE8A5D@dilger.ca> Message-ID: On Apr 27, 2012, at 7:48 AM, Andreas Dilger wrote: > > - there was no objection to converting the Lustre code from spaces > to tabs. My proposal was that build/checkpatch.pl could require > tabs immediately, and new patches should be submitted with tabs > on all new/modified lines (and optionally all lines on small > functions to avoid messy formatting). This will avoid issues > with current patches in flight, and also avoid "git annotate" > showing the jumbo replace-all-spaces-with-tabs patch for every > line in Lustre, and I think a good fraction of lines will be > updated in the next 9-12 months or more. As we approach the > actual time for upstream kernel submission is close, then we can > make a final effort to clean up remaining lines in idle code > (which will also be unlikely to conflict with existing work). Lustre also requires to align the first alphabet of members while defining a structure, but linux kernel only aligns any first character (for example, * for pointer), then which way we should choose? we probably should update our coding guidelines ASAP. Liang -------------- next part -------------- An HTML attachment was scrubbed... URL: From tao.peng at emc.com Sun Apr 29 04:33:41 2012 From: tao.peng at emc.com (Peng Tao) Date: Sun, 29 Apr 2012 12:33:41 +0800 Subject: [Lustre-devel] [wc-discuss] Re: Lustre and cross-platform portability In-Reply-To: <424DA9EC-3CC6-4BD5-9A17-FECE362CE91E@whamcloud.com> References: <5609A4E0-2356-400F-9D53-F71B7007338C@whamcloud.com> <5A40CBC5-F91A-4F34-8209-0C216CCE8A5D@dilger.ca> <1B1F8162-5FC6-4038-810A-EA219EE3BC84@whamcloud.com> <424DA9EC-3CC6-4BD5-9A17-FECE362CE91E@whamcloud.com> Message-ID: On Sat, Apr 28, 2012 at 4:23 AM, Andreas Dilger wrote: > On 2012-04-27, at 4:15 AM, wrote: >> Andreas Dilger wrote: >>> On 2012-04-26, at 20:23, wrote: >>>> 2. Lustre has vim syntax rules in most source files, which need >>>> to be removed >>> >>> They should be replaced with explicit vim and enacts syntax rules that have the kernel indent style instead.  If we could get syntax rules that embodied more of the coding style than just indentation, that would be even better. >>> >> But we do need to remove them before submitting to kernel, right? And if we enforce checkpatch.pl on every patch applied, IMHO there is not much benefit to have syntax rules on every file, not to mention that it is explicitly forbidden in kernel coding style (Documentation/CodingStyle, Chapter 18:  Editor modelines and other cruft). >> >> BTW, instead of just enabling tabs, how about changing checkpatch.pl to latest kernel version to make sure all future patches follow kernel coding styles? > > The Lustre checkpatch.pl is already based on the kernel one, but with some small modifications.  It will default to checking for spaces vs. tabs, default to "--no-tree", does not require signoffs (since this is added at commit time after the patch is checked).  One other change is to allow no spaces after commas in function parameters if the line is 79 or 80 columns long.  That avoids a line wrap for just a couple of characters. > > I have no objection to updating to a newer version of checkpatch.pl if it improves the checking.  Please run it against > I hope we can use latest kernel version of checkpatch.pl so that it is more likely future patches can be applied to both kernel and Whamcloud tree. I did a diff against kernel checkpatch.pl and it creates ~2k lines of change. So I think it is worth updating Lustre version of checkpatch.pl. I submitted http://review.whamcloud.com/2610 for the change. Please help to review. Thank you. >>>> IMO, we can divide macros to three groups (or more?): >>>> 1. Old kernel support macros, kernel maintainers are clear that they won't accept it. >> >>>> 2. For macros to mark out server code, kernel maintainers can accept it. But I think we need to make sure we don't do it too intrusive. >>> >>> Sure, and we also need to make sure the ongoing maintenance effort to keep the code working is not too much either. >>> >>> I'm OK with incremental patches that more cleanly split the client and server code (structures, headers, etc) if that improves the code structure and readability. >> >> I agree that we can do some incremental patches to split client and server code. But I hope we only do it when it is trivial and simple. IMHO if we want to entirely split client/server code, it will be large code structure change. Since kernel maintainers already agreed on HAVE_SERVER_SUPPORT, how about we keep going that way at first? > > By all means, we can stick with HAVE_SERVER_SUPPORT for now.  I was just commenting that I'm not against other changes if they improve the code in the long run. > Thanks. We will do the split whenever it is easy. :) Best, Tao > 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 Mon Apr 30 12:52:57 2012 From: alexey_lyashkov at xyratex.com (Alexey Lyashkov) Date: Mon, 30 Apr 2012 19:52:57 +0700 Subject: [Lustre-devel] rename in Changelog In-Reply-To: <73AED5C780AE05478241DB067651A92102F109CD@XYUS-EX22.xyus.xyratex.com> References: <73AED5C780AE05478241DB067651A92102F109CD@XYUS-EX22.xyus.xyratex.com> Message-ID: but it's introduce the race. different mdt thread my write a one or more llog record between rename records. so it's isn't always two next records. On Apr 25, 2012, at 23:36, Nathan Rutman wrote: > it wasn't done that way in the first place because the record size in an llog is fixed, > so any size increase is multiplied by the number of records, so fewer records > can be stored. Splitting the rename into two was the unfortunate casualty of that goal. > > On Apr 25, 2012, at 2:05 AM, Lai Siyao wrote: > >> Rename record in Changelog is different from other operations, it's split into >> two records: RNMFRM and RNMTO. This makes Changelog analysis hard >> because these two records may not be consecutive and several renames >> may occur at the same time. >> >> I'm not clear why it's designed to be so, except that RNMTO is needed >> because for DNE (distributed namespace) the rename target may reside on >> another MDS, and a separate RNMTO record is needed. But even with this >> it's fine to store all information in a RENME record, but leave the information of >> whether rename removes the last hardlink of the target file (if it exists) in >> RNMTO record. >> >> I tried to add a field spfid in struct changelog_rec to store source parent fid, >> and pack both source (if has) and target names into record. Normally the >> record size if sizeof(fid) larger than before, and it can be differentiated >> according to version. The test result looks good, but I want to know whether >> anyone oppose to this? If not, I'll make the change and make it changelog >> version 2. >> >> Cheers, >> - Lai >> >> >> _______________________________________________ >> Lustre-devel mailing list >> Lustre-devel at lists.lustre.org >> http://lists.lustre.org/mailman/listinfo/lustre-devel > _______________________________________________ > Lustre-devel mailing list > Lustre-devel at lists.lustre.org > http://lists.lustre.org/mailman/listinfo/lustre-devel