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" <[email protected]> wrote: >On Mon, Apr 22, 2013 at 4:01 PM, Mark Ridley <[email protected]> >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" <[email protected]> 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 [email protected] >> 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 [email protected] More majordomo info at http://vger.kernel.org/majordomo-info.html
