xfs
[Top] [All Lists]

Re: xfs_copy

To: Daniel Moore <dxm@xxxxxxxxxxxxxxxxxxxxxxxx>
Subject: Re: xfs_copy
From: Steve Lord <lord@xxxxxxx>
Date: Mon, 14 Aug 2000 08:40:19 -0500
Cc: linux-xfs@xxxxxxxxxxx
In-reply-to: Message from Daniel Moore <dxm@clouds.melbourne.sgi.com> of "Mon, 14 Aug 2000 13:21:11 +1000." <200008140321.NAA08204@clouds.melbourne.sgi.com>
Sender: owner-linux-xfs@xxxxxxxxxxx
> 
> ivanr@xxxxxxxxxxxxxxxxx writes:
> 
>  => (Under IRIX) xfs_copy will copy unmounted xfs filesystems, whereas
>  => xfsdump/xfsrestore use mounted filesystems.  The only real difference
>  => between xfs_copy and dd, is that xfs_copy will generate a new filesystem
>  => uuid for the copied filesystems.
> 
> xfs_copy also traverses the AGF & it seems only copies the blocks that
> are actually in use by the filesystem (neat but that means we'd have
> to SIM -> libxfs it as well as porting it to linux).
> 
> I think the best option is to remove xfs_copy from the tree. Does
> anyone have any objections to me nuking it?
> 
> The already mentioned alternatives are dd and xfs_dump/restore.
> If uuids are the issue (and xfs_db doesn't already do what is
> needed), it would be really easy to write a tool to manipulate
> them as needed.


dd does not really cut it unless your filesystem is full. How much of
libsim does xfs_copy really use? A quick scan of the source does not seem
to indicate that much. It reads the super block and sets up a mount
structure so it can do size calculations, apart from that I cannot see
much in there.

I would prefer to have xfs_copy survive if possible.

Steve




> 
> -----------------------------------------------------
>  Daniel Moore                  dxm@xxxxxxx
>  R&D Software Engineer         Phone: +61-3-98348209
>  SGI Performance Tools Group   Fax:   +61-3-98132378
> -----------------------------------------------------



<Prev in Thread] Current Thread [Next in Thread>