For me anyway, I hope the fedora team don't take too long to make it available. Thanks for all your help today. On 22/04/2013 15:41, "Harald Glatt" <mail@xxxxxxxxx> wrote: >I heard it's coming out next week. > >On Mon, Apr 22, 2013 at 4:40 PM, Mark Ridley <mark@xxxxxxxxxxxxxxxxxxx> >wrote: >> 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
