Linux-BTRFS Archive on lore.kernel.org
 help / color / Atom feed
From: Qu Wenruo <quwenruo.btrfs@gmx.com>
To: Chiung-Ming Huang <photon3108@gmail.com>
Cc: Btrfs <linux-btrfs@vger.kernel.org>
Subject: Re: How to Fix 'Error: could not find extent items for root 257'?
Date: Mon, 10 Feb 2020 15:03:28 +0800
Message-ID: <8d8be3c5-e186-d1d5-c270-da22c61f1495@gmx.com> (raw)
In-Reply-To: <CAEOGEKHARKKSYMEU5kbswA7-PjxT9xAOomktG32h9RS6aYUVjA@mail.gmail.com>

[-- Attachment #1.1: Type: text/plain, Size: 4049 bytes --]



On 2020/2/10 下午2:50, Chiung-Ming Huang wrote:
> Qu Wenruo <quwenruo.btrfs@gmx.com> 於 2020年2月7日 週五 下午3:16寫道:
>>
>>
>>
>> On 2020/2/7 下午2:16, Chiung-Ming Huang wrote:
>>> Qu Wenruo <quwenruo.btrfs@gmx.com> 於 2020年2月7日 週五 下午12:00寫道:
>>>>
>>>> All these subvolumes had a missing root dir. That's not good either.
>>>> I guess btrfs-restore is your last chance, or RO mount with my
>>>> rescue=skipbg patchset:
>>>> https://patchwork.kernel.org/project/linux-btrfs/list/?series=170715
>>>>
>>>
>>> Is it possible to use original disks to keep the restored data safely?
>>> I would like
>>> to restore the data of /dev/bcache3 to the new btrfs RAID0 at the first and then
>>> add it to the new btrfs RAID0. Does `btrfs restore` need metadata or something
>>> in /dev/bcache3 to restore /dev/bcache2 and /dev/bcache4?
>>
>> Devid 1 (bcache 2) seems OK to be missing, as all its data and metadata
>> are in RAID1.
>>
>> But it's strongly recommended to test without wiping bcache2, to make
>> sure btrfs-restore can salvage enough data, then wipeing bcache2.
>>
>> Thanks,
>> Qu
> 
> Is it possible to shrink the size of bcache2 btrfs without making
> everything worse?
> I need more disk space but I still need bcache2 itself.

That is kinda possible, but please keep in mind that, even in the best
case, it still needs to write some (very small amount) metadata into the
fs, thus I can't ensure it won't make things worse, or even possible
without falling back to RO.

You need to dump the device extent tree, to determine the where the last
dev extent is for each device, then shrink to that size.

Some example here:

# btrfs ins dump-tree -t dev /dev/nvme/btrfs
...

        item 6 key (1 DEV_EXTENT 2169503744) itemoff 15955 itemsize 48
                dev extent chunk_tree 3
                chunk_objectid 256 chunk_offset 2169503744 length 1073741824
                chunk_tree_uuid 00000000-0000-0000-0000-000000000000

Here for the key, 1 means devid 1, 2169503744 means where the device
extent starts at. 1073741824 is the length of the device extent.

In above case, the device with devid 1 can be resized to 2169503744 +
1073741824, without relocating any data/metadata.

# time btrfs fi resize 1:3243245568 /mnt/btrfs/
Resize '/mnt/btrfs/' of '1:3243245568'

real    0m0.013s
user    0m0.006s
sys     0m0.004s

And the dump-tree shows the same last device extent:
...
        item 6 key (1 DEV_EXTENT 2169503744) itemoff 15955 itemsize 48
                dev extent chunk_tree 3
                chunk_objectid 256 chunk_offset 2169503744 length 1073741824
                chunk_tree_uuid 00000000-0000-0000-0000-000000000000

(Maybe it's a good time to implement some like fast shrink for btrfs-progs)

Of course, after resizing btrfs, you still need to resize bcache, but
that's not related to btrfs (and I am not familiar with bcache either).

Thanks,
Qu

> 
> Regards,
> Chiung-Ming Huang
> 
> 
>>>
>>> /dev/bcache2, ID: 1
>>>    Device size:             9.09TiB
>>>    Device slack:              0.00B
>>>    Data,RAID1:              3.93TiB
>>>    Metadata,RAID1:          2.00GiB
>>>    System,RAID1:           32.00MiB
>>>    Unallocated:             5.16TiB
>>>
>>> /dev/bcache3, ID: 3
>>>    Device size:             2.73TiB
>>>    Device slack:              0.00B
>>>    Data,single:           378.00GiB
>>>    Data,RAID1:            355.00GiB
>>>    Metadata,single:         2.00GiB
>>>    Metadata,RAID1:         11.00GiB
>>>    Unallocated:             2.00TiB
>>>
>>> /dev/bcache4, ID: 5
>>>    Device size:             9.09TiB
>>>    Device slack:              0.00B
>>>    Data,single:             2.93TiB
>>>    Data,RAID1:              4.15TiB
>>>    Metadata,single:         6.00GiB
>>>    Metadata,RAID1:         11.00GiB
>>>    System,RAID1:           32.00MiB
>>>    Unallocated:             2.00TiB
>>>
>>> Regards,
>>> Chiung-Ming Huang
>>>
>>


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 488 bytes --]

  reply index

Thread overview: 16+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-02-05 10:18 Chiung-Ming Huang
2020-02-05 10:29 ` Qu Wenruo
2020-02-05 15:29   ` Chiung-Ming Huang
2020-02-05 19:38     ` Chris Murphy
2020-02-06  3:11       ` Chiung-Ming Huang
     [not found]   ` <CAEOGEKHf9F0VM=au-42MwD63_V8RwtqiskV0LsGpq-c=J_qyPg@mail.gmail.com>
     [not found]     ` <f2ad6b4f-b011-8954-77e1-5162c84f7c1f@gmx.com>
2020-02-06  4:13       ` Chiung-Ming Huang
2020-02-06  4:35         ` Qu Wenruo
2020-02-06  6:50           ` Chiung-Ming Huang
2020-02-07  3:49           ` Chiung-Ming Huang
2020-02-07  4:00             ` Qu Wenruo
2020-02-07  6:16               ` Chiung-Ming Huang
2020-02-07  7:16                 ` Qu Wenruo
2020-02-10  6:50                   ` Chiung-Ming Huang
2020-02-10  7:03                     ` Qu Wenruo [this message]
2020-02-15  3:47                       ` Chiung-Ming Huang
2020-02-15  4:29                         ` Qu Wenruo

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=8d8be3c5-e186-d1d5-c270-da22c61f1495@gmx.com \
    --to=quwenruo.btrfs@gmx.com \
    --cc=linux-btrfs@vger.kernel.org \
    --cc=photon3108@gmail.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link

Linux-BTRFS Archive on lore.kernel.org

Archives are clonable:
	git clone --mirror https://lore.kernel.org/linux-btrfs/0 linux-btrfs/git/0.git

	# If you have public-inbox 1.1+ installed, you may
	# initialize and index your mirror using the following commands:
	public-inbox-init -V2 linux-btrfs linux-btrfs/ https://lore.kernel.org/linux-btrfs \
		linux-btrfs@vger.kernel.org
	public-inbox-index linux-btrfs

Example config snippet for mirrors

Newsgroup available over NNTP:
	nntp://nntp.lore.kernel.org/org.kernel.vger.linux-btrfs


AGPL code for this site: git clone https://public-inbox.org/public-inbox.git