[LUDOC-186] Document OI Restoration Created: 24/Sep/13 Updated: 16/Mar/17 Resolved: 16/Mar/17 |
|
| Status: | Closed |
| Project: | Lustre Documentation |
| Component/s: | None |
| Affects Version/s: | None |
| Fix Version/s: | None |
| Type: | Bug | Priority: | Minor |
| Reporter: | Linda Bebernes (Inactive) | Assignee: | nasf (Inactive) |
| Resolution: | Duplicate | Votes: | 0 |
| Labels: | None | ||
| Issue Links: |
|
||||||||||||||||
| Severity: | 3 | ||||||||||||||||
| Rank (Obsolete): | 10718 | ||||||||||||||||
| Description |
|
(Submitted for Brett Lee) Hi Andreas, Am trying to determine, based on the Roadmap and recent Release Notes, whether the MDT has the ability to reconstruct the OI's from the FID's after a backup/restore. It seems like it was to be part of the OpenSFS phase 1 LFSCK work, but am unable to determine if it has been completed (and thus Lustre users are free to backup the MDT using tools other than 'dd'). Are you able to confirm it is done, and if so, in which version? Many thanks! From your comments at: On 2011-09-12, at 7:06 PM, Jeremy Filizetti wrote: > Andreas Dilger wrote: If there is a file-level backup/restore of the MDT then the restored OI will map the FIDs to the wrong inode numbers, since file-level backups (tar, rsync, dump) do not preserve the inode numbers. Doing a device-level backup/restore preserves the inode numbers. This wasn't originally planned to be fixed for Lustre 2.0 and 2.1 because ZFS backup and restore always restore the inode (dnode) numbers, and there is no problem. For any users with Lustre 2.x the "dd" backup is usable in the meantime. As part of the OpenSFS contract for lfsck, the first phase is to implement OI rebuilding for the first phase. Cheers, Andreas – |
| Comments |
| Comment by nasf (Inactive) [ 16/Mar/17 ] |
|
Related document will be updated in |