xfs errors while unlinking filenames with hash collisions

[Mark Tinguely]

On 03/27/14 10:24, Hannes Frederic Sowa wrote:
> On Thu, Mar 27, 2014 at 10:15:01AM -0500, Mark Tinguely wrote:
>> 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?
>
> Sure, I'll put it on my todo list for the weekend.
>
> Thanks,
>
>    Hannes


I will bisect where this started to happen. It appears to be around 
Linux 3.10.

--Mark.