Recover from "journal entries X-Y missing! (replaying X-Z)", "IO error on writing btree."

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



Hello!

During boot my bcache device cannot be activated anymore and hence the
filesystem content is inaccessible.  It appears that parts of the journal are
corrupted, since dmesg says:
```
bcache: register_bdev() registered backing device sda3
bcache: error on UUID:
bcache: journal entries X-Y missing! (replaying X-Z)
, disabling caching
bcache: bch_count_io_errors() nvme0n1: IO error on writing btree.
bcache: bch_btree_insert() error -5
bcache: bch_cached_dev_attach() Can't attach sda3: shutting down
bcache: register_cache() registered cache device nvme0n1
bcache: bch_count_io_errors() nvme0n1: IO error on writing btree.
bcache: bch_count_io_errors() nvme0n1: IO error on writing btree.
bcache: bch_count_io_errors() nvme0n1: IO error on writing btree.
bcache: bch_count_io_errors() nvme0n1: IO error on writing btree.
bcache: bch_count_io_errors() nvme0n1: IO error on writing btree.
bcache: bch_count_io_errors() nvme0n1: IO error on writing btree.
bcache: cache_set_free() Cache set UUID unregistered
```

UUID represents a UUID.  X, Y, Z are integers, with X<Y<Z, Y=X+12 and Z=Y+116.

Error -5 is EIO, i.e. a generic I/O error.  Is there a way to get more
information on where that error originates from and what exactly is broken?
Did bcache just detect broken data, or is the device itself broken?  Which
device, the HDD or the NVMe SSD?

Is there a way to recover from this without loosing all data on the drive?  Is
it maybe possible to just discard the journal entries >X and return to the
state the block device was at point X, loosing only modifications after that
point?

Background: The situation appeared after my computer was running for a few
hours and the screen stayed dark when I tried to wake the monitor from
standby.  The machine did not react to NumLock or Ctrl+Alt+Entf, so I issued a
magic SysRq and tried to safely reboot the machine by slowly typing REISUB.
Sadly after this the machine ended up in the state described above.

Any help would be appreciated!

Thanks in advance,
Dennis

Attachment: signature.asc
Description: This is a digitally signed message part.


[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[Index of Archives]     [Linux ARM Kernel]     [Linux Filesystem Development]     [Linux ARM]     [Linux Omap]     [Fedora ARM]     [IETF Annouce]     [Security]     [Bugtraq]     [Linux OMAP]     [Linux MIPS]     [ECOS]     [Asterisk Internet PBX]     [Linux API]

  Powered by Linux