[Top] [All Lists]

Re: Fwd: xfs_reno

To: Hans-Peter Jansen <hpj@xxxxxxxxx>
Subject: Re: Fwd: xfs_reno
From: Mark Tinguely <tinguely@xxxxxxx>
Date: Mon, 11 Mar 2013 16:48:03 -0500
Cc: david@xxxxxxxxxxxxx, xfs@xxxxxxxxxxx
Delivered-to: xfs@xxxxxxxxxxx
In-reply-to: <20351675.Zy117sIl8Z@xrated>
References: <20351675.Zy117sIl8Z@xrated>
User-agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:9.0) Gecko/20120122 Thunderbird/9.0
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

How is this case usually handled?

Here's the current state of things.


----------  Weitergeleitete Nachricht  ----------

Betreff: xfs_reno
Datum: Mittwoch, 6. MÃrz 2013, 12:52:19
Von: Hans-Peter Jansen<hpj@xxxxxxxxx>
An: bnaujok@xxxxxxx

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
xfs_reno: add_node_path: ino 8611163233, path
xfs_reno: add_node_path: ino 8611163234, path
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

Do you allow me to add your Signed-off-by to this patch?

If you want to build this, apply both patches to xfsprogs.


Have you been getting "Out of memory" warnings on your runs? I am.

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
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. 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'
xfs_reno: unable to move directory contents: /mnt/xxx to /mnt/xfs_reno_NXQLWI
xfs_reno: Cannot stat /mnt/xfs_reno_epdaJc: Inappropriate ioctl for device

xfs_reno: unable to duplicate directory attributes: /mnt/xfs_reno_epdaJc
/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


--Mark Tinguely.

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