[Lustre-discuss] Migrating MDT volume to a new location
Bob Ball
ball at umich.edu
Thu Feb 3 17:32:22 PST 2011
Luster User Guide section 15.2
"If hardware replacement is the reason for the backup or if a spare
storage device is
available, it is possible to do a raw copy of the MDS or OST from one
block device to
the other, as long as the new device is at least as large as the
original device. To do
this, run:
dd if=/dev/{original} of=/dev/{new} bs=1M"
so, the new volume was slightly bigger than the old.
bob
On 2/3/2011 6:10 PM, Thomas Roth wrote:
> So your new MDT volume had the same size as the old one? You didn't have to resize?
>
> Would be interesting to know if someone has experience with resize2fs applied to a MDT ...
>
> Cheers,
> Thomas
>
> On 02/03/2011 06:35 PM, Bob Ball wrote:
>> We used dd. It took about 12 hours. After the dd, we did an e2fsck on
>> the new volume, remounted it as the MDT, and Lustre happily began
>> serving files again.
>>
>> Thanks to everyone for their help.
>>
>> bob
>>
>> On 2/3/2011 12:21 PM, Frederik Ferner wrote:
>>> Bob Ball wrote:
>>>> Is there a recommended way to migrate an MDT (MGS is separate) volume
>>>> from one location to another on the same server? This uses iSCSI volumes.
>>>>
>>>> Lustre 1.8.4
>>> We have recently migrated our MDT to an new volume to change the inode
>>> size. We used tar and getfattr/setfattr for this closely following the
>>> MDT backup and restore procedure from the manual. We did take our file
>>> system down completely for over a week over Christmas to do this, though
>>> it could have possibly been quicker if we had not taken time off as
>>> well. We also did very careful checking of everything before bringing up
>>> the new MDT. This was on a file system with at that time about 90M files.
>>>
>>> Be sure to use a tar version that has an efficient way to detect files
>>> that are completely sparse. We found that the version on RHEL5 did not
>>> have this and taking backups took very long, I think there is a thread
>>> on the list about this which has a link to a fixed tar version for RHEL5
>>> which we used in the end. Also, we did not use any --posix or --xattr
>>> option for tar as we found that this is broken and creates bogus files.
>>> We used plain 'tar --sparse'.
>>>
>>> If you don't have to change any mkfs options (like inode size in our
>>> case), I suspect any block based copy mechanism like dd or pvmove is the
>>> better option, possibly followed by a resize.
>>>
>>> Good luck,
>>> Frederik
>>>
>> _______________________________________________
>> Lustre-discuss mailing list
>> Lustre-discuss at lists.lustre.org
>> http://lists.lustre.org/mailman/listinfo/lustre-discuss
More information about the lustre-discuss
mailing list