xfs errors while unlinking filenames with hash collisions

[Mark Tinguely]

On 03/27/14 09:05, Hannes Frederic Sowa wrote:
> On Thu, Mar 27, 2014 at 08:34:14AM -0500, Mark Tinguely wrote:
>> On 03/27/14 08:23, Hannes Frederic Sowa wrote:
>>> On Thu, Mar 27, 2014 at 08:14:06AM -0500, Mark Tinguely wrote:
>>>> Have you tried to run a xfs_repair on the filesystem after the reboot?
>>>
>>> Yes, I did. I still use the filesystem and it works. As soon as I try to
>>> remove the directory again the same splash from above happens again.
>>
>> Is it the latest xfsprogs' repair?
>>
>> Do you have the output from the repair still?
>
> I can easily test this here, so you can throw any commands and tests at
> me. ;)
>
> This is the output:
>
> (I replayed the journal before that)
>
> pre-mount:/# xfs_repair -V
> xfs_repair version 3.1.11
> pre-mount:/# xfs_repair -v /dev/vda1
> Phase 1 - find and verify superblock...
>          - block cache size set to 372848 entries
> Phase 2 - using internal log
>          - zero log...
> zero_log: head block 5071 tail block 5071
>          - scan filesystem freespace and inode maps...
>          - found root inode chunk
> Phase 3 - for each AG...
>          - scan and clear agi unlinked lists...
>          - process known inodes and perform inode discovery...
>          - agno = 0
> bad hash ordering in block 8388739 of directory inode 3543184

interesting. I will see if I can recreate it.

Are you open to making it an xfstest?

--Mark.