[lustre-discuss] interrupted tar archive of an mdt ldiskfs

[Colin Faber]

Yes, the manual really needs to be updated on the lustre.org site to make
this more clear =)

On Mon, Jul 13, 2015 at 12:31 PM, John White <jwhite at lbl.gov> wrote:

> Wow, I don’t see anything indicating that in the manual…  That’s quite
> worrying.  So in the end, a block level migration is likely safer here?
>
> > On Jul 13, 2015, at 11:25 AM, Colin Faber <colin.faber at seagate.com>
> wrote:
> >
> > On, 2.x systems an object index database is utilized to track inode <->
> FID mapping. When you perform the traditional backup/restore this OI
> database becomes out of sync (because inodes numbers change).
> >
> > You'll need to restore the OI after your backup, on early 2.x systems
> the only way this was possible was with the migrator tool from Xyratex. On
> later revisions this functionality was baked into the lfsck tool.
> >
> > -cf
> >
> >
> > On Mon, Jul 13, 2015 at 12:20 PM, John White <jwhite at lbl.gov> wrote:
> > Yea, I’m benchmarking rsync right now, it doesn’t seem much faster than
> the initial tar was at all.
> >
> > Can you elaborate on the risk on 2.x systems?..
> >
> > > On Jul 13, 2015, at 11:17 AM, Colin Faber <colin.faber at seagate.com>
> wrote:
> > >
> > > modern rsync with ea support may work, but I'm not sure you're going
> to have much gains here as it's going to want to compare the inodes as
> well, so you're still stuck scanning all of them again.
> > >
> > > That said, it's worth a shot, and keep in mind this is risky on 2.x
> systems.
> > >
> > > -cf
> > >
> > >
> > > On Mon, Jul 13, 2015 at 11:23 AM, John White <jwhite at lbl.gov> wrote:
> > > So I was migrating an MDT from one array to another with a tar pipe
> using the flags recommended in the manual.  Got something like 92M out of
> 120M done when a coworker inadvertently rebooted the node that was doing
> the tar.  Is there any way to resume this action?  I know tar doesn’t have
> a resume function, but can a sufficiently modern rsync handle the EAs and
> such?  Luckily we still have the source in tact, but I’d *really* like to
> get this migration done during the downtime we have right now...
> > > _______________________________________________
> > > lustre-discuss mailing list
> > > lustre-discuss at lists.lustre.org
> > >
> https://urldefense.proofpoint.com/v2/url?u=http-3A__lists.lustre.org_listinfo.cgi_lustre-2Ddiscuss-2Dlustre.org&d=AwIGaQ&c=IGDlg0lD0b-nebmJJ0Kp8A&r=x9pM59OqndbWw-lPPdr8w1Vud29EZigcxcNkz0uw5oQ&m=iFETq-ylA9iKyTA9nV4wlhH1eOSW-L4OqpyPAdM4jh0&s=SbTO6au0x0xyZREjpFDaOaXKWcKRvTgQ2j_hSHFB4Dg&e=
> > >
> >
> >
>
> _______________________________________________
> lustre-discuss mailing list
> lustre-discuss at lists.lustre.org
> http://lists.lustre.org/listinfo.cgi/lustre-discuss-lustre.org
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.lustre.org/pipermail/lustre-discuss-lustre.org/attachments/20150713/1c5fb932/attachment.htm>