On Wed, Apr 1, 2015 at 2:04 PM, Chris Murphy <lists@xxxxxxxxxxxxxxxxx> wrote:
> When I had this same btrfs check error, it was the exact inode number
> and same /etc/shadow file. I didn't diff the two shadow files, but I
That's too bizarre for words. Two folks, on two different systems,
getting btrfs problems on similar kernels on the exact same filepath.
In my case, the file was last frobbed by yum/rpm. Do we have a strange
interaction between a kernel regression and yum/rpm rubbing the
filesystem the wrong way?
BTW, I did not change/touch the file at all. My only "fix" action was
the btrfs check --repair mentioned earlier. Right now, on the booted
system I did
# uname -a
Linux tp-martin.remote-learner.net 3.18.9-200.fc21.x86_64 #1 SMP Mon
Mar 9 15:10:50 UTC 2015 x86_64 x86_64 x86_64 GNU/Linux
# btrfs scrub start -BrR /
scrub done for 94637b35-a294-4be2-aa47-82c52d6d53ef
scrub started at Wed Apr 1 13:46:20 2015 and finished after 266 seconds
data_extents_scrubbed: 344155
tree_extents_scrubbed: 58048
data_bytes_scrubbed: 11896840192
tree_bytes_scrubbed: 951058432
read_errors: 0
csum_errors: 0
verify_errors: 0
no_csum: 20268
csum_discards: 254459
super_errors: 0
malloc_errors: 0
uncorrectable_errors: 0
unverified_errors: 0
corrected_errors: 0
last_physical: 23928504320
cheers,
m
--
martin.langhoff@xxxxxxxxx
- ask interesting questions
- don't get distracted with shiny stuff - working code first
~ http://docs.moodle.org/en/User:Martin_Langhoff
--
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
