Details
-
Improvement
-
Resolution: Fixed
-
Minor
-
None
-
None
-
8342
Description
This ticket intended to track ldiskfs patches work on FC18 3.7 kernel.
Attachments
Issue Links
- is duplicated by
-
LU-3228 fc18: sanity test_183: @@@@@@ FAIL: test_183 failed with 1
-
- Resolved
-
- is related to
-
-
- Resolved
-
-
-
- Resolved
-
-
-
- Resolved
-
- is related to
-
-
- Resolved
-
-
-
- Resolved
-
Activity
http://review.whamcloud.com/#/c/8231 is ready for inspection and possible merger.
I see patch 8116 has been abandon. I believe the point of the patch was to limit the port of patches for fc19 support. Do this mean the ldiskfs patches will be updated or will the rhel6.5 patch be enough?
http://review.whamcloud.com/#/c/8116 looks ready for inspection and possible merger.
I think LU-4209 already exists to address the problem with O_LOV_DELAY_CREATE.
O_LOV_DELAY_CREATE conflict with __O_TMPFILE. Need change it. lod and osp procfs patch need fix some bug. I have commented in gerrit.
Ran several jobs (various IOR, mdtest configurations and a science app) against the 3.11 base lustre file system using ldiskfs. It was successful so I would say we are in pretty good shape.
One odd quirk. lustre-ldiskfs.spec is setup with a Requires: modutils. However there isn't any rpm in fedora that provides modutils. I could only install lustre with a --force option on the command line.
Looks like in earlier distro modutils was one of the Provides: in the module-init-tools rpm. The fedora rpm that contains similar files as the old module-init-tools rpm is named kmod, but it has no Provides: modutils in it.
it lives, take II
I'm seeing first signs of life now with ldiskfs in fc19:
[root@fedora19 tests]# llmount.sh Stopping clients: fedora19 /mnt/lustre (opts:) Stopping clients: fedora19 /mnt/lustre2 (opts:) Loading modules from /usr/lib64/lustre/tests/.. detected 1 online CPUs by sysfs libcfs will create CPU partition based on online CPUs debug=vfstrace rpctrace dlmtrace neterror ha config ioctl super subsystem_debug=all -lnet -lnd -pinger gss/krb5 is not supported quota/lquota options: 'hash_lqs_cur_bits=3' Formatting mgs, mds, osts Format mds1: /tmp/lustre-mdt1 Format ost1: /tmp/lustre-ost1 Format ost2: /tmp/lustre-ost2 Checking servers environments Checking clients fedora19 environments Loading modules from /usr/lib64/lustre/tests/.. detected 1 online CPUs by sysfs libcfs will create CPU partition based on online CPUs debug=vfstrace rpctrace dlmtrace neterror ha config ioctl super subsystem_debug=all -lnet -lnd -pinger gss/krb5 is not supported Setup mgs, mdt, osts Starting mds1: -o loop /tmp/lustre-mdt1 /mnt/mds1 Started lustre-MDT0000 Starting ost1: -o loop /tmp/lustre-ost1 /mnt/ost1 Started lustre-OST0000 Starting ost2: -o loop /tmp/lustre-ost2 /mnt/ost2 Started lustre-OST0001 Starting client: fedora19: -o user_xattr,flock fedora19@tcp:/lustre /mnt/lustre Using TIMEOUT=20 seting jobstats to procname_uid Setting lustre.sys.jobid_var from disable to procname_uid Changed after 0s: from '' to 'disable' Waiting 90 secs for update Updated after 9s: wanted 'procname_uid' got 'procname_uid' disable quota as required [root@fedora19 tests]# lfs df UUID 1K-blocks Used Available Use% Mounted on lustre-MDT0000_UUID 133560 1576 118624 1% /mnt/lustre[MDT:0] lustre-OST0000_UUID 171080 9380 147700 6% /mnt/lustre[OST:0] lustre-OST0001_UUID 171080 9380 147700 6% /mnt/lustre[OST:1] filesystem summary: 342160 18760 295400 6% /mnt/lustre
Send it my way. I will try it out. Tomorrow I will setup a real file system using a 3.11 kernel to see how it holds up. If it holds up I plan to mount it on our cray test bed and run a bunch of jobs to stress test it.
Patches landed to Master. Final patch http://review.whamcloud.com/#/c/8116 is being tracked under
LU-5276