Any idea when the 3.9 kernel will be out. I see there are lots of btrfs fixes going into it. I'm currently running FC18 on 3.8.7, although 10 minutes ago it got updated to 3.8.8. On 22/04/2013 15:28, "Harald Glatt" <mail@xxxxxxxxx> wrote: >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
