xfs_ncheck gives outdated and partial result

xfs_ncheck gives outdated and partial result

[Daniele P.]

Hi All,
I'm here to ask a couple of question regarding xfs_ncheck.
I'm using xfs_db version 2.6.20

The first question is:
Is it right that I have to unmount/mount the filesystem before
using it (1), or to get the partial right (3) answer?
And why it's print only the first file name for inodes pointed
by multiple files (2)?


(1)
# mkfs.xfs /dev/hda5
meta-data=/dev/hda5              isize=256    agcount=16, agsize=152617 blks
         =                       sectsz=512
data     =                       bsize=4096   blocks=2441872, imaxpct=25
         =                       sunit=0      swidth=0 blks, unwritten=1
naming   =version 2              bsize=4096
log      =internal log           bsize=4096   blocks=2560, version=1
         =                       sectsz=512   sunit=0 blks
realtime =none                   extsz=65536  blocks=0, rtextents=0
# mount /dev/hda5 /mnt/hda5/
# touch /mnt/hda5/a
# xfs_ncheck -i 131 /dev/hda5
ERROR: The filesystem has valuable metadata changes in a log which needs to
be replayed.  Mount the filesystem to replay the log, and unmount it before
re-running xfs_ncheck.  If you are unable to mount the filesystem, then use
the xfs_repair -L option to destroy the log and attempt a repair.
Note that destroying the log may cause corruption -- please attempt a mount
of the filesystem before doing this.
must run blockget -n first

(2)
# ln /mnt/hda5/a /mnt/hda5/b
# ls -i /mnt/hda5/
131 a  131 b
# umount /mnt/hda5
# mount /dev/hda5 /mnt/hda5
# xfs_ncheck -i 131 /dev/hda5
        131 a

(3)                                           
# ln /mnt/hda5/a /mnt/hda5/c
# xfs_ncheck -i 131 /dev/hda5
        131 a
# rm /mnt/hda5/a
# xfs_ncheck -i 131 /dev/hda5
        131 a
# umount /mnt/hda5
# mount /dev/hda5 /mnt/hda5
# xfs_ncheck -i 131 /dev/hda5
        131 b

Thanks in advance,
Daniele P.

Re: xfs_ncheck gives outdated and partial result

[Lachlan McIlroy]

Hi Daniele,

Daniele P. wrote:
> Hi All,
> I'm here to ask a couple of question regarding xfs_ncheck.
> I'm using xfs_db version 2.6.20
> 
> The first question is:
> Is it right that I have to unmount/mount the filesystem before
> using it (1), or to get the partial right (3) answer?
> And why it's print only the first file name for inodes pointed
> by multiple files (2)?
> 
> 
> (1)
> # mkfs.xfs /dev/hda5
> meta-data=/dev/hda5              isize=256    agcount=16, agsize=152617 blks
>          =                       sectsz=512
> data     =                       bsize=4096   blocks=2441872, imaxpct=25
>          =                       sunit=0      swidth=0 blks, unwritten=1
> naming   =version 2              bsize=4096
> log      =internal log           bsize=4096   blocks=2560, version=1
>          =                       sectsz=512   sunit=0 blks
> realtime =none                   extsz=65536  blocks=0, rtextents=0
> # mount /dev/hda5 /mnt/hda5/
> # touch /mnt/hda5/a
> # xfs_ncheck -i 131 /dev/hda5
> ERROR: The filesystem has valuable metadata changes in a log which needs to
> be replayed.  Mount the filesystem to replay the log, and unmount it before
> re-running xfs_ncheck.  If you are unable to mount the filesystem, then use
> the xfs_repair -L option to destroy the log and attempt a repair.
> Note that destroying the log may cause corruption -- please attempt a mount
> of the filesystem before doing this.
> must run blockget -n first
While it is possible to run xfs_ncheck on a mounted filesystem the results
may be inaccurate and misleading.  I believe xfs_ncheck accesses the filesystem
directly without interpreting the log so if there are outstanding changes in
the log then the filesystem may appear inconsistent.  Unmounting the filesystem
ensures that no changes will occur while xfs_ncheck is running and is the only
way to be sure that it will provide an accurate report.  If the filesystem is
unmounted but there are still outstanding entries in the log then mount and
unmount the filesystem again to replay the log.

> 
> (2)
> # ln /mnt/hda5/a /mnt/hda5/b
> # ls -i /mnt/hda5/
> 131 a  131 b
> # umount /mnt/hda5
> # mount /dev/hda5 /mnt/hda5
> # xfs_ncheck -i 131 /dev/hda5
>         131 a
This could just be a convenience feature to provide the first known path to
the inode.  Does anyone have a better answer?

> 
> (3)                                           
> # ln /mnt/hda5/a /mnt/hda5/c
> # xfs_ncheck -i 131 /dev/hda5
>         131 a
> # rm /mnt/hda5/a
> # xfs_ncheck -i 131 /dev/hda5
>         131 a
The log entry for the delete has not been replayed into the filesystem yet
so xfs_ncheck still sees stale data.

> # umount /mnt/hda5
> # mount /dev/hda5 /mnt/hda5
> # xfs_ncheck -i 131 /dev/hda5
>         131 b
Remounting the filesystem forces the log to be replayed into the filesystem
and now xfs_ncheck has a consistent view.

> 
> Thanks in advance,
> Daniele P.
> 
> 

Re: xfs_ncheck gives outdated and partial result

[Eric Sandeen]

Daniele P. wrote:
> Hi All,
> I'm here to ask a couple of question regarding xfs_ncheck.
> I'm using xfs_db version 2.6.20
> 
> The first question is:
> Is it right that I have to unmount/mount the filesystem before
> using it (1), or to get the partial right (3) answer?
> And why it's print only the first file name for inodes pointed
> by multiple files (2)?

I think Lachlan had good answers to your questions... I'm curious, are
you using xfs_ncheck on a mounted filesystem for any particular reason?
 It seems that maybe if you are concerned about the out-of-date info on
a mounted filesystem, maybe you are attempting to use this from a script
or something as part of a larger tool, and that may not be a good idea
in general.  xfs_ncheck, a wrapper around xfs_db, reads the block device
directly, and nothing in the kernel guarantees consistency between the
block device address space and the filesystem address space.

-Eric

Re: xfs_ncheck gives outdated and partial result

[Timothy Shimmin]

--On 20 October 2006 8:58:08 AM +0200 "Daniele P." <daniele@interline.it> wrote:

> Hi All,
> I'm here to ask a couple of question regarding xfs_ncheck.
> I'm using xfs_db version 2.6.20
>
...
> And why it's print only the first file name for inodes pointed
> by multiple files (2)?
>

I presume you are referring to hardlinks - with multiple directory
entries pointing to the same inode.
Looking at db/check.c/addname_inode() it looks like it only stores
the first name that it comes across during directory processing when
scanning happens in the blockget command.


addname_inode(
        inodata_t       *id,
        char            *name,
        int             namelen)
{
        if (!nflag || id->name)  <---- if name exists, then return
                return;
        id->name = xmalloc(namelen + 1);
        memcpy(id->name, name, namelen);
        id->name[namelen] = '\0';
}

So we just get one valid path.

--Tim