Re: Fwd: xfs_reno

[Hans-Peter Jansen <hpj@urpla.net>]

Am Montag, 11. März 2013, 16:48:03 schrieb Mark Tinguely:
> On 03/06/13 08:55, Hans-Peter Jansen wrote:
> > Hi Dave,
> > 
> > I tried to gather Barrys SOB, but failed so far. His trace ends in 2009
> > google wise.
> > 
> > How is this case usually handled?
> > 
> > Here's the current state of things.
> > 
> > Cheers,
> > Pete
> > 
> > 
> > ----------  Weitergeleitete Nachricht  ----------
> > 
> > Betreff: xfs_reno
> > Datum: Mittwoch, 6. März 2013, 12:52:19
> > Von: Hans-Peter Jansen<hpj@urpla.net>
> > An: bnaujok@sgi.com
> > 
> > Hi Barry,
> > 
> > attached is a slightly mangled version of your xfs_reno tool, that I badly
> > needed recently. While at it, I plan to submit it, as it saved my *ss.
> > Thanks.
> > 
> > Apart from relocation to xfsprogs, I just changed this
> > 
> > +       log_message(LOG_DEBUG, "%s: %llu %lu %s", msg, node->ino,
> > +                       node->numpaths, node->paths[0]);
> > 
> > from %llu to %lu for the node->numpaths argument. It might still be wrong,
> > as numpath is defined as nlink_t which is a __u32 type, but the %s
> > printed garbage like this:
> > 
> > Scanning directory tree...
> > xfs_reno: add_node_path: ino 8611163235, path
> > /work/dlbase/hosts/11.2/pico/var/run/screens
> > xfs_reno: add_node_path: ino 8611163233, path
> > /work/dlbase/hosts/11.2/pico/var/run/pcscd/pcscd.events
> > xfs_reno: add_node_path: ino 8611163234, path
> > /work/dlbase/hosts/11.2/pico/var/run/uscreens
> > xfs_reno: nodehash: 8611163233 692488159933497345 ��]��f�e�
> > xfs_reno: nodehash: 8611163234 692366801337581569 ��]��f�e�
> > xfs_reno: nodehash: 8611163235 692223830466232321 ��]��f�e�
> > 
> > I guess, gcc is smart enough to see, that the struct members overlap here,
> > and prints the paths[0] argument as a %llu value. What do you think?
> > 
> > Anyway, I will revise this during the course of creating a xlstests test
> > for xfs_reno...
> > 
> > Do you allow me to add your Signed-off-by to this patch?
> > 
> > If you want to build this, apply both patches to xfsprogs.
> > 
> > TIA,
> > Pete
> 
> Have you been getting "Out of memory" warnings on your runs? I am.

No, I would have mentioned them. But I guess, my file systems are tiny 
compared to yours. The affected FS have 2.8T and 4.1T, with former with many 
small files and directories, the latter with many 2G files.
 
> Compiling, I get the warnings about having "\r" in the strings. For example:
> 
> reno/xfs_reno.c:1415: internationalized messages should not contain the
> `\r' escape sequence

Well, that's for the spin wheel, that might have interesting effects, when 
localized to right-to-left languages...

>                      ----------
> I wonder if we should add a temp directory option. It seems to want to
> use the parent directory of the directory as a temporary. 

Without digging into this, I can only guess, but the whole point of xfs_reno 
is relocating the inodes on the FS in question *without* copying files around. 
Using a separate TEMP defeats this purpose, don't it?

It might be in order to add a note to the man page to not try to use it in
"cross mount operation" scenarios.

> Below is the
> result of running xfs_reno on the target directory is "/mnt/xxx
> (changing the \r to <^M>\n for the email):
> 
> xfs_reno: directory: 128 1 /mn<^M>
> xfs_reno: /mnt/xfs_reno_epdaJc: Cannet set target extended attributes<^M>
> xfs_reno: failed to rename: '/mnt/xxx/origin' to
> '/mnt/xfs_reno_NXQLWI/origin'
> <^M>
> xfs_reno: unable to move directory contents: /mnt/xxx to
> /mnt/xfs_reno_NXQLWI
> <^M>
> xfs_reno: Cannot stat /mnt/xfs_reno_epdaJc: Inappropriate ioctl for device
> 
> <^M>
> xfs_reno: unable to duplicate directory attributes: /mnt/xfs_reno_epdaJc
> t/xxx
>                      ------
> /mnt is not an XFS filesystem. When mounting on the root, say /mnt, the
> message look like:
> 
> xfs_reno: Cannot stat //xfs_reno_epdaJc: Inappropriate ioctl for device

You lost me here. What I can say, is that using eg. "xfs_reno -vpn /work", 
hence on the mount point directly, did as advertised.

Cheers,
Pete

_______________________________________________
xfs mailing list
xfs@oss.sgi.com
http://oss.sgi.com/mailman/listinfo/xfs