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

[Linda A. Walsh]

Dave Chinner wrote:
> On Tue, Jun 29, 2010 at 05:01:12PM -0700, Linda A. Walsh wrote:
>>
>> Dave Chinner wrote:
>> ---------------------------------------------------------------------------------------------------
>>>> 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?
>> -----
>> Those files were 'fine' before today.
>>
>> I know it is not a terminal problem --
>> I told ls to list all files in the directory -- then it says "no such file".
>>
>> Can you say that "*" shouldn't match everything?
>>
>> Those question marks are in the place for the size!
>>
>> There are no weird characters in those file names.
> 
> I beg to differ ;)
----
	They are standard UTF-8 characters!  What's weird about
them?!?   Next you'll be complaining about my hair style... ;).


> 
>> Here are the same files in another directory:
>> mp3> ll 3*
>> -rwx------ 1 3255702 2010-06-14 10:54 30-Omoide to Yakusoku (TV saizu｜Reinaʼs Ver.).mp3*
>> -rwx------ 1 3272004 2010-06-14 10:54 31-Omoide to Yakusoku (TV saizu｜Tomoeʼs Ver.).mp3*
>> -rwx------ 1 3234876 2010-06-14 10:54 32-Omoide to Yakusoku (TV saizu｜Nanualʼs Ver.).mp3*
>                                                                        ^^^
> That character is a non-ascii character, which is why I was
> wondering about terminals and character sets.  It does not display
> correctly in mutt (a bold vertical bar) or Vim (a dotted, double
> character width square) using LANG=en_AU.UTF-8 here....
----
you don't have the right font for your Vim. :-)   

  I use vim here and it displays
in the TTY version, the X version and even the windows version!

Anyway -- as you can see above, the files display fine in another directory with the
same character.  IT's not the vertical bar char.  I use UTF-8 characters all over
the place -- I created that file manually.  Go get 'Bablemap'.  It's free (well donation
requested) from http://www.babelstone.co.uk/Software/BabelMap.html.  My systems handle
them 'fine'.  That's not the problem here.  
I have 3 directories that all have copies of files 30-32 in them that are corrupt.

I have another directory "Shakugan no Shana II OST", that I can't cd into or ls.
Just says 'not found'.

This all happened today.  They were accessible before today.  I'm not sure what changed,
other than new files were added.



> 
>> How can file size, time and date be in unprintable characters that "ls" can't display?
> 
> They aren't. They are printed as ??? because the stat failed and
> hence they are unknown.
----
	Ok, why would the stat fail?  

	There's nothing magical about a 2TB limit?  (sigh...)

	Ideas?

Linda