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);
> > 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 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
> xfs_reno: unable to move directory contents: /mnt/xxx to
> 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
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.