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
