A difficult filesystem

Eric Wilhelm scratchcomputing at gmail.com
Wed Jun 20 23:14:50 BST 2007

# from Andy Armstrong
# on Wednesday 20 June 2007 05:30 am:

>Any of the normal hard-link-preserving copying methods run out of  
>memory pretty early - for obvious reasons.

I assume that includes rsync?

If you're transferring the whole partition, any chance of getting lvm to 
adopt the filesystem and migrate it across pv's?  (That's iffy, so try 
it on a disposable setup first.)

Maybe more feasible would be to create a mirror with mdadm and then just 
unplug the original once /proc/mdstat gives you the all-clear.

>So I copied the whole filesystem (dd if=x of=y) onto the new device 

Is that `dd if=/dev/sda1 of=/dev/sdb1`? (pointing at the device or 
partition?)  Can you use an lv as a dd target (thus allowing lvextend)?

>While I'm waiting does anyone have tips for other tools that might be
>   useful?

Assuming you're talking about a dirvish-like setup, it might be fastest 
to simply reconstruct the process that originally created the trees 
(but applying it to the repository->repository transfer rather than the 
typical nightly host->repository usage.)

I'm guessing $local_backup_nightly_job_time * $number_of_nightlies is 
less than two weeks.  You know a few rules about your data that 
rsync/cp/tar don't.  E.g. "links only within a tree/vault" and "links 
only to previous date".

That is, you have something like:


For each target, transfer the original/oldest (2005-01-01) tree to 
dest/target, then `cp -al` to the next date (2005-01-02) in dest/target 
and rsync from bank/target/ into dest/target/ per date.

You can also run one fork per target, which should scale per cpu if your 
disk hardware is bored and the fs implementation isn't bottlenecking.

If it works, send me your code :-D

As an old bass player friend of mine used to say: throw money, don't 
--Tony Parisi

More information about the london.pm mailing list