From Roman_Grigoryev at xyratex.com  Thu May  3 09:45:23 2012
From: Roman_Grigoryev at xyratex.com (Roman Grigoryev)
Date: Thu, 03 May 2012 13:45:23 +0400
Subject: [Lustre-devel] [Lustre-discuss] [wc-discuss] Re: Lustre and
	cross-platform portability
In-Reply-To: <F19688880B763E40B28B2B462677FBF805EF52D53F@MX09A.corp.emc.com>
References: <5609A4E0-2356-400F-9D53-F71B7007338C@whamcloud.com>
	<5A40CBC5-F91A-4F34-8209-0C216CCE8A5D@dilger.ca>
	<F19688880B763E40B28B2B462677FBF805EF42BC26@MX09A.corp.emc.com>
	<1B1F8162-5FC6-4038-810A-EA219EE3BC84@whamcloud.com>
	<F19688880B763E40B28B2B462677FBF805EF42BD03@MX09A.corp.emc.com>,
	<4F9A7434.6060300@xyratex.com>
	<F19688880B763E40B28B2B462677FBF805EF52D53F@MX09A.corp.emc.com>
Message-ID: <4FA253B3.8090706@xyratex.com>

Hi Tao,

I'm not know how linux developers approve patches. But, logically,
because Lustre is big enough project and use kernel subsystems then it
should be tested after kernel changes on kernel side too. In  other case
(without testing) we can observer situation when Lustre built ok but
doesn't work.

I don't know goal of adding Lustre to kernel and, possible,this
situation could be acceptable from your point of view.

Thanks,
	Roman

On 04/27/2012 04:33 PM, tao.peng at emc.com wrote:
> 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: <wc-discuss at whamcloud.com>; <lustre-devel at lists.lustre.org>; <lustre-discuss at lists.lustre.org>
>>> Subject: Re: [wc-discuss] Re: Lustre and cross-platform portability
>>>
>>> On 2012-04-26, at 20:23, <tao.peng at emc.com> 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  Thu May  3 10:03:43 2012
From: tao.peng at emc.com (tao.peng at emc.com)
Date: Thu, 3 May 2012 06:03:43 -0400
Subject: [Lustre-devel] [Lustre-discuss] [wc-discuss] Re: Lustre and
 cross-platform portability
In-Reply-To: <4FA253B3.8090706@xyratex.com>
References: <5609A4E0-2356-400F-9D53-F71B7007338C@whamcloud.com>
	<5A40CBC5-F91A-4F34-8209-0C216CCE8A5D@dilger.ca>
	<F19688880B763E40B28B2B462677FBF805EF42BC26@MX09A.corp.emc.com>
	<1B1F8162-5FC6-4038-810A-EA219EE3BC84@whamcloud.com>
	<F19688880B763E40B28B2B462677FBF805EF42BD03@MX09A.corp.emc.com>,
	<4F9A7434.6060300@xyratex.com>
	<F19688880B763E40B28B2B462677FBF805EF52D53F@MX09A.corp.emc.com>
	<4FA253B3.8090706@xyratex.com>
Message-ID: <F19688880B763E40B28B2B462677FBF805EF42C153@MX09A.corp.emc.com>

> -----Original Message-----
> From: Roman Grigoryev [mailto:Roman_Grigoryev at xyratex.com]
> Sent: Thursday, May 03, 2012 5:45 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
> 
> Hi Tao,
Hi Roman,

> 
> I'm not know how linux developers approve patches. But, logically,
> because Lustre is big enough project and use kernel subsystems then it
> should be tested after kernel changes on kernel side too. In  other case
> (without testing) we can observer situation when Lustre built ok but
> doesn't work.
Now I see what you are worrying about. All code submitted to Linux kernel will be tested, and also patches later merged. It's just that kernel is a different place than Lustre git tree. We are not allowed to put test scripts into kernel tree. So all test code will remain in Whamcloud tree. But we will run the same tests against kernel code as well. One of our goal is to keep kernel client code in sync with Whamcloud tree as much as possible, so that the same code will be tested with older kernels as well.

> 
> I don't know goal of adding Lustre to kernel and, possible,this
> situation could be acceptable from your point of view.
> 
Untested code is buggy and useless. We certainly don't want it either.

Thanks,
Tao

> Thanks,
> 	Roman
> 
> On 04/27/2012 04:33 PM, tao.peng at emc.com wrote:
> > 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: <wc-discuss at whamcloud.com>; <lustre-devel at lists.lustre.org>; <lustre-discuss at lists.lustre.org>
> >>> Subject: Re: [wc-discuss] Re: Lustre and cross-platform portability
> >>>
> >>> On 2012-04-26, at 20:23, <tao.peng at emc.com> 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
> >
> >
> 
> ______________________________________________________________________
> This email may contain privileged or confidential information, which should only be used for the
> purpose for which it was sent by Xyratex. No further rights or licenses are granted to use such
> information. If you are not the intended recipient of this message, please notify the sender by return
> and delete it. You may not use, copy, disclose or rely on the information contained in it.
> 
> Internet email is susceptible to data corruption, interception and unauthorised amendment for which
> Xyratex does not accept liability. While we have taken reasonable precautions to ensure that this
> email is free of viruses, Xyratex does not accept liability for the presence of any computer viruses
> in this email, nor for any losses caused as a result of viruses.
> 
> Xyratex Technology Limited (03134912), Registered in England & Wales, Registered Office, Langstone
> Road, Havant, Hampshire, PO9 1SA.
> 
> The Xyratex group of companies also includes, Xyratex Ltd, registered in Bermuda, Xyratex
> International Inc, registered in California, Xyratex (Malaysia) Sdn Bhd registered in Malaysia,
> Xyratex Technology (Wuxi) Co Ltd registered in The People's Republic of China and Xyratex Japan
> Limited registered in Japan.
> ______________________________________________________________________
> 
> 


From Roman_Grigoryev at xyratex.com  Thu May  3 10:45:58 2012
From: Roman_Grigoryev at xyratex.com (Roman Grigoryev)
Date: Thu, 03 May 2012 14:45:58 +0400
Subject: [Lustre-devel] [Lustre-discuss] [wc-discuss] Re: Lustre and
	cross-platform portability
In-Reply-To: <F19688880B763E40B28B2B462677FBF805EF42C153@MX09A.corp.emc.com>
References: <5609A4E0-2356-400F-9D53-F71B7007338C@whamcloud.com>
	<5A40CBC5-F91A-4F34-8209-0C216CCE8A5D@dilger.ca>
	<F19688880B763E40B28B2B462677FBF805EF42BC26@MX09A.corp.emc.com>
	<1B1F8162-5FC6-4038-810A-EA219EE3BC84@whamcloud.com>
	<F19688880B763E40B28B2B462677FBF805EF42BD03@MX09A.corp.emc.com>,
	<4F9A7434.6060300@xyratex.com>
	<F19688880B763E40B28B2B462677FBF805EF52D53F@MX09A.corp.emc.com>
	<4FA253B3.8090706@xyratex.com>
	<F19688880B763E40B28B2B462677FBF805EF42C153@MX09A.corp.emc.com>
Message-ID: <4FA261E6.3070107@xyratex.com>


On 05/03/2012 02:03 PM, tao.peng at emc.com wrote:
>>
>> I'm not know how linux developers approve patches. But, logically,
>> because Lustre is big enough project and use kernel subsystems then it
>> should be tested after kernel changes on kernel side too. In  other case
>> (without testing) we can observer situation when Lustre built ok but
>> doesn't work.

> Now I see what you are worrying about. All code submitted to Linux kernel 
> will be tested, and also patches later merged. It's just that kernel is a 
> different place than Lustre git tree. We are not allowed to put test scripts 
> into kernel tree. So all test code will remain in Whamcloud tree. But we will 
> run the same tests against kernel code as well. One of our goal is to keep kernel
> client code in sync with Whamcloud tree as much as possible, so that the same 
> code will be tested with older kernels as well.

I just want to point, as I understand situation, keeping kernel client
code in sync with Whamcloud tree without testing on latest
kernels(include unstable) could lead to situation when client on new
kernel doesn't work but built ok. Testing on older kernels doesn't say
about work on new kernels, only give possibility.
Thanks,
	Roman
> 
>>
>> I don't know goal of adding Lustre to kernel and, possible,this
>> situation could be acceptable from your point of view.
>>
> Untested code is buggy and useless. We certainly don't want it either.
> 
> Thanks,
> Tao
> 
>> Thanks,
>> 	Roman
>>
>> On 04/27/2012 04:33 PM, tao.peng at emc.com wrote:
>>> 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: <wc-discuss at whamcloud.com>; <lustre-devel at lists.lustre.org>; <lustre-discuss at lists.lustre.org>
>>>>> Subject: Re: [wc-discuss] Re: Lustre and cross-platform portability
>>>>>
>>>>> On 2012-04-26, at 20:23, <tao.peng at emc.com> 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
>>>
>>>
>>
>> ______________________________________________________________________
>> This email may contain privileged or confidential information, which should only be used for the
>> purpose for which it was sent by Xyratex. No further rights or licenses are granted to use such
>> information. If you are not the intended recipient of this message, please notify the sender by return
>> and delete it. You may not use, copy, disclose or rely on the information contained in it.
>>
>> Internet email is susceptible to data corruption, interception and unauthorised amendment for which
>> Xyratex does not accept liability. While we have taken reasonable precautions to ensure that this
>> email is free of viruses, Xyratex does not accept liability for the presence of any computer viruses
>> in this email, nor for any losses caused as a result of viruses.
>>
>> Xyratex Technology Limited (03134912), Registered in England & Wales, Registered Office, Langstone
>> Road, Havant, Hampshire, PO9 1SA.
>>
>> The Xyratex group of companies also includes, Xyratex Ltd, registered in Bermuda, Xyratex
>> International Inc, registered in California, Xyratex (Malaysia) Sdn Bhd registered in Malaysia,
>> Xyratex Technology (Wuxi) Co Ltd registered in The People's Republic of China and Xyratex Japan
>> Limited registered in Japan.
>> ______________________________________________________________________
>>
>>
> 

From tao.peng at emc.com  Thu May  3 15:08:31 2012
From: tao.peng at emc.com (tao.peng at emc.com)
Date: Thu, 3 May 2012 11:08:31 -0400
Subject: [Lustre-devel] [Lustre-discuss] [wc-discuss] Re: Lustre and
 cross-platform portability
In-Reply-To: <4FA261E6.3070107@xyratex.com>
References: <5609A4E0-2356-400F-9D53-F71B7007338C@whamcloud.com>
	<5A40CBC5-F91A-4F34-8209-0C216CCE8A5D@dilger.ca>
	<F19688880B763E40B28B2B462677FBF805EF42BC26@MX09A.corp.emc.com>
	<1B1F8162-5FC6-4038-810A-EA219EE3BC84@whamcloud.com>
	<F19688880B763E40B28B2B462677FBF805EF42BD03@MX09A.corp.emc.com>,
	<4F9A7434.6060300@xyratex.com>
	<F19688880B763E40B28B2B462677FBF805EF52D53F@MX09A.corp.emc.com>
	<4FA253B3.8090706@xyratex.com>
	<F19688880B763E40B28B2B462677FBF805EF42C153@MX09A.corp.emc.com>,
	<4FA261E6.3070107@xyratex.com>
Message-ID: <F19688880B763E40B28B2B462677FBF805EF52D540@MX09A.corp.emc.com>


________________________________________
From: Roman Grigoryev [Roman_Grigoryev at xyratex.com]
Sent: Thursday, May 03, 2012 6:45 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

On 05/03/2012 02:03 PM, tao.peng at emc.com wrote:
>>
>> I'm not know how linux developers approve patches. But, logically,
>> because Lustre is big enough project and use kernel subsystems then it
>> should be tested after kernel changes on kernel side too. In  other case
>> (without testing) we can observer situation when Lustre built ok but
>> doesn't work.

> Now I see what you are worrying about. All code submitted to Linux kernel
> will be tested, and also patches later merged. It's just that kernel is a
> different place than Lustre git tree. We are not allowed to put test scripts
> into kernel tree. So all test code will remain in Whamcloud tree. But we will
> run the same tests against kernel code as well. One of our goal is to keep kernel
> client code in sync with Whamcloud tree as much as possible, so that the same
> code will be tested with older kernels as well.

> I just want to point, as I understand situation, keeping kernel client
> code in sync with Whamcloud tree without testing on latest
> kernels(include unstable) could lead to situation when client on new
> kernel doesn't work but built ok. Testing on older kernels doesn't say
> about work on new kernels, only give possibility.
I agree. We need to test latest kernel from time to time, and it can be a community effort. We will certainly test every patch we put in. And anyone interested can test the code as well. If you are suggesting some public testing infrastructure, maybe Whamcloud will be interested? IMHO, testing every patch in upstream kernel like Maloo does for Whamcloud tree, is a little luxury through.

Thanks,
Tao




From adilger at whamcloud.com  Tue May  8 20:17:41 2012
From: adilger at whamcloud.com (Andreas Dilger)
Date: Tue, 8 May 2012 14:17:41 -0600
Subject: [Lustre-devel] Lustre coding style: use tabs for indentation
Message-ID: <C28123A9-C33A-4C45-9DAC-0036A528A600@whamcloud.com>

NOTE TO ALL LUSTRE DEVELOPERS
=============================

As previously discussed at LUG in Austin, and in these lists, we've decided to change Lustre to use the upstream Linux kernel coding style.  This is being done in order to allow merging the Lustre client code into the upstream kernel.

In most cases, the two coding styles agree, but one of the major differences is that Lustre uses 8-space indents, while the kernel uses tabs.  To ensure the transition is not disruptive to ongoing work in patches and branches, there will NOT be an en-masse change of every line of Lustre to use tabs.  This would cause 280kLOC of changes in a short time, and would break landing of all in-flight patches and branches, and the commit history of every line of code would be useless.


Instead, there will be an incremental change to the coding style:
* All lines of code that are modified or added by new or updated
  patches must use tabs for indentation.  This includes tests.
* If there are fewer than 6 unmodified lines between two modified
  lines (i.e. normal "diff" context) still using spaces, they should
  also be converted to using tabs.
* If there are only a "handful" of lines remaining in a function,
  test, structure, header, etc. that are using spaces for indentation,
  they should also be converted to using tabs (including the function
  declaration, if needed).  Use your judgement, but since every line
  must be changed at some point, it is better to err on the side of
  converting more lines to tabs than fewer.

By modifying adjacent lines together, and stragglers in a file, it will not significantly increase the size or number of the patches, and it will avoid messy blocks of code that have both tabs and spaces interleaved.  If there are other whitespace or code style issues (e.g. trailing spaces or tabs, placement of braces or operators, etc.) on lines being modified, it would be useful to clean them up at the same time, to also improve the overall quality of the code.

Note that in Gerrit it is possible to permanently select "Ignore Whitespace" as "All" when reviewing a patch, so that the indentation change doesn't interfere with the understanding of the patch.

The build/checkpatch.pl script has already been updated to match the latest kernel version, and requires tabs for indentation.  The vim/emacs modelines that force spaces for indentation have also been removed.

Given the number of lines of code that will be changing over the next year due to OSD restructuring, DNE, LNET, NRS, SMP scaling, etc., it is expected that a significant fraction of the lines will be converted by the 2.4 release.  By this time, we will evaluate whether an en-masse conversion of the remaining lines is warranted, whether for just the client code, or for all code.

Thanks for your cooperation in during this change.

Cheers, Andreas
--
Andreas Dilger                       Whamcloud, Inc.
Principal Lustre Engineer            http://www.whamcloud.com/




From rhenwood at whamcloud.com  Fri May 11 20:23:20 2012
From: rhenwood at whamcloud.com (Richard Henwood)
Date: Fri, 11 May 2012 15:23:20 -0500
Subject: [Lustre-devel] MDS performance: SMP Node Affinity Docs for OpenSFS
	NRE
Message-ID: <CAA6TbrMb8kviNvHcNXPmr3D35srUkzA6un1mGuw8Rx-J07+dkA@mail.gmail.com>

Hi All,

OpenSFS and Whamcloud are engaged in delivering high-priority
enhancements to Lustre for the community.
The Solution Architecture and High Level Design for MDS Performance:
SMP Node Affinity have been completed and are available for comments
and feedback:
http://wiki.whamcloud.com/display/PUB/MDS+SMP+Node+Affinity+Solution+Architecture
http://wiki.whamcloud.com/display/PUB/MDS+SMP+Node+Affinity+High+Level+Design

With best regards,
Richard
-- 
Richard.Henwood at whamcloud.com
Whamcloud Inc.
tel: +1 512 410 9612

From Roman_Grigoryev at xyratex.com  Wed May 16 13:57:24 2012
From: Roman_Grigoryev at xyratex.com (Roman Grigoryev)
Date: Wed, 16 May 2012 17:57:24 +0400
Subject: [Lustre-devel] [more info] [Twg] Separated test execution
In-Reply-To: <4FB17224.1050105@xyratex.com>
References: <4FB17224.1050105@xyratex.com>
Message-ID: <4FB3B244.7080309@xyratex.com>

Hi all,

I did (wit Alexanders help) 2 test executions on our latest lustre build
with limited set of test suites. *

First tests execution*: executing all tests with with ONLY keyword
one-by-one.

*Second execution*: executing all tests with with ONLY keyword
one-by-one and reformat lustre partition
(/usr/lib64/lustre/tests/llmountcleanup.sh and FORMAT=yes sh
/usr/lib64/lustre/tests/llmount.sh).

With these executions ways we should detect all tests dependencies
(exclude false pass, but this it other problem).

I prepared table with results for both executions and differences
between them.

Crossed tests - tests which are in ALWAYS_EXLUDED list.
 
So, it is 15 test which was failed with ONLY/ ONLY+REFORMAT.
Test  replay-single.44a.test  is killed by timeout, and can be excluded
from this list.
Tests sanity-quota.18b and sanity.129 failed because end of space(and
looks like formatting fix it).
So, 12 test have dependencies and should be fixed.  I think this is good
news.

 suite 	 with reformat 	 without reformat
	 diff
 sanity 	 
sanity.200h.test  	
	
sanity.200c.test 	
	
sanity.201b.test
	
	
sanity.200d.test
	
	
sanity.51c.test
	
	
sanity.42d.test
	
	
sanity.201c.test 	
	
sanity.200b.test 

	 
sanity.201b.test 	
	
sanity.200d.test 	
	
sanity.51c.test 	
	
sanity.42d.test 	
	
sanity.129.test 	
	
sanity.201c.test 

	 +200h
 +200c
 +200b
 -129
 sanityn 	 
 sanityn.14b.test
	
	
 sanityn.1b.test  	
	
 sanityn.1c.test  	
	
 sanityn.28.test  	
	
 sanityn.29.test

	 
 sanityn.14b.test
	
	
 sanityn.1b.test  	
	
 sanityn.1c.test  	
	
 sanityn.28.test  	
	
 sanityn.29.test 

	 no diff
 sanity-quota 	 none 	 sanity-quota.18b.test
	 -18b
 conf-sanity 	 none 	 none 	 no diff
 ost-pools
	 none 	 none 	 no diff
 lustre-rsync-test 	 none 	 none 	 no diff
 insanity 	 insanity.10.test
	 insanity.10.test
	 no diff
 replay-vbr 	 none 	 none 	 no diff
 replay-dual 	 none 	 none 	 no diff
 replay-ost-single 	 none 	 none 	 no diff
 recovery-small 	 
 recovery-small.3.test
	
	
 recovery-small.5.test 	
	
 recovery-small.52.test 	
	
 recovery-small.2.test 

	 
recovery-small.3.test
	
	
 recovery-small.5.test 	
	
 recovery-small.52.test 	
	
 recovery-small.2.test 

	 no diff
 replay-single 	 replay-single.44a.test
	 replay-single.44a.test
	 no diff


Thanks,
            Roman


On 05/15/2012 12:59 AM, Alexander Lezhoev wrote:
> Hi there,
>
> Let me raise the question about Lustre tests separated execution.
> We've discussed this problem already, but I'd like to clear up some
> details.
>
> Usually we run all tests sequentially, but in the automation tool we
> are using we need to run tests separately, with ONLY parameter. This
> allows us to have full control over the test execution: terminate hung
> tests by timeout or restore environment in case of the file system
> damage. At the moment some of tests are designed to be run sequentially.
>
> By our estimation, there are about 30 tests need for the  improvement.
> If we settle this question, we can significantly improve
> test-framework automation potential.
> Please share your opinions about this question and help to make a
> decision about it.
> The questions are
>
>  1. Do we want to have an ability to run each test independently?
>  2. What is more acceptable - unite sequential tests into complex ones
>     or supplement exists test with additional code steps?   
>
>
>
> Some technical details:
>
> Typical problem is sanityn test_1
>
> test_1a() {
>    touch $DIR1/f1
>    [ -f $DIR2/f1 ] || error
> }
> run_test 1a "check create on 2 mtpt's =========================="
>
> test_1b() {
>    chmod 777 $DIR2/f1
>    $CHECKSTAT -t file -p 0777 $DIR1/f1 || error
>    chmod a-x $DIR2/f1
> }
> run_test 1b "check attribute updates on 2 mtpt's ==============="
>
> test_1c() {
>    $CHECKSTAT -t file -p 0666 $DIR1/f1 || error
> }
> run_test 1c "check after remount attribute updates on 2 mtpt's ="
>
> test_1d() {
>    rm $DIR2/f1
>    $CHECKSTAT -a $DIR1/f1 || error
> }
> run_test 1d  "unlink on one mountpoint removes file on other ===="
>
>
> They cannot be run separately, because the next index uses the code of
> previous one. This means all tests should be run in groups of letter
> indexes, or they should be refactored to run independently.
>
> Some of tests have been already refactored to run "letters"
> separately, but we have to make a rule which we should follow and use
> for further refactoring.
> There are three decisions we can take about this situation
>
>   * Join the code of all test steps into single test with
>     corresponding number. So we will have one test_1 instead of
>     test_1a .. test_1d in the described case.
>   * Move the code of steps to corresponding functions which will be
>     called from each step. In other words the next indexed test will
>     duplicate some functionality of previous one.
>   * Do nothing and decide that "letters" mustn't be executed
>     independently, but only in "number" group.
>
>
> The first variant could be implemented as follows.
>
> test_1() {
>
> touch $DIR1/f1
>
> [ -f $DIR2/f1 ] || error "check create on 2 mtpt's failed"
>
> chmod 777 $DIR2/f1
>
> $CHECKSTAT -t file -p 0777 $DIR1/f1 || error "check attribute updates
> on 2 mtpt's failed"
>
> chmod a-x $DIR2/f1
>
> $CHECKSTAT -t file -p 0666 $DIR1/f1 || error "check after remount
> attribute updates on 2 mtpt's failed"
>
> rm $DIR2/f1
>
> $CHECKSTAT -a $DIR1/f1 || error "unlink on one mountpoint removes file
> on other failed"
>
> }
> run_test 1 "check attributes updates on 2 mtpt's"
>
> This approach has disadvantage that such kind of refactoring will lead
> to reduction of test numbering and it will hard to work with
> regression history of the refactored tests.
> The second case of refactoring can look like this:
>
> test_1a() {
>    test_1_create
> }
> run_test 1a "check create on 2 mtpt's =========================="
>
> test_1b() {
>    test_1_create
>    test_1_check_attr
> }
> run_test 1b "check attribute updates on 2 mtpt's ==============="
>
> test_1c() {
>    test_1_create
>    test_1_check_attr
>    test_1_check_attr2
> }
> run_test 1c "check after remount attribute updates on 2 mtpt's ="
>
> test_1d() {
>    test_1_create
>    test_1_check_attr
>    test_1_check_attr2
>    test_1_unlink
> }
> run_test 1d  "unlink on one mountpoint removes file on other ===="
>
> I've omitted functions code - their content is obvious.
> This disadvantage of this approach --- summary increase of tests
> run-time (the next test duplicates code of previous one). But the
> necessity of all these tests is doubtful here, because the last one
> includes first three tests.
>
> Very similar situation is for recovery-small 1, 2, 3 and 4, 5.
>
> test_1() {
> drop_request "mcreate $DIR/f1" || return 1
> drop_reint_reply "mcreate $DIR/f2" || return 2
> }
> run_test 1 "mcreate: drop req, drop rep"
>
> test_2() {
> drop_request "tchmod 111 $DIR/f2"  || return 1
> drop_reint_reply "tchmod 666 $DIR/f2"  || return 2
> }
> run_test 2 "chmod: drop req, drop rep"
>
> test_3() {
> drop_request "statone $DIR/f2" || return 1
> drop_reply "statone $DIR/f2"   || return 2
> }
> run_test 3 "stat: drop req, drop rep"
>
> These three tests are actually steps of a single test scenario,
> because they work with the results of previous ones.
>
> We can separate these tests:
>
> test_1() {
>    test_1_mcreate
> }
> run_test 1 "mcreate: drop req, drop rep"
>
> test_2() {
>    test_1_mcreate
>    test_2_chmod
> }
> run_test 2 "chmod: drop req, drop rep"
>
> test_3() {
>    test_1_mcreate
>    test_3_stat
> }
> run_test 3 "stat: drop req, drop rep"
>
> or join them into one and remove test_2 and test_3.
>
> test_1() {
>    drop_request "mcreate $DIR/f1"  || return 1
>    drop_reint_reply "mcreate $DIR/f2"    || return 2
>    drop_request "tchmod 111 $DIR/f2"  || return 3
>    drop_reint_reply "tchmod 666 $DIR/f2"    || return 4
>    drop_request "statone $DIR/f2" || return 5
>    drop_reply "statone $DIR/f2"   || return 6
> }
> run_test 1 "mcreate, chmod,stat: drop req, drop,req"
>
>
> Another big example are sanity tests 200 and 201. Here is the part of
> the resulting code after refactoring, so we can separately run each
> letter index:
>
> test_200a() {
>   test_200_create_pool
>   test_201_remove_pool
> }
> run_test 200a "Create new pool =========================================="
>
> test_200b() {
>   test_200_create_pool
>   test_200_add_targets
>   test_201_remove_all_targets
>   test_201_remove_pool
> }
>
> . . .
>
> test_201b() {
>   test_200_create_pool
>   test_200_add_targets
>   test_200_dir_set_pool
>   test_200_check_dir_pool
>   test_200_check_file_alloc
>   test_200_create_files
>   test_200_create_relative_path_files
>   test_201_remove_all_targets
>   test_201_remove_pool
> }
> run_test 201b "Remove all targets from a pool =========================="
>
> test_201c() {
>   test_200_create_pool
>   test_201_remove_pool
> }
> run_test 201c "Remove a pool ============================================"
>
>
> We have to include cleanup steps here to make possible to run letter
> indexes independently. With that cleanup steps, 200a and 201c became
> absolutely equal and need to be reduced. Same situation is for 200h
> and 201b.
>
>
>
> Sorry for so long email and thanks to Kyr
> (Kyrylo_Shatskyy at xyratex.com) for it's preparing.
>
> -- 
> Alexander Lezhoev.
> Morpheus test team.
> Xyratex.
>
>
>
> _______________________________________________
> twg mailing list
> twg at lists.opensfs.org
> http://lists.opensfs.org/listinfo.cgi/twg-opensfs.org

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.lustre.org/pipermail/lustre-devel_lists.lustre.org/attachments/20120516/fa05b5c1/attachment.html>

From kelly.zhang at emc.com  Wed May 30 10:44:03 2012
From: kelly.zhang at emc.com (kelly.zhang at emc.com)
Date: Wed, 30 May 2012 06:44:03 -0400
Subject: [Lustre-devel] Fail to build Lustre on SUSE11
Message-ID: <F62E2618FCA29E42AB21F281C9511BB4137DACAE61@MX26A.corp.emc.com>

Hello,

There is a compiling error when building Lustre rpms on SUSE11, at "make rpms". Would you please help to check this.
The error is like:
/home/build/kernel/rpmbuild/BUILD/lustre-2.2.52/lustre/llite/llite_lib.c: In function "ll_setattr_raw":
/home/build/kernel/rpmbuild/BUILD/lustre-2.2.52/lustre/llite/llite_lib.c:1343: error: implicit declaration of function "inode_newsize_ok "
make[8]: *** [/home/build/kernel/rpmbuild/BUILD/lustre-2.2.52/lustre/llite/llite_lib.o] Error 1
make[7]: *** [/home/build/kernel/rpmbuild/BUILD/lustre-2.2.52/lustre/llite] Error 2
make[6]: *** [/home/build/kernel/rpmbuild/BUILD/lustre-2.2.52/lustre] Error 2
make[5]: *** [_module_/home/build/kernel/rpmbuild/BUILD/lustre-2.2.52] Error 2
make[5]: Leaving directory `/var/tmp/kernel-source-2.6.27.19-build/usr/src/linux-2.6.27.19-5.1'
make[4]: *** [modules] Error 2
make[4]: Leaving directory `/home/build/kernel/rpmbuild/BUILD/lustre-2.2.52'
make[3]: *** [all-recursive] Error 1
make[3]: Leaving directory `/home/build/kernel/rpmbuild/BUILD/lustre-2.2.52'
make[2]: *** [all] Error 2
make[2]: Leaving directory `/home/build/kernel/rpmbuild/BUILD/lustre-2.2.52'
error: Bad exit status from /var/tmp/rpm-tmp.54512 (%build)


RPM build errors:
    Bad exit status from /var/tmp/rpm-tmp.54512 (%build)
make[1]: *** [rpms-real] Error 1
make[1]: Leaving directory `/home/build/lustre'
make: *** [rpms] Error 2

Building machine arch: x86_64
Distribution: SUSE 11 SP1
Kernel Version used for building: 2.6.27.19-5.1

Best Regards,
Kelly(EMC)
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.lustre.org/pipermail/lustre-devel_lists.lustre.org/attachments/20120530/d0660ee3/attachment.html>

From kelly.zhang at emc.com  Thu May 31 10:17:10 2012
From: kelly.zhang at emc.com (kelly.zhang at emc.com)
Date: Thu, 31 May 2012 06:17:10 -0400
Subject: [Lustre-devel] Lustre sanity test_226 fails
Message-ID: <F62E2618FCA29E42AB21F281C9511BB4137DACAF52@MX26A.corp.emc.com>

Hi all,

When running sanity.sh, sometimes test_226 would fail with the following error:

lfs fid2path /mnt/lustre [0x200000404:0x1a:0x0]

ioctl err -22: Invalid argument (22)

fid2path error: Invalid argument

We tried Whamcloud master (6b1daa840a66703446c238d1efb3f13dd93012ee), and get the same error.
Run test_226 twice, it is likely to meet one failure.

I did not find such error in Maloo, so would you please help to check this? Thanks a lot.

Best Regards,
Kelly(EMC)

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.lustre.org/pipermail/lustre-devel_lists.lustre.org/attachments/20120531/3d674c17/attachment.html>