I think it won't... That would just be the goal eventually. If scrub sees no errors all the data should be in tact and your best bet to get things working perfectly again is to create a new filesystem and transfer the data into it. I'm not a dev and I can't say if a btrfs-image for debugging purposes would be helpful in this case or not, maybe this kind of corrution has been fixed a long time ago and wouldn't happen again in up-to-date versions of btrfs anyway. On Mon, Apr 22, 2013 at 4:24 PM, Mark Ridley <mark@xxxxxxxxxxxxxxxxxxx> wrote: > Thanks for getting back to me. > > Do you think remount fixes the keys reverted problem? > > On 22/04/2013 15:18, "Harald Glatt" <mail@xxxxxxxxx> wrote: > >>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
