Details
-
Technical task
-
Resolution: Fixed
-
Major
-
Lustre 2.5.0
-
None
-
8659
Description
ldiskfs is a prerequisite of lustre. But instead of building the prerequisite before lustre, we have chosen to stop and perform the build of in the middle of the lustre. That introduces a great deal of unnecessary complexity to the lustre build system. The complexity is so great, that we have allowed the normal* way of building RPMs to remain broken for years. Our .src.rpm files remain unbuildable under many normal situations.
To make further progress on LU-1199, this major problem must be addressed. As I see it, there are two main solutions we could choose:
- Move ldiskfs out of the lustre source tree. Build it first.
- Keep ldiskfs in-tree, but eliminate its independant build system and spec file. The ldiskfs binary rpm becomes a sub-module of lustre.spec.
I have been moving us towards option 1. I have gotten enough change landed to allow ldiskfs to be built out of tree. It will not take much change to allow Lustre to use the externally pre-build ldiskfs packages. We already do this at LLNL, so I'm pretty clear on what needs to be done there.
I think option 1 would also position us nicely is James Simmons is successful in getting all of the ldiskfs into the upstream kernel at some point. We will already be comfortable at that point building against an ldiskfs that is out of tree.
It is also nicely symmetric with how we build against an external zfs today (and perhaps btrfs in the future). Even if we wind up needed to make an "lbtrfs" in the future, I don't think we would want to repeat the choice to try to merge that into the lustre tree.
I would like to see a quick decision from Intel on which path we should take for Lustre 2.5, so that we can get the change introduced early in the development cycle. That will give us some time to adjust all of our personal processes, and get the kinks worked out well in advance of release.
* I am defining "normal" to be the way that a distro like fedore would do it: first build ldiskfs rpms, including devel packages. Then build lustre against the already built ldiskfs packages.
Attachments
Issue Links
- is duplicated by
-
LU-3955
Eliminate ldiskfs recursive & independent rpm packaging
-
- Closed
-
Activity
Just verified it is the LU-4314 issue with parallel builds. If I change the make flag options it builds. Will move discussion over to there.
Minh I looked at LU-4314 which appears to be the same error I got. I will try the patch their to see if it does address my issue.
Yes I was. Have you seen this with using a external OFED stack?
James,
When you saw the ftrace compile issue above, were you using any external OFED?
Chris since this patch has landed I'm seeing the follow errors.
James, could you start a new ticket for that? I'll forget about this in no time if it is on a closed ticket.
Include which kernel you are using. Maybe configuration options too. I am not seeing that error, and I don't have any ideas off the top of my head.
Chris since this patch has landed I'm seeing the follow errors.
lustre-2.4.92-broke/ldiskfs/trace/events/ldiskfs.h: In function ‘ftrace_profile_enable_ldiskfs_free_inode’:
lustre-2.4.92-broke/ldiskfs/trace/events/ldiskfs.h:18: error: implicit declaration of function ‘register_trace_ldiskfs_free_inode’
lustre-2.4.92-broke/ldiskfs/trace/events/ldiskfs.h: In function ‘ftrace_profile_disable_ldiskfs_free_inode’:
lustre-2.4.92-broke/ldiskfs/trace/events/ldiskfs.h:18: error: implicit declaration of function ‘unregister_trace_ldiskfs_free_inode’
lustre-2.4.92-broke/ldiskfs/trace/events/ldiskfs.h: In function ‘ftrace_profile_enable_ldiskfs_request_inode’
I have looked over the code in detail to see what is wrong but can't figure it out. Do you have any ideas?
James, the patch to fix the ldiskfs issue is in
LU-4266