xfs
[Top] [All Lists]

Re: Fwd: xfs_reno

To: Hans-Peter Jansen <hpj@xxxxxxxxx>
Subject: Re: Fwd: xfs_reno
From: Mark Tinguely <tinguely@xxxxxxx>
Date: Tue, 12 Mar 2013 08:48:46 -0500
Cc: david@xxxxxxxxxxxxx, xfs@xxxxxxxxxxx
Delivered-to: xfs@xxxxxxxxxxx
In-reply-to: <5202910.jIRzyplXT6@xrated>
References: <20351675.Zy117sIl8Z@xrated> <513E5113.60508@xxxxxxx> <5202910.jIRzyplXT6@xrated>
User-agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:9.0) Gecko/20120122 Thunderbird/9.0
On 03/12/13 04:02, Hans-Peter Jansen wrote:
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@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.

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

Sorry, the biggest problem is US daylight savings change and my simple brain. Waking this morning, it all mentally clicked. It is working as intended. Sorry for the noise.

--Mark.

--Mark.

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