Am Sat, 26 Mar 2016 22:57:53 -0600 schrieb Chris Murphy <[email protected]>:
> On Sat, Mar 26, 2016 at 7:30 PM, Kai Krakow <[email protected]> > 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 [email protected] More majordomo info at http://vger.kernel.org/majordomo-info.html
