[LUDOC-186] Document OI Restoration

Duplicate — Thu, 16 Mar 2017 03:06:04 +0000

(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:
https://groups.google.com/a/whamcloud.com/forum/#!topic/wc-discuss/rD9fhIvAfF0

On 2011-09-12, at 7:06 PM, Jeremy Filizetti wrote:

> Andreas Dilger wrote:
>> I would expect that a "dd" backup would be much faster than this. Also, dd (or other block device copy) is the only valid way to do an MDT backup with Lustre 2.x.
>
> Why is "dd" the only valid way to backup a Lustre 2.x MDT?
The problem is with an internal table (called the Object Index, or OI) that is used to map the Lustre File Identifier (FID) onto an internal inode number.

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
–
Andreas Dilger
Principal Engineer
Whamcloud, Inc.

–
Brett Lee
Sr. Systems Engineer
Intel High Performance Data Division

Whamcloud Community JIRA

[LUDOC-186] Document OI Restoration