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@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
/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.
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'
<^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
Thank-you,
--Mark Tinguely.
_______________________________________________
xfs mailing list
xfs@xxxxxxxxxxx
http://oss.sgi.com/mailman/listinfo/xfs
