On Mon, 2015-12-28 at 18:08 -0600, Zach Fuller wrote: > I ran "btrfs check --repair" again on the drive, and no "type > mismatch > with chunk" errors were returned. You should always be very conservative in using --repair... AFAIU, it *may* do more bad than good,... often the best idea is to either wait till some developer encourages you do try it or as a last resort... If you do have backups, than I'd suggest now is the time you start to diff your precious data, to find out whether anything may have been corrupted. > I then mounted the drive, ran "du -s", unmounted the drive again, and > ran "btrfs check" one more time to see if any errors remained: > > > $ sudo btrfs check /dev/sdc1 2>&1 | tee check2.txt > checking extents > checking free space cache > Wanted bytes 737280, found 1245184 for off 5683961462784 > Wanted bytes 536870912, found 1245184 for off 5683961462784 > cache appears valid but isnt 5683961462784 > Checking filesystem on /dev/sdc1 > UUID: 1a160f37-7206-43f9-9285-6217ee97a665 > found 1681690084900 bytes used err is -22 > I'm not sure what the output of the above check means, but there are > certainly less errors than before. Should I be worried about these > "free space cache" errors? Well it does seems as if something would still not be as it should... :-/ So my recommendation would be... (unless someone more senior on the list has a better advise)... backup your current data, compare it with previous backups,... and start with a fresh filesystem... or at least that's what I personally would do - but I'm uber careful, and others would maybe just continue with the fs as is, as long as it doesn't show severe problems during usage. Cheers, Chris.
Attachment:
smime.p7s
Description: S/MIME cryptographic signature
