You are not logged in.
Pages: 1
I was running bedup on my pictures sub volume today for the first time. I'm planning on beduping my entire raid1 volume before sending to an external backup. I glance through the list and see that there are five screenshots which are duplicates of one another, ranging in date from Nov 2013 to Jan 2016. I found this somewhat alarming and went to investigate by looking at the screenshots. First off, they are each about 11kB png files created with Gnome via the PrtSc key on my keyboard, and they are all, solid black at my monitor's resolution 1920x1200. That does give me a bit of comfort. If it was corruption, I'd have expected it to be something else. Then I look at what other screenshots were taken around that time.
The next three paragraphs are probably pointless, but I want to be thorough.
Two from 2015 seem to have been taken while I was playing one of the Hyperdimensional Neptunia games since to either side of them are a collection of screens from that. I like to take pictures of the dialog since I find them very funny. What isn't funny is perfectly good screen shots with a blank in the middle. So, okay, sometimes games have blank screens and I, for some reason, took a picture of it.
The one from 2014 was between a shot of my terminal (pacman printed an "important notice" that I wanted to be able to refer back to if need be) and a webpage. Not especially helpful, but it's less like to be a game.
The one from 2013 was between screenshots of two error messages a couple days apart. The 2016 one is also just kind of there.
That wasn't especially enlightening. Luckily my back up scripts (daily, weekly, and monthly) dump a verbose list all changes rsync makes. I use grep raid1* -e "screenshot's date (ie 2016-01-03)" to search my logs. The only thing I see are the creation dates. No changes seems to have occurred. Note that while my daily rsync back up is a simple time stamp and size check, the weekly and monthly are a full checksum, so if the file was changed sometime after the backup was created, it should have caught it.
I go and check my off-line backup (vs the one that is merely a large internal one I leave unmounted when not backing up). This looks like it was last updated sometime in May 2016. It to shows the same files, so it isn't a result of the dedup process (which was done on a snapshot and not the original by the way).
To me, it looks like a peculiarity in the screenshotting as opposed to a file system error, however I wanted to check with you guys. I know there are some bugs in btrfs that can cause corruption, but I didn't think any of them were silent.
So my question is in four parts: Do you guys agree that this is not a result of corruption, could this be corruption on creation that was never caught by scrub, what do you think it may be, and are there silent corruption bugs in btrfs still?
When I searched "btrfs silent corruption" in Google, I got https://www.spinics.net/lists/linux-btrfs/msg59190.html . However, it looks like this sort of error, while silent at the time, can be caught by a scrub.
edit: Also, how would I go about looking for errors such as the type I'm worrying about other than to have regularly created hashs ready?
Last edited by nstgc (2017-02-03 17:20:25)
Offline
Pages: 1