xfs
[Top] [All Lists]

Re: xfs errors while unlinking filenames with hash collisions

To: Mark Tinguely <tinguely@xxxxxxx>
Subject: Re: xfs errors while unlinking filenames with hash collisions
From: Hannes Frederic Sowa <hannes@xxxxxxxxxxxxxxxxxxx>
Date: Thu, 27 Mar 2014 22:15:14 +0100
Cc: xfs@xxxxxxxxxxx
Delivered-to: xfs@xxxxxxxxxxx
In-reply-to: <533490C9.3010703@xxxxxxx>
References: <20140327074156.GJ29498@xxxxxxxxxxxxxxxxxxxxxxxxx> <5334241E.9060708@xxxxxxx> <20140327132354.GU29498@xxxxxxxxxxxxxxxxxxxxxxxxx> <533428D6.507@xxxxxxx> <20140327140556.GW29498@xxxxxxxxxxxxxxxxxxxxxxxxx> <53344075.8050607@xxxxxxx> <20140327152448.GE29498@xxxxxxxxxxxxxxxxxxxxxxxxx> <533490C9.3010703@xxxxxxx>
On Thu, Mar 27, 2014 at 03:57:45PM -0500, Mark Tinguely wrote:
> 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.
> >
> I will bisect to find the introduction. It appears be somewhere between 
> Linux 3.9 and 3.10.

Thanks!

Maybe it would be best to add a seed to the hashing function (and the super
block)?

<Prev in Thread] Current Thread [Next in Thread>