On 8/12/14, 9:51 AM, Brian Foster wrote:
> On Tue, Aug 12, 2014 at 02:17:00AM +0200, Carlos E. R. wrote:
> Content-ID: <alpine.LSU.2.11.1408120142170.21410@minas-tirith.valinor>
>
>
> El 2014-08-12 a las 00:36 +0200, Carlos E. R. escribió:
>>>> El 2014-08-11 a las 16:56 -0500, Mark Tinguely escribió:
>
>>>> but all of them are about 401M before compression. The upload will take
>>>> long, my ADSL upload is 0.3M/s at most.
>
>
> I have shared (view) on google drive a folder with the three files. Both
> Brian Foster and Mark Tinguely should have got a link on the mail from me.
> If somebody else wants access, just tell me.
>
>
>> I see the same thing from repair that was in your repair output:
>
>> block (1,12608397-12608397) multiply claimed by cnt space tree, state - 2
>
>> If I take a look at the btrees as is, I see "235:[12608397,10]" included
>> in the bnobt (fsb 0x200aa55) and "270:[12608397,10]" in the cntbt (fsb
>> 0x2000781). If I skip the mount, zero the log and repair, everything
>> seems Ok. I can allocate the remainder of available space and rm -rf
>> everything in the fs without an error.
>
>> Once I replay the log, I see "272:[12608397,10] 273:[12608397,10]" in
>> the cntbt, which is clearly a duplicate entry. This is what repair
>> detects and cleans up and seems to lead to the shutdown. E.g., if I
>> mount and use the fs, I can hit an assert or failure just by attempting
>> to allocate the rest of the space in the fs. If that is the state of the
>> fs on disk, it's only a matter of time we explode due to allocating and
>> freeing that range of space or possibly attempting to allocate that
>> space twice.
>
>> Mark mentioned that he didn't see the superblock item in the log with
>> regard to the freeze. I don't see that either... which perhaps suggests
>> that this all happens during the wake-from-hibernate sequence..? My
>> understanding is that we should freeze on hibernate, thus force
>> everything out to the log, write an unmount record and then dirty the
>> log with a superblock transaction. Therefore, that should be the only
>> item in the log post-freeze. Here, we have various items in the log
>> including several logged buffers that correspond to the cntbt block that
>> ends up corrupted (daddr 0xf427c08).
What freeze? look at hibernate(), nothing but a sync:
/**
* hibernate - Carry out system hibernation, including saving the image.
*/
int hibernate(void)
{
...
printk(KERN_INFO "PM: Syncing filesystems ... ");
sys_sync();
printk("done.\n");
error = freeze_processes();
if (error)
goto Exit;
AFAIK there is no freeze call involved.
-Eric
_______________________________________________
xfs mailing list
xfs@xxxxxxxxxxx
http://oss.sgi.com/mailman/listinfo/xfs
