At a minimum there are a few upstream commits from Peng Tao that need to be back ported:
https://git.kernel.org/cgit/linux/kernel/git/gregkh/staging.git/commit/drivers/staging/lustre?h=staging-next&id=ea8352c289294e21ee13bdb105f55dc63497acff staging/lustre/libcfs: cleanup linux-mem.h
https://git.kernel.org/cgit/linux/kernel/git/gregkh/staging.git/commit/drivers/staging/lustre?h=staging-next&id=3bb22ec53e2bd12a241ed84359bffd591a40ab87 staging/lustre/ptlrpc: convert to new shrinker API
https://git.kernel.org/cgit/linux/kernel/git/gregkh/staging.git/commit/drivers/staging/lustre?h=staging-next&id=fe92a0557a6f332119c51fdd2f3d574040989447 staging/lustre/obdclass: convert lu_object shrinker to count/scan API
https://git.kernel.org/cgit/linux/kernel/git/gregkh/staging.git/commit/drivers/staging/lustre?h=staging-next&id=cbc3769ecd74b183d3ba5e11264cf484d8572a00 staging/lustre/ldlm: convert to shrinkers to count/scan API
These upstream mods are only good for the exact kernel version they reside in. Backports will need autoconf support to adapt to different kernel versions as well as 3.12.
http://review.whamcloud.com/8799
http://review.whamcloud.com/8800
http://review.whamcloud.com/8801
another patch is at: http://review.whamcloud.com/9230 from LU-4614.
Last sanity test result:
sanity: FAIL: test_17m e2fsck should not report error upon short/long symlink MDT: rc=4
sanity: FAIL: test_103 permissions failed
sanity: FAIL: test_133e Bad write_bytes sum, expected 1376256, got 0
sanity: FAIL: test_160a User cl1 not found in changelog_users
sanity: FAIL: test_160b User cl2 not found in changelog_users
sanity: FAIL: test_161c flag 0x0 is not 0x1
sanity: FAIL: test_184a swap of file layout failed
sanity: FAIL: test_184c swap of /mnt/lustre/d184c.sanity/184c/file1 and /mnt/lustre/d184c.sanity/184c/file2 failed
sanity: FAIL: test_200 failed to use fallback striping for empty pool
sanity: FAIL: test_200 test_200 failed with 2
test_182 dead lock the kernel
test_208 cannot umount
test_228b cannot umount
Is this for ZFS? Do you have a shrinker patch?
It is ldiskfs. Yes, I'll commit it shortly.
http://review.whamcloud.com/9300 shrinker change.
Last sanity status:
sanity: FAIL: test_17k rsync failed with xattrs enabled
sanity: FAIL: test_17l lgetxattr_size_check /mnt/lustre/d17l.sanity lustre.lov failed
sanity: FAIL: test_17m e2fsck should not report error upon short/long symlink MDT: rc=4
sanity: FAIL: test_53 can not match last_seq/last_id for OST-osc-MDT0000
sanity: FAIL: test_65k setstripe should have succeeded
sanity: FAIL: test_101b Too many (5632) discarded pages with size (8192)
sanity: FAIL: test_103 permissions failed
sanity: FAIL: test_116b can't create
sanity: FAIL: test_127a Missing read_bytes stats
sanity: FAIL: test_130b FIEMAP on /mnt/lustre/f130b.sanity failed; returned wrong number of luns or wrong len for OST 0001
sanity: FAIL: test_130c FIEMAP on /mnt/lustre/f130c.sanity failed; returned wrong number of luns or wrong len for OST 0001
sanity: FAIL: test_130e FIEMAP on /mnt/lustre/f130e.sanity failed; returned wrong number of luns or wrong len for OST 0001
sanity: FAIL: test_133c The counter for destroy on ost was not incremented
sanity: FAIL: test_133e Bad write_bytes sum, expected 1376256, got 0
sanity: FAIL: test_184c concurrent write on /mnt/lustre/d184c.sanity/184c/file1 failed
sanity: FAIL: test_220 test_220 failed with 6
test_209 stuck in shrinker process.
Last sanity status:
sanity: FAIL: test_17m e2fsck should not report error upon short/long symlink MDT: rc=4
sanity: FAIL: test_103 permissions failed
sanity: FAIL: test_184c concurrent write on /mnt/lustre/d184c.sanity/184c/file1 failed
sanity: FAIL: test_220 test_220 failed with 3
sanity: FAIL: test_231b dd of=/mnt/lustre/d231b.sanity/f231b.sanity seek=510 failed
test_209 stuck on shrink.
Link with test_103 failed.
SLES12 is also 3.12 based, so I can lend a hand here as well.l
I have it building against SLES12 Beta5. No testing done yet, but my recipe looks like:
Existing commits:
http://review.whamcloud.com/9300
http://review.whamcloud.com/9384
http://review.whamcloud.com/7936
http://review.whamcloud.com/7934
http://review.whamcloud.com/8036
http://review.whamcloud.com/8049
New commits:
http://review.whamcloud.com/10158
http://review.whamcloud.com/10159
http://review.whamcloud.com/10160
http://review.whamcloud.com/10161
http://review.whamcloud.com/10162
http://review.whamcloud.com/10163
http://review.whamcloud.com/10164
http://review.whamcloud.com/10165
I'll start some testing in the morning.
I think you left out http://review.whamcloud.com/8010 from your recipe.
Yep, missed that one when pasting. I have it applied in my local repo.
Peter can you link this ticket to LU-4960 now that Jeff has posted work for process namespace server side.
James, I can & will do that.
fwiw, I too have been able to do a successful server build following Jeff's recipe including #8010. Build only so far, no actual functional results to report.
when building with latest zfs http://review.whamcloud.com/10064 is also needed.
if building ldiskfs only, that's a don't care.
Welcome back Jeff.
I also just changed the recipe. You will now need http://review.whamcloud.com/#/c/2677 from LU-1330. Besides supporting new kernels we have been attempting to sync up the code with what is upstream in the kernel. We are getting pretty close to our goal. Still purging of the cfs_list (LU-3963) is left. There is work from LU-4423 that is backporting the upstream changes into master as well.
As for 3.12 client support only the shrinker change is needed. Everything else is merged 
Yang Sheng reported their was a bug with the shrinker still. Thank you for helping out with pushing forward server side support. One thing I like to recommend is that we create a generic pool of patches for ldiskfs agaisnt the upstream 3.12 kernel. From their we can create distro specific patches. This way the series files can share a lot of the same patches. We also have fedora fc20 support in the works. I have started to look at Ubuntu/debian support as well.
Forgot to mention the kernel patch series. The only patches you need to port are raid5-mmp-unplug-dev and bh_lru_size_config.patch. Their are also some quota scaling fixes but I don't know if those have been picked up mainstream and ended up in the SLES12 kernels. Recent test show the block tunable patches might not be worth it anymore. Also dev_read_only kernel hack will be going way. Please try out patch http://review.whamcloud.com/#/c/7200 instead. Feed back on that patch would be great.
James, for now I have been using the old 3.x-fc18.series for kernel patches. it applies cleanly but still includes the dev_read_only hack. Will look into your alternative.
We have a collision with the ext4_map_block patch from LU-3373 and the one from Jeff. It seems that the LU-3373 patch is the favored but if this is the case then we will run into conflicts with several of the patch Jeff also has pushed. It looks like we are going to have to setup the dependence correctly now. I like to suggest that the ext4_map_block patch be placed last in the dependency tree.
After reviewing both, I'd like to perform testing with my version. It's cleaner and ext4_map_blocks is being called correctly. ext4_map_blocks will return the number of blocks mapped and if it returns less than map.m_len, it needs to be called multiple times to properly map the entire range. The version in LU-3373 needs general cleanup and also to call ext4_map_blocks properly. I expect that, with the exception of the unmap_underlying_metadata call (which I'd like to see the bug report for), the result would look pretty much like mine.
Ok, so I just ran acceptance-small against my recipe and ran into:
ldiskfs_truncate needing i_mutex (WARN_ON)
scheduling while atomic (usermodehelper kmalloc + waiting) due to the upcall cache lock being a rwlock instead of a sleeping lock
procfs warnings from nrs_tbf_quantum not existing during umount
warning from inc_nlink due to I_LINKABLE not being set (introduced in Linux commit f4e0c30c19)
All of those are just annoyances and can be fixed pretty easily.
But the BUG_ON(de->name_len != 1); check in dx_get_dx_info is getting triggered as well, which has halted testing for now.
I'll dig into these a bit.
Jeff, the procfs warnings from nrs_tbf_quantum not existing during umount have already been reported elsewhere, so it's not something new in your patches. see LU-4832
Oh, yeah, I'm not expecting that they were introduced by my patches - most of these are checks that have gone into the upstream kernel and haven't been addressed yet.
The scheduling while atomic issue was introduced here:
4b7cbec39 (LU-540 misc patch for user identity upcall/downcall)
The author claimed that the allocation was unnecessary, but it was necessary to avoid holding the atomic lock across a sleeping operation. Given that the operations using this value aren't performance critical (if they were, we wouldn't be doing call_usermodehelper), we can replace the lock with a sleeping lock and keep the allocations out of it.
Oh so that is the source of the upcall backtrace I get. I have been ignoring it thinking it was due to a configuration issue on my part. The patch for the TBF NR is totally broken. When I created the patch I had no docs on how to actually test it. Li has left me some pointers in the gerrit review.
Found another scheduling while atomic issue:
ll_statahead_interpret takes &lli->lli_sa_lock
ll_intent_drop_lock
ldlm_lock_decref
ldlm_lock_decref_internal
ldlm_bl_to_thread
kmem_cache_alloc_trace oops
... this one is a bit more involved than I'm comfortable with.
I added a bit of debugging to the dx_get_dx_info BUG_ON and got back the following. AFAICT it's supposed to be "."
bad name: 0000000200000bd1:00000718:00000000: 0
Looks like that's a bug in the ldiskfs patch set.
Jeff could you reverse the order of dependency for http://review.whamcloud.com/#/c/10164 and http://review.whamcloud.com/#/c/10163. The reason is 10164 will be much easier to land and 10163 is currently broken which makes 10164 broken. Also we need to investigate to see if a performance difference happens when moving to ext4_map_blocks.
Ok, reversed the order and fixed the ext4_map_blocks patch. The entire set builds now.
There was a bug in my ext4_map_blocks patch that caused pretty much everything to return zeroes. I have a fixed version that works properly. I also have a patch that's required for any 3.10+ kernel since ext4_truncate will check that i_mutex is held. I'm going to run small-acceptance again and push the fixes.
After a quick look over, I think the main performance difference is going to come from the holes case. ext4_map_blocks handles it, but not efficiently. It should be doable to use the FIEMAP code to handle the read-only holes case and use ext4_map_blocks for the write case since the allocations paper over the performance issue AFAICT. Not that I'm volunteering to do it.
Peter can you link LU-5058 to this ticket as well. Currently a few collisions of patches are happening. What I like to recommend is that the following 3 base patches have no dependency chain so they can land in parallel.
http://review.whamcloud.com/#/c/10325 - LU-5058
http://review.whamcloud.com/#/c/10160 - LU-3953
http://review.whamcloud.com/#/c/10161 - LU-4416 - This can be the base for all the osd-ldisk changes. Remove the
LU-5058 bits.
These 3 patches don't have dependency on each other and it is much faster to land patches that lack dependencies. Since time is short we really need to focus on making RHEL7 and SLES12 client support available for Lustre 2.6. We can do the server support for Lustre 2.7. This means focusing on getting 9300, LU-3953 and LU-5058 landed ASAP. What do you think Jeff?
Works for me, though we've got demand for 2.6 server support on SLE12 AFAIK. So I'll still be plugging away on these (as they pass acceptance except for the namei.c:517 crash).
James, I put in the link you asked for.
I agree that focusing on the small set of patches needed for client support and without dependencies on each other makes sense. Really want to get at least those landed before 2.6 closes. Don't at all suggest we should slow down or stop progress on all the other patches, just that we do what's needed for clients first.
Thank you Bob. Jeff please keep doing the awesome work.
Patches needed for RHEL7 client support:
http://review.whamcloud.com/#/c/10325 - LU-5058
Additional patches needed for [SuSE12 client ] / [ generic 3.12 ] support
http://review.whamcloud.com/#/c/10160 - LU-3953
http://review.whamcloud.com/#/c/9300 - LU-4416
Patches need for ZFS server support include the above plus:
http://review.whamcloud.com/#/c/7934
http://review.whamcloud.com/#/c/8049
Think there's a typo in your list. don't you mean:
http://review.whamcloud.com/#/c/10160 - LU-3953
http://review.whamcloud.com/#/c/9300 - LU-4416
?
fixed.
For the latest master all patches needed for client support of 3.12 kernels has been landed. This covers both RHEL7 and SuSE 12 clients.
If you want ZFS back end support with 3.12 kernels you will need the following two patches:
http://review.whamcloud.com/#/c/7934 - LU-3319 ZFS lprocfs updates
http://review.whamcloud.com/#/c/8049 - LU-3319 mdd/ofd lprocfs updates
Currently ldiskfs development is in the early stages for 3.12 kernel supports. The list of patches currently under development can be reviewed with the following link
http://review.whamcloud.com/#/q/status:open+message:LU-4416,n,z
In addition for RHEL7 ldiskfs support the following patch needs to be applied:
Currently clients on newer kernels require you to modprobe lustre before you do a client mount. This is fix in the patch
http://review.whamcloud.com/#/c/10587 from LU-4800.
For people wanted to use an external OFED stack (3.12 or Mellanox) you will need patch http://review.whamcloud.com/#/c/10571
from LU-5140. This patch also fixes this issue on select SLES11 SP3 platforms (Cray) as well.
Time for a update. All the needed LU-3319 patches for ZFS server support has landed. Lustre 2.6 should be able to support ZFS server support on RHEL7 or SuSE12 now. One last cleanup patch will be produced for LU-3319 but it is not necessary to land it for 2.6 to get server support.
Currently osd-ldiskfs is still in development but should be ready for 2.7. Patches for that work
can be viewed here http://review.whamcloud.com/#/q/status:open+message:LU-4416,n,z
For client support the patch for LU-4800 has landed. This means you can mount clients without the need to modprobe the lustre modules first. Client support is very well supported at this point. If you are using a external OFED stack you will need patch http://review.whamcloud.com/#/c/10571 from LU-5140.
Update : The patch for LU-5140 just landed so clients on newer kernels will build and work with new OFED stacks.
I have done some experimenting with the ldiskfs patch for SuSE12 to discover their is only one patch in that series that can't be applied to the 3.12.22 upstream linux kernel trree. Since this is the case I like to purpose we create a 3.12 series file and extend SuSE12 and RHEL7 off of it.The reason for this is so we can start organizing the patches we should be sending upstream to the
ext4 maintainers. I like to create another 3.X-upstream series file as well to sync to every 3.X version that comes out. In the end the goal will be to no longer need ldiskfs.
I think the recent landing of fix for LU-4906 has broken the build for 3.12. Can't even build clients anymore, I get build errors from llite/dir.c. I think there was a commit some time ago changing readdir code in osd-ldiskfs. I suspect recent changes to dir.c didn't take into account the HAVE_DIR_CONTEXT case from autoconf wrt readdir code.
Looking into it. Can you post what build error you get?
added a bit more detail in LU-5234 for this specific issue
As Bob has mentioned a new issue has merged in master that broke client support for RHEL7 and SuSE12. I have a patch to resolve this at http://review.whamcloud.com/#/c/10761 which is related to LU-5234. Please give it a try.
As of today all patches needed for client and zfs support has landed. Many patches for ldiskfs has landed but more testing and work needs to be done. The patches left for ldiskfs support are:
http://review.whamcloud.com/#/c/8116 - LU-3373 / LU-5276 ext4_map_block support
http://review.whamcloud.com/#/c/10376 - LU-4416 limit transaction size in ldiskfs
http://review.whamcloud.com/#/c/10165 ldiskfs for 3.12 / SuSE12
http://review.whamcloud.com/#/c/10249 - LU-5022 RHEL7 ldiskfs support
More patches have landed. The patches left for ldiskfs support are:
http://review.whamcloud.com/#/c/10376 - LU-4416 limit transaction size in ldiskfs
http://review.whamcloud.com/#/c/10165 ldiskfs for SuSE12
http://review.whamcloud.com/#/c/10249 - LU-5022 RHEL7 ldiskfs support.
Down to two patches.
http://review.whamcloud.com/#/c/10165 ldiskfs for SuSE12 support
http://review.whamcloud.com/#/c/10783 fix for a conf-sanity test so it can pass maloo
All that is left to land is http://review.whamcloud.com/#/c/10165 which covers ldiskfs for SuSE12 support.
Jeff I like to discuss how to go about to make a pathless server for SLES12 support. Currently three primary patches are needed:
bh_lru_size_config.patch - a simple which might change based on what will go upstream. Andrew Morton discuss just having BH_LRU_SIZE
changes to 16 in the kernel.
quota enhancement patches - These have already been merged upstream as the following commits
commit b9ba6f94b2382ef832f97122976b73004f714714
commit 9eb6463f31cf720deaf0e810cacc403d7720b10c
commit 1ea06bec78a128adc995ca32bd906a6c9bb9cf91
commit 606cdcca04a609ed4dfbfe788942de9477da556b
commit d68aab6b8f572406aa93b45ef6483934dd3b54a6
It would be really nice to have those merged into your tree.
Lastly the work under LU-3406. That is just starting to get underway and once we have a proper solution then it could also be integrated as well.
Hi James, I'm afraid we're too late to incorporate the quota changes. SLE12 GA was released last week. The quota changes would change the kABI so we can't accept them into the release. Unless LU-3406 has changes substantially since I asked Neil Brown to take a look at it last year, we won't be able to accept that one either. He had serious reservations about whether it would end up causing corruption in use. The configurable BH_LRU_SIZE change might be acceptable since it's local to fs/buffer.c
Jeff since SLES11SP4 is not out just yet would you consider having the BH_LRU_SIZE and quota improvements merged into your kernel?
I can propose it. We're technically past our feature request deadline, but I can present it as a late change request.
I think main issue is push http://review.whamcloud.com/7200 can be landed asap.
Bob Glossman (bob.glossman@intel.com) uploaded a new patch: http://review.whamcloud.com/14532
Subject: LU-4416 build: add build files for SLES 12 client build
Project: fs/lustre-release
Branch: master
Current Patch Set: 1
Commit: 35b55f7f4b2390b4145b6898ccd8e4fb421c7da3
Oleg Drokin (oleg.drokin@intel.com) merged in patch http://review.whamcloud.com/14532/
Subject: LU-4416 build: add build files for SLES 12 client build
Project: fs/lustre-release
Branch: master
Current Patch Set:
Commit: 48416b83331778f564986b8c96ee6d362123af76
Looks like this ticket can be close after http://review.whamcloud.com/#/c/10165/ landed.
Oleg Drokin (oleg.drokin@intel.com) merged in patch http://review.whamcloud.com/10165/
Subject: LU-4416 ldiskfs: enable support for SLES12
Project: fs/lustre-release
Branch: master
Current Patch Set:
Commit: 9067f1b50aaeae2a79dfa9f777f96637c3d4bb05
Landed for 2.8