RE: xfs_ncheck (actually xfs_db) eats a lot of memory and is killed

Barry Naujok
2006-12-20T01:00:48Z

> -----Original Message-----
> From: xfs-bounce@oss.sgi.com [mailto:xfs-bounce@oss.sgi.com]
> On Behalf Of Marcin Zajaczkowski
> Sent: Tuesday, 19 December 2006 6:39 PM
> To: linux-xfs@oss.sgi.com
> Subject: Re: xfs_ncheck (actually xfs_db) eats a lot of
> memory and is killed
>
> Marcin Zajączkowski wrote:
> > Barry Naujok wrote:
> >>> Subject: xfs_ncheck (actually xfs_db) eats a lot of
> memory and is killed
> > (...)
> >>> Recently I've got rescue CD with xfs_progs in version 2.8.11 and
> >>> tried to repair it. xfs_repair gave me about 150 files with names
> >>> like inode numbers in /lost+found and 1500 "normal" named
> files in
> >>> its subdirectory.
> >>> I've tried to use "xfs_ncheck -i inode /dev/hdX" to got names
> >>> corresponding with specified inode(s), but program had
> been runing
> >>> several minutes, xfs_db had eaten all available memory
> (768MB) and
> >>> was killed by system (whole system hung too). The second time I
> >>> killed it (kill -15) when it ate whole available memory.
> >>> My file system has about 6GB and is filled with 95%.
> >>
> >> This is the second report of a smallish filesystem using all of the
> >> system's memory (the other being xfs_repair). Hopefully
> when I diagnose
> >> the problem with the previous report, I can fix the same issue with
> >> xfs_db and your filesystem.
> >>
> >> If it at all possible, can you xfs_copy the offending
> filesystem to a
> >> file and compress it and make it available to me to find/fix the
> >> problem.
> >
> > Hmm, it won't be so easy. Compressed dump of a fielsystem
> before repair
> > (I had to use dd, because xfsdump refused to cooperate) has 2,5GB.
> > Damaged files were (probably) only in one directory
> /usr/bin. Maybe I
> > could reduce size of the image excluding few other directories (in
> > xfsdump)?
> > Do you think that error would still occur?
>
> What do you think about that?

xfs_dump won't recreate the filesystem that causes xfs_db to gobble up
memory unfortunately, xfs_copy copies the filesystem as it is, block for
block.

> Btw, is it possible to mount XFS filesystem from the file created by
> xfs_copy?
> If not, is it possible to restore file system "backuped" to file (by
> xfs_copy)? I read in the manual that the first parameter
> xfs_copy has to
> be device (not file). xfs_restore will work with that "dump"?

Yes, you can mount an XFS filesystem file using the "-o loop" mount
option and specifying the file for the device.

Yes, you can xfs_copy from a file back to a device. From the man page:
"The first (source) argument must be the pathname of the device or file
containing the XFS filesystem.".

xfs_dump/xfs_restore is more like tar copying all metadata, but not disk
layout.

> >>> Am I doing something wrong with xfs_db?
> >>> Is there any easier way to restore my files?
> >>
> >> Your files have been restored as much as possible. You'll
> have to work
> >> out what is in lost+found and move them back to their appropriate
> >> locations.
> >
> > With files with "normal" names there is no problem. There
> are all from
> > one directory (/usr/bin), but I'm unable (without
> xfs_ncheck) to map
> > files with inode-like names with their normal names (150+ files). I
> > tried with xfs_db and the way described in your FAQ, but I had some
> > problems too.
>
> Currently I have to use LiveCD (/usr/bin is a quite important
> directory
> ;) ). Do you suggest to try to repair it manually (copy files with
> names, try to boot and try to use RPM to repair broken packages
> (restore missing files) or there could be an easiest way (at the xfs
> layer to match numbers with proper names)?

If the /usr/bin directory was trashed, I think you can only restore from
the original packages, I don't think you'll have much luck doing it
manually. (xfs_repair 2.8.10 onwards will restore the same files that
the manual approach can retrieve.)