Details
-
Task
-
Resolution: Fixed
-
Major
-
Lustre 2.1.0, Lustre 1.8.6
-
None
-
16,038
-
4966
Description
In order for Lustre to use OSTs larger than 16TB, the e2fsprogs "master" branch needs to be tested against such large LUNs. The "master" branch has unreleased modifications that should allow mke2fs, e2fsck, and other tools to use LUNs over 16TB, but it has not been heavily tested at this point.
Bruce, I believe we previously discussed a test plan for this work, using llverdev and llverfs. Please attach a document or comment here with details. The testing for 16TB LUNs is documented in https://bugzilla.lustre.org/show_bug.cgi?id=16038.
After the local ldiskfs filesystem testing is complete, then obdfilter-survey and full Lustre client testing is needed.
Attachments
Activity
| Attachment | New: large-LUN-inodes.suite_log.ddn-sfa10000e-stack01.build273.log [ 10429 ] |
| Fix Version/s | New: Lustre 2.1.0 [ 10021 ] | |
| Resolution | New: Fixed [ 1 ] | |
| Status | Original: Open [ 1 ] | New: Resolved [ 5 ] |
| Attachment | New: large-LUN-inodes.suite_log.ddn-sfa10000e-stack01.build263.log [ 10364 ] |
| Attachment | New: large-LUN-inodes.suite_log.ddn-sfa10000e-stack01.log [ 10353 ] |
| Attachment | New: 128TB_partial.log [ 10210 ] |
| Comment |
[ bq. For large filesystems it looks like it is faster after the llverfs "full" test to reformat the filesystem than remounting the filesystem and deleting all of the test files. I modified the test script to reformat the OST after the llverfs "full" test on the "ldiskfs" filesystem, and kept the remount-and-delete way after the llverfs "partial" tests on both the "ldiskfs" and "lustre" filesystems. However, the remounting of "lustre" filesystem hung as follows: {noformat} ========================= setup the Lustre filesystem ========================= # mount -t lustre -o user_xattr,acl /dev/large_vg/mdt_lv /mnt/mds1 /dev/large_vg/mdt_lv on /mnt/mds1 type lustre (rw,user_xattr,acl) Filesystem Size Used Avail Use% Mounted on /dev/large_vg/mdt_lv 1.8G 112M 1.6G 7% /mnt/mds1 # mount -t lustre -o extents,mballoc /dev/large_vg/ost_lv /mnt/ost1 /dev/large_vg/ost_lv on /mnt/ost1 type lustre (rw,extents,mballoc) Filesystem Size Used Avail Use% Mounted on /dev/large_vg/ost_lv 7.9G 7.5G 124K 100% /mnt/ost1 # mount -t lustre -o user_xattr,acl,flock 192.168.77.4@o2ib:/largefs /mnt/lustre {noformat} Dmesg showed that: {noformat} LustreError: 13799:0:(ldlm_lib.c:944:target_handle_connect()) largefs-MDT0000: denying connection for new client 0@lo (c3724b30-3f1e-8ed7-d7eb-dcfd7b2c9822): 1 clients in recovery for 300s LustreError: 13799:0:(ldlm_lib.c:1919:target_send_reply_msg()) @@@ processing error (-16) req@ffff8101b8f2bc00 x1368490566115054/t0 o38-><?>@<?>:0/0 lens 368/264 e 0 to 0 dl 1305094648 ref 1 fl Interpret:/0/0 rc -16/0 LustreError: 11-0: an error occurred while communicating with 0@lo. The mds_connect operation failed with -16 {noformat} Maloo report: https://maloo.whamcloud.com/test_sets/b8983b34-7ba0-11e0-b5bf-52540025f9af As we can see, after the llverfs "partial" test on the "lustre" filesystem, the OST was out of space and remounting the Lustre filesystem hung. Andreas, is this a Lustre issue? I modified the test script again to reformat the MDT and OST after the llverfs "partial" test and before "full" test on "lustre" filesystem. The test passed as follows: https://maloo.whamcloud.com/test_sets/36d13d86-7b9f-11e0-b5bf-52540025f9af Could you please review the above report again? ] |
| Attachment | New: llverdev_b1_8_master.diff [ 10191 ] | |
| Attachment | New: llverfs_b1_8_master.diff [ 10192 ] |
| Affects Version/s | New: Lustre 1.8.6 [ 10022 ] |
| Assignee | Original: Bruce Cassidy [ bruce ] | New: Jian Yu [ yujian ] |