Am Sat, 26 Mar 2016 22:57:53 -0600
schrieb Chris Murphy <lists@xxxxxxxxxxxxxxxxx>:
> On Sat, Mar 26, 2016 at 7:30 PM, Kai Krakow <hurikhan77@xxxxxxxxx>
> wrote:
>
> > Both filesystems on this PC show similar corruption now - but they
> > are connected to completely different buses (SATA3 bcache + 3x SATA2
> > backing store bache{0,1,2}, and USB3 without bcache = sde), use
> > different compression (compress=lzo vs. compress-force=zlib), but
> > similar redundancy scheme (draid=0,mraid=1 vs.
> > draid=single,mraid=dup). A hardware problem would induce completely
> > random errors on these pathes.
> >
> > Completely different hardware shows similar problems - but that
> > system is currently not available to me, and will stay there for a
> > while (it's a non-production installation at my workplace). Why
> > would similar errors show up here, if it'd be a hardware error of
> > the first system?
>
> Then there's something about the particular combination of mount
> options you're using with the workload that's inducing this, if it's
> reproducing on two different systems. What's the workload and what's
> the full history of the mount options? Looks like it started life as
> compress lzo and then later compress-force zlib and then after that
> the addition of space_cache=v2?
Still, that's two (or three) different filesystems:
The first (my main system) had compress=lzo forever, I never used
compress-force or something different than lzo.
The second (my main system backup) had compress-force=zlib forever,
never used a different compression option.
The third (the currently offline system) had compress=lzo like the
first one. It has no backup, system can be rebuild from scratch, no
important data there. I don't bother about that currently.
> Hopefully Qu has some advice on what's next. It might not be a bad
> idea to get a btrfs-image going.
I first upgraded to btrfs-progs 4.5 and removed the space_cache=v2
option (space tree has been removed, ro-incompat flag was reset
according to dmesg). I only activated that to see if it changes things,
and I made sure beforehand that this can be removed. Looks like that
works as documented.
I'll come back to the other thread as soon as I've run the check. It
takes a while (it contains a few weeks worth of snapshots). Meanwhile
I'll see if the main fs looks any different with btrfs-progs 4.5. I
need to get into dracut pre-mount for that.
At least, with space_cache=v2 removed, the delayed_refs problem there
is gone - so that code obviously has problems.
The main system didn't use space_cache=v2, tho, when the "object
already exists" problem hit me first.
I'll prepare for btrfs-image. How big is that going to be? I'd prefer
to make it as sparse as possible. I could hook it up to a 100mbit
upload but I need to get storage for that first.
--
Regards,
Kai
Replies to list-only preferred.
--
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
