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

John White jwhite at lbl.gov
Mon Jul 13 11:20:58 PDT 2015

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=

More information about the lustre-discuss mailing list