xfs
[Top] [All Lists]

Re: Fwd: xfs_reno

To: Mark Tinguely <tinguely@xxxxxxx>
Subject: Re: Fwd: xfs_reno
From: Hans-Peter Jansen <hpj@xxxxxxxxx>
Date: Tue, 12 Mar 2013 10:02:09 +0100
Cc: david@xxxxxxxxxxxxx, xfs@xxxxxxxxxxx
Delivered-to: xfs@xxxxxxxxxxx
In-reply-to: <513E5113.60508@xxxxxxx>
References: <20351675.Zy117sIl8Z@xrated> <513E5113.60508@xxxxxxx>
User-agent: KMail/4.10.1 (Linux/3.4.33-2.24-desktop; KDE/4.10.1; x86_64; ; )
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

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