6

I've been writing to a 3TB USB external hard drive (WD MyBook) with a Btrfs filesystem, when accidentally I've switched the power off to the drive's power brick.

What is strange - the write operations seemed to continue (I expected an immediate I/O error). I have killed the rsync process manually and tried to remount the filesystem.

The /dev/sdf node was still there, but I was unable to mount it.

I've tried partprobe and btrfs device scan to no avail.

After rebooting I was unable to mount the filesystem again. I've run a btrfs rescue chunk-recover -v on the drive, and after about 14 hours found this:

(A long list of good chunks)
Chunk: start = 1992919351296, len = 1073741824, type = 1, num_stripes = 1
      Stripes list:
      [ 0] Stripe: devid = 1, offset = 1975739482112
      No block group.
      Device extent list:
          [ 0]Device extent: devid = 1, start = 1975739482112, len = 1073741824, chunk offset = 1992919351296
  Chunk: start = 1993993093120, len = 1073741824, type = 1, num_stripes = 1
      Stripes list:
      [ 0] Stripe: devid = 1, offset = 1976813223936
      No block group.
      Device extent list:
          [ 0]Device extent: devid = 1, start = 1976813223936, len = 1073741824, chunk offset = 1993993093120
Unrecoverable Chunks:
  Chunk: start = 1995066834944, len = 1073741824, type = 1, num_stripes = 1
      Stripes list:
      [ 0] Stripe: devid = 1, offset = 1977886965760
      No block group.
      No device extent.
  Chunk: start = 1996140576768, len = 1073741824, type = 1, num_stripes = 1
      Stripes list:
      [ 0] Stripe: devid = 1, offset = 1978960707584
      No block group.
      No device extent.
  Chunk: start = 1997214318592, len = 1073741824, type = 1, num_stripes = 1
      Stripes list:
      [ 0] Stripe: devid = 1, offset = 1980034449408
      No block group.
      No device extent.
  Chunk: start = 1998288060416, len = 1073741824, type = 1, num_stripes = 1
      Stripes list:
      [ 0] Stripe: devid = 1, offset = 1981108191232
      No block group.
      No device extent.
  Chunk: start = 1361559158784, len = 1073741824, type = 1, num_stripes = 0
      Stripes list:
      Block Group: start = 1361559158784, len = 1073741824, flag = 1
      No device extent.

Total Chunks:           1850
  Recoverable:          1845
  Unrecoverable:        5

Orphan Block Groups:

Orphan Device Extents:

parent transid verify failed on 1634923266048 wanted 1530 found 1532
parent transid verify failed on 1634923266048 wanted 1530 found 1532
Ignoring transid failure
Couldn't setup extent tree
open with broken chunk error
Chunk tree recovery failed

After a long list of chunks, there's a few that were unrecoverable. What does that mean?

I've tried all possible btrfs command including scrub, check, --init-extent-tree, zero-log but the y all end up doing nothing with a similar output:

# btrfs check -p /dev/sdc
Opening filesystem to check...
parent transid verify failed on 1634923266048 wanted 1530 found 1532
parent transid verify failed on 1634923266048 wanted 1530 found 1532
Ignoring transid failure
Couldn't setup extent tree
ERROR: cannot open file system

Is it possible that I have completely trashed a Btrfs filesystem just with an unexpected power failure?

You can find more detail about this case here: https://forum.manjaro.org/t/unfixable-btrfs-filesystem-after-a-power-failure/80994

Improve this question
4
  • May I know why was this question down-voted?
    – unfa
    Mar 30, 2019 at 8:50
  • Thank you @fra-san - I've fixed hat and also rehauled the question with newly found information and hopefully made it more focused.
    – unfa
    Mar 30, 2019 at 10:10
  • For this sort of issue the best resource is the BTRFS mailing list. If you simply execute a bunch BTRFS commands you can cause more harm than good. I suggest you ask your question there.
    – Emmanuel Rosa
    Mar 31, 2019 at 1:33
  • Thanks. Looks like I've run btrfs check --repair without first reading all about it and trashed my filesystem that way.
    – unfa
    Apr 4, 2019 at 11:53

1 Answer 1

Reset to default
2

DO NOT USE btrfs check UNLESS YOU REALLY KNOW WHAT ARE YOU DOING! IT MAY TRASH YOUR FILESYSTEM!

I've contacted the Btrfs mailing list, and I've learned that the any use of btrfs check --repair may lead to increased filesystem damage.

Looks like I have foolishly used that command after a small issue, and rendered the filesystem bricked.

It shows a warning when you run it to read help:

# btrfs check
btrfs check: too few arguments
usage: btrfs check [options] <device>

    Check structural integrity of a filesystem (unmounted).

    Check structural integrity of an unmounted filesystem. Verify internal
    trees' consistency and item connectivity. In the repair mode try to
    fix the problems found. 
    WARNING: the repair mode is considered dangerous and should not be used
             without prior analysis of problems found on the filesystem.

More information: https://btrfs.wiki.kernel.org/index.php/Btrfsck

Improve this answer

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .