Re: xfs file system in process of becoming corrupt; though xfs_repair thinks it's fine! ;-/ (was xfs_dump problem...)

From: Dave Chinner <david@fromorbit.com>
To: Linda Walsh <xfs@tlinx.org>
Cc: xfs-oss <xfs@oss.sgi.com>
Subject: Re: xfs file system in process of becoming corrupt; though xfs_repair thinks it's fine! ;-/ (was xfs_dump problem...)
Date: Wed, 30 Jun 2010 09:25:32 +1000	[thread overview]
Message-ID: <20100629232532.GA24712@dastard> (raw)
In-Reply-To: <4C2A749E.4060006@tlinx.org>

On Tue, Jun 29, 2010 at 03:33:02PM -0700, Linda Walsh wrote:
> Dave Chinner wrote:
> >Can you get a list of all the attributes and their sizes on the
> >inodes xfsdump is complaining about?
> >
> >Cheers,
> >
> >Dave.
> Wish I could...had a software problem that had me have to reuse the
> drive I just copied those examples from.
> 
> But have another XFS problem that is much more reliably persistent.
> I don't know if they are at all related, but since I have this problem
> that's a bit "stuck", it's easier to "reproduce".
> 
> Filesystem is one of my larger ones:
> 
> Ishtar:/Torrents> 'df' -T --sync  .
> Filesystem    Type   1K-blocks      Used Available Use% Mounted on
> /dev/dm-7      xfs   6442319744 2305631080 4136688664  36% /Torrents
> Ishtar:/Torrents> 'df' -iT --sync  .
> Filesystem    Type    Inodes   IUsed   IFree IUse% Mounted on
> /dev/dm-7      xfs   1288490112   34313 1288455799    1% /Torrents
> 
> I have 3 files that developed 'bugs' in them in 3 separate
> directories.  Oddly, they were they were 3 copies of the same 3
> files.  Very Odd.
> 
> Symptom is from ls:
> ---------------------------------------------------------------------------------------------------
> Ishtar:/Torrents> 'ls' -ni bad*     ls: cannot access bad/30-Omoide
> to Yakusoku (TV saizu｜Reinaʼs Ver.).mp3: No such file or directory
> ls: cannot access bad/31-Omoide to Yakusoku (TV saizu｜Tomoeʼs Ver.).mp3: No such file or directory
> ls: cannot access bad/32-Omoide to Yakusoku (TV saizu｜Nanualʼs Ver.).mp3: No such file or directory
> bad:
> total 0
> 2359101 ?????????? ? ? ? ?                ? 30-Omoide to Yakusoku (TV saizu｜Reinaʼs Ver.).mp3
> 2354946 ?????????? ? ? ? ?                ? 31-Omoide to Yakusoku (TV saizu｜Tomoeʼs Ver.).mp3
> 2354949 ?????????? ? ? ? ?                ? 32-Omoide to Yakusoku (TV saizu｜Nanualʼs Ver.).mp3
> ls: cannot access bad2/30-Omoide to Yakusoku (TV saizu｜Reinaʼs Ver.).mp3: No such file or directory
> ls: cannot access bad2/31-Omoide to Yakusoku (TV saizu｜Tomoeʼs Ver.).mp3: No such file or directory
> ls: cannot access bad2/32-Omoide to Yakusoku (TV saizu｜Nanualʼs Ver.).mp3: No such file or directory

Those file names have a weird character in them - are you sure that
the terminal supports that character set and is not mangling it and
hence not matching what is actually stored on disk?

> The file system, labeled 'Torrents' is layered on a lvm base (I'm not convinced that
> lvm is as reliable as physical partitions at this point, which is why I mention it).
> 
> It's a 'live' file system.  What info do you want me to dump from it?
> 
> I'm dumping the files from it now, so I can try to remake the file system.
> 
> The problem is 'spreading' to "new" files.  Basically, any file that is being written to
> now, seems to be in danger of becoming inaccessible.

Do those "new" files have the same strange characters in them?

> Also, FWIW -- I did unmount the file system and run xfs_repair.  It
> finds no problems -- so why are these files not accessible?

If there are no problems reported by repair, then I suspect that
it's a terminal level problem...

Cheers,

Dave.
-- 
Dave Chinner
david@fromorbit.com

_______________________________________________
xfs mailing list
xfs@oss.sgi.com
http://oss.sgi.com/mailman/listinfo/xfs