Did some tests, finished 30% code.
I just noticed this here, while it is still easy to browse through all the open issues 
Just for your information, the offline approach: https://bugzilla.lustre.org/show_bug.cgi?id=22734
Thanks for pointing this out, which explains a lot of details on LAST_ID recovery!
Code is ready, and in inspection.
It probably makes sense for Fan Yong to implement this as part of the LFSCK project, so that an OST can recover from some common forms of corruption.
The existing patch is at http://review.whamcloud.com/141, but needs to be refreshed.
It will be considered in LFSCK phase II.
In discussions during LU-2886 patch http://review.whamcloud.com/6199 inspection, it was proposed to improve the on-disk format of the LAST_ID file:
struct last_id_ondisk {
__u64 lio_next_oid;
__u32 lio_magic;
__u32 lio_cksum;
};
and ofd_seq_load() (maybe rename this to ofd_seq_last_oid_read()?), ofd_seq_last_oid_write() and ll_recover_lost_found_objs.c should updated to handle both an old 8-byte LAST_ID file, and this new 16-byte format. If the on-disk LAST_ID file is corrupted (bad lio_magic, bad lio_cksum, lio_next_oid > OBIF_MAX_OID for seq != 0, lio_next_oid > IDIF_MAX_OID for fid_seq == 0) it would be treated the same as if it where missing, and this LAST_ID recovery code should traverse the object directories for that group and rebuild the LAST_ID file.
This would avoid the case where the LAST_ID file has some random garbage in it and causes an inconsistency between the MDT's and OST's understanding of what the next valid OID is.
The one missing part of this process is to be able to use a newly formatted OST in place if an old one with the same index if the last_rcvd and mountdata files are not accessible. The last_rcvd file will be recreated at mount time with default parameters (should normally be ok), but mkfs.lustre will create the mountdata file with the LDD_F_VIRGIN flag always set. It should be possible to add a --replace option to mkfs.lustre so that the MGS doesn't refuse the OST to connect because the index is in use.
I've pushed http://review.whamcloud.com/7443 for "mkfs.lustre --replace", and the OST precreating only recent objects if the MDT lov_objid is much larger than the OST LAST_ID. This replaces the old patch in http://review.whamcloud.com/141.
So is there still further work to complete for this ticket or does the recent landing mean that this ticket can be closed?
We still need the patch for rebuilding LAST_ID file:
http://review.whamcloud.com/6997
backport to b2_4: http://review.whamcloud.com/8159
Patch landed on Lustre b2_4 branch.
backport to b2_4: http://review.whamcloud.com/8159
The new-added conf-sanity test 69 introduced regression failure on interop testing:
https://maloo.whamcloud.com/test_sets/4c4bf322-54af-11e3-9029-52540035b04c
The patch also introduced conf-sanity test 72 and 73 regression failures:
https://maloo.whamcloud.com/test_sets/4c4bf322-54af-11e3-9029-52540035b04c
https://maloo.whamcloud.com/test_sets/1ee70c90-4d17-11e3-9c23-52540035b04c
https://maloo.whamcloud.com/test_sets/acaa49a4-4c5c-11e3-826a-52540035b04c
https://maloo.whamcloud.com/test_sets/e3329b42-473a-11e3-89d8-52540035b04c
https://maloo.whamcloud.com/test_sets/61470bfa-45f4-11e3-810a-52540035b04c
Before Lustre b2_4 build #57 (which contains the patch), conf-sanity test 72 and 73 always passed on Lustre b2_4 branch.
The new-added conf-sanity test 69 also introduced regression failure on ZFS testing:
https://maloo.whamcloud.com/test_sets/57656c1e-5605-11e3-8e94-52540035b04c
Patches for adding Lustre version check codes into conf-sanity test 69:
master branch: http://review.whamcloud.com/8411
b2_5 branch: http://review.whamcloud.com/8413
b2_4 branch: http://review.whamcloud.com/8412
Patch http://review.whamcloud.com/6997 is implementing LAST_ID rebuild after corruption, and also handles the case where the MDT and OST are out of sync about the LAST_ID value.
Closing as remaining work is tracked under LU-1267