Re: Mainlining Lustre client

[Peng Tao <tao.peng@emc.com>]

Hi Andreas,

On Sun, Apr 28, 2013 at 3:09 AM, Andreas Dilger <adilger@dilger.ca> wrote:
>
> Tao,
> thanks for starting to look into this.
>
Thank you for not complaining me creating more work for you :)

> Does it really make sense to stage a filesystem under drivers/*?
> IMHO it makes a lot more sense to put the components into the
> location where they would live in the upstream kernel tree (i.e.
> fs/lustre and net/lnet).
>
This is how current patches are created. And I agree with you that
putting the code in fs/lustre and net/lnet and depending on
CONFIG_STAGING will be more convenient for future development.  It is
also what Trond suggested in last year's LSF-MM summit. Personally I
am OK with either way though.

So it is indeed a question to Greg and Al: Do you have any objections
if we put lustre client code in fs/lustre and net/lnet, depending it
on CONFIG_STAGING? Thanks very much!

> Also a question for you - what version of the Lustre client
> are you intending to submit to the staging tree?  We are very close
> to the 2.4.0 release, so it definitely makes sense to start with
> that one.
>
The current patch was created before LUG 2013, based on Whamcloud's
master HEAD at that time, plus several under-review patches in Intel
Jira to get 3.8/3.9 kernel support and code extraction. I will create
the new big patch based on the current master HEAD which is closer to
the 2.4.0 release. And future patches can be ported to staging client
incrementally. Does it sound OK to you?

> There is also the question of how you will keep the staging client
> in-sync with the development done in the upstream Lustre repo?
>
Certainly patches will be ported between staging client and the
development done in Lustre repo back and forth. All bugfix and new
feature patches will be ported to staging client. Cleanup patches will
also be ported to Lustre repo when necessary. As HCH once mentioned,
it is a price we must pay to get a long-time out-of-tree file system
mainlined :-)

> There has definitely been a lot of work done to clean up the
> Lustre code, but there is still a considerable amount of work
> left to be done.  In particular, the CLIO layer needs a bunch of
> cleanup to become more efficient and understandable.
>
I agree that there is still a fair amount of work left. IMHO, the CLIO
layer cleanup is more about coping with upstream kernel's
readahead/writeback mechanisms and thus it should more or less involve
Al, Christoph and maybe others' (like Fengguang Wu's) opinions. So it
can be done during the staging time.

Thanks for your strong support all the time!

Best Regards,
Tao