Re: BTRFS 3.8.7 Kernel Crash Report

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



Only data errors (from CRC checks), maybe also some structure errors -
I'm not sure. A remount should fix all errors. If it doesn't I think
it's considered a bug - ultimately the goal is that no --repair should
ever be required... Scrub is generally safe though, unlike btrfsck
--repair.

On Mon, Apr 22, 2013 at 4:16 PM, Mark Ridley <mark@xxxxxxxxxxxxxxxxxxx> wrote:
> What does btrfs scrub do?
>
> Is that meant to detect and fix problems?
>
> Thanks,
>
> Mark
>
> On 22/04/2013 15:13, "Harald Glatt" <mail@xxxxxxxxx> wrote:
>
>>Yeah, --repair is not recommended as of now. Maybe posting the btrfsck
>>output just from checking would be helpful in this case.
>>
>>On Mon, Apr 22, 2013 at 4:04 PM, Mark Ridley <mark@xxxxxxxxxxxxxxxxxxx>
>>wrote:
>>> No.
>>>
>>> Without --repair pointed out some problems, but whats the point of
>>>knowing
>>> about the problems if they can't be fixed so I ran with --repair and it
>>> broke the volume.
>>>
>>> On 22/04/2013 15:02, "Harald Glatt" <mail@xxxxxxxxx> wrote:
>>>
>>>>On Mon, Apr 22, 2013 at 4:01 PM, Mark Ridley <mark@xxxxxxxxxxxxxxxxxxx>
>>>>wrote:
>>>>> Thanks, David.
>>>>>
>>>>> What causes this corruption and how can I fix it?
>>>>>
>>>>> I'm very worried about running btrfs.fsck as last time it made a
>>>>>slight
>>>>> corruption like this worse and the whole volume had to be trashed.
>>>>>
>>>>> After fsck the "available space" on df ended up being negative so
>>>>>nothing
>>>>> could be written to the volume.
>>>>>
>>>>> Mark
>>>>>
>>>>> On 22/04/2013 14:42, "David Sterba" <dsterba@xxxxxxx> wrote:
>>>>>
>>>>>>On Mon, Apr 22, 2013 at 01:19:41PM +0000, Mark Ridley wrote:
>>>>>>> If I then use rsync --inplace to update the images, I get a btrfs
>>>>>>>stack
>>>>>>>trace
>>>>>>> and btrfs hangs:
>>>>>>>
>>>>>>> This happens every night.
>>>>>>
>>>>>>> [<ffffffffa00bd5c1>] btrfs_set_item_key_safe+0x141/0x150 [btrfs]
>>>>>>
>>>>>>The check fails because it finds keys in reverted order. Given the
>>>>>>conditions under which it happens I think it's an on-disk corruption
>>>>>>and
>>>>>>fsck should be able to at least detect it.
>>>>>>
>>>>>>david
>>>>>
>>>>> --
>>>>> To unsubscribe from this list: send the line "unsubscribe linux-btrfs"
>>>>>in
>>>>> the body of a message to majordomo@xxxxxxxxxxxxxxx
>>>>> More majordomo info at  http://vger.kernel.org/majordomo-info.html
>>>>
>>>>This happened without --repair?
>>>
>
--
To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html




[Index of Archives]     [Linux Filesystem Development]     [Linux NFS]     [Linux NILFS]     [Linux USB Devel]     [Linux Audio Users]     [Yosemite News]     [Linux Kernel]     [Linux SCSI]

  Powered by Linux