From: "Henri Hyyryläinen" <henri.hyyrylainen@gmail.com>
To: Qu Wenruo <quwenruo.btrfs@gmx.com>, Qu Wenruo <wqu@suse.com>,
linux-btrfs@vger.kernel.org
Subject: Re: How to remove an unremovable file and directory?
Date: Sun, 5 Oct 2025 11:20:47 +0300 [thread overview]
Message-ID: <e34577ac-3b2a-4fc8-8d04-b06f9b70cc5b@gmail.com> (raw)
In-Reply-To: <2836fb95-a819-43fd-913e-a7c7f7741665@gmx.com>
Hello,
The check has completed and, probably thanks to the second repair, it
did not find much. Here's the full output:
> [1/8] checking log skipped (none written)
> [2/8] checking root items
> [3/8] checking extents
> Device extent[4, 19977638903808, 1073741824] didn't find the relative
> chunk.
> [4/8] checking free space cache
> [5/8] checking fs roots
> [6/8] checking only csums items (without verifying data)
> [7/8] checking root refs
> [8/8] checking quota groups skipped (not enabled on this FS)
> Opening filesystem to check...
> Checking filesystem on /dev/sdb
> UUID: 2b4ad16d-e456-4adf-960b-dca43560b98b
> found 49454062784512 bytes used, no error found
> total csum bytes: 48225005724
> total tree bytes: 72333164544
> total fs tree bytes: 19189743616
> total extent tree bytes: 3319316480
> btree space waste bytes: 5998261217
> file data blocks allocated: 119737771229184
> referenced 72125752061952
- Henri Hyyryläinen
Qu Wenruo kirjoitti 5.10.2025 klo 1.41:
>
>
> 在 2025/10/5 09:06, Henri Hyyryläinen 写道:
>> Thanks for the command.
>>
>> I tried reading through the data but I could not determine if there
>> was any information related to scrub or balance status.
>
> It's fine. No persistent item for balance/dev-replace. So it's not
> involved.
>
> Waiting for the readonly check result.
>
> And meanwhile, please prepare an environment to compile btrfs-progs.
>
> If there is only one stray dev extent, I'll create a simple dirty fix
> so that you can mount the fs again.
>
> Thanks,
> Qu
>
>>
>> Here's the full output I got:
>>
>>> btrfs-progs v6.16.1
>>> root tree
>>> leaf 227587769614336 items 61 free space 3547 generation 2035509
>>> owner ROOT_TREE
>>> leaf 227587769614336 flags 0x1(WRITTEN) backref revision 1
>>> fs uuid 2b4ad16d-e456-4adf-960b-dca43560b98b
>>> chunk uuid 0e317678-73cc-4485-ab6b-987285e19681
>>> item 0 key (EXTENT_TREE ROOT_ITEM 0) itemoff 15844 itemsize 439
>>> generation 2035509 root_dirid 0 bytenr 227587769630720
>>> byte_limit 0 bytes_used 3319316480
>>> last_snapshot 0 flags 0x0(none) refs 1
>>> drop_progress key (0 UNKNOWN.0 0) drop_level 0
>>> level 3 generation_v2 2035509
>>> uuid 00000000-0000-0000-0000-000000000000
>>> parent_uuid 00000000-0000-0000-0000-000000000000
>>> received_uuid 00000000-0000-0000-0000-000000000000
>>> ctransid 0 otransid 0 stransid 0 rtransid 0
>>> ctime 0.0 (1970-01-01 02:00:00)
>>> otime 0.0 (1970-01-01 02:00:00)
>>> stime 0.0 (1970-01-01 02:00:00)
>>> rtime 0.0 (1970-01-01 02:00:00)
>>> item 1 key (DEV_TREE ROOT_ITEM 0) itemoff 15405 itemsize 439
>>> generation 2025974 root_dirid 0 bytenr 227594196631552
>>> byte_limit 0 bytes_used 21889024
>>> last_snapshot 0 flags 0x0(none) refs 1
>>> drop_progress key (0 UNKNOWN.0 0) drop_level 0
>>> level 2 generation_v2 2025974
>>> uuid 00000000-0000-0000-0000-000000000000
>>> parent_uuid 00000000-0000-0000-0000-000000000000
>>> received_uuid 00000000-0000-0000-0000-000000000000
>>> ctransid 0 otransid 0 stransid 0 rtransid 0
>>> ctime 0.0 (1970-01-01 02:00:00)
>>> otime 0.0 (1970-01-01 02:00:00)
>>> stime 0.0 (1970-01-01 02:00:00)
>>> rtime 0.0 (1970-01-01 02:00:00)
>>> item 2 key (FS_TREE INODE_REF 6) itemoff 15388 itemsize 17
>>> index 0 namelen 7 name: default
>>> item 3 key (FS_TREE ROOT_ITEM 0) itemoff 14949 itemsize 439
>>> generation 2025975 root_dirid 256 bytenr 227573939142656
>>> byte_limit 0 bytes_used 6603997184
>>> last_snapshot 2025951 flags 0x0(none) refs 1
>>> drop_progress key (0 UNKNOWN.0 0) drop_level 0
>>> level 3 generation_v2 2025975
>>> uuid eea49a45-adcf-4bff-a203-0f600f2db6a8
>>> parent_uuid 00000000-0000-0000-0000-000000000000
>>> received_uuid 00000000-0000-0000-0000-000000000000
>>> ctransid 2025953 otransid 0 stransid 0 rtransid 0
>>> ctime 1759258850.523837328 (2025-09-30 22:00:50)
>>> otime 1679586168.0 (2023-03-23 17:42:48)
>>> stime 0.0 (1970-01-01 02:00:00)
>>> rtime 0.0 (1970-01-01 02:00:00)
>>> item 4 key (FS_TREE ROOT_REF 256) itemoff 14921 itemsize 28
>>> root ref key dirid 256 sequence 6 name .snapshots
>>> item 5 key (ROOT_TREE_DIR INODE_ITEM 0) itemoff 14761 itemsize 160
>>> generation 3 transid 0 size 0 nbytes 16384
>>> block group 0 mode 40755 links 1 uid 0 gid 0 rdev 0
>>> sequence 0 flags 0x0(none)
>>> atime 1679586169.0 (2023-03-23 17:42:49)
>>> ctime 1679586169.0 (2023-03-23 17:42:49)
>>> mtime 1679586169.0 (2023-03-23 17:42:49)
>>> otime 1679586169.0 (2023-03-23 17:42:49)
>>> item 6 key (ROOT_TREE_DIR INODE_REF 6) itemoff 14749 itemsize 12
>>> index 0 namelen 2 name: ..
>>> item 7 key (ROOT_TREE_DIR DIR_ITEM 2378154706) itemoff 14712
>>> itemsize 37
>>> location key (FS_TREE ROOT_ITEM 18446744073709551615) type DIR
>>> transid 0 data_len 0 name_len 7
>>> name: default
>>> item 8 key (CSUM_TREE ROOT_ITEM 0) itemoff 14273 itemsize 439
>>> generation 2025954 root_dirid 0 bytenr 227588044062720
>>> byte_limit 0 bytes_used 49791238144
>>> last_snapshot 0 flags 0x0(none) refs 1
>>> drop_progress key (0 UNKNOWN.0 0) drop_level 0
>>> level 3 generation_v2 2025954
>>> uuid 00000000-0000-0000-0000-000000000000
>>> parent_uuid 00000000-0000-0000-0000-000000000000
>>> received_uuid 00000000-0000-0000-0000-000000000000
>>> ctransid 0 otransid 0 stransid 0 rtransid 0
>>> ctime 0.0 (1970-01-01 02:00:00)
>>> otime 0.0 (1970-01-01 02:00:00)
>>> stime 0.0 (1970-01-01 02:00:00)
>>> rtime 0.0 (1970-01-01 02:00:00)
>>> item 9 key (UUID_TREE ROOT_ITEM 0) itemoff 13834 itemsize 439
>>> generation 2025954 root_dirid 0 bytenr 227587802447872
>>> byte_limit 0 bytes_used 16384
>>> last_snapshot 0 flags 0x0(none) refs 1
>>> drop_progress key (0 UNKNOWN.0 0) drop_level 0
>>> level 0 generation_v2 2025954
>>> uuid 00000000-0000-0000-0000-000000000000
>>> parent_uuid 00000000-0000-0000-0000-000000000000
>>> received_uuid 00000000-0000-0000-0000-000000000000
>>> ctransid 0 otransid 0 stransid 0 rtransid 0
>>> ctime 0.0 (1970-01-01 02:00:00)
>>> otime 0.0 (1970-01-01 02:00:00)
>>> stime 0.0 (1970-01-01 02:00:00)
>>> rtime 0.0 (1970-01-01 02:00:00)
>>> item 10 key (256 ROOT_ITEM 0) itemoff 13395 itemsize 439
>>> generation 2025954 root_dirid 256 bytenr 227587802316800
>>> byte_limit 0 bytes_used 49152
>>> last_snapshot 2015386 flags 0x0(none) refs 1
>>> drop_progress key (0 UNKNOWN.0 0) drop_level 0
>>> level 1 generation_v2 2025954
>>> uuid 56f85f76-1eb8-1245-a35b-8a9307d5c68f
>>> parent_uuid 00000000-0000-0000-0000-000000000000
>>> received_uuid 00000000-0000-0000-0000-000000000000
>>> ctransid 2025954 otransid 31 stransid 0 rtransid 0
>>> ctime 1759260258.238143629 (2025-09-30 22:24:18)
>>> otime 1679588253.995834574 (2023-03-23 18:17:33)
>>> stime 0.0 (1970-01-01 02:00:00)
>>> rtime 0.0 (1970-01-01 02:00:00)
>>> item 11 key (256 ROOT_BACKREF 5) itemoff 13367 itemsize 28
>>> root backref key dirid 256 sequence 6 name .snapshots
>>> item 12 key (256 ROOT_REF 14428) itemoff 13341 itemsize 26
>>> root ref key dirid 28589 sequence 2 name snapshot
>>> item 13 key (256 ROOT_REF 14451) itemoff 13315 itemsize 26
>>> root ref key dirid 28635 sequence 2 name snapshot
>>> item 14 key (256 ROOT_REF 14475) itemoff 13289 itemsize 26
>>> root ref key dirid 28683 sequence 2 name snapshot
>>> item 15 key (256 ROOT_REF 14499) itemoff 13263 itemsize 26
>>> root ref key dirid 28731 sequence 2 name snapshot
>>> item 16 key (256 ROOT_REF 14523) itemoff 13237 itemsize 26
>>> root ref key dirid 28779 sequence 2 name snapshot
>>> item 17 key (256 ROOT_REF 14547) itemoff 13211 itemsize 26
>>> root ref key dirid 28827 sequence 2 name snapshot
>>> item 18 key (256 ROOT_REF 14559) itemoff 13185 itemsize 26
>>> root ref key dirid 28851 sequence 2 name snapshot
>>> item 19 key (256 ROOT_REF 14583) itemoff 13159 itemsize 26
>>> root ref key dirid 28899 sequence 2 name snapshot
>>> item 20 key (256 ROOT_REF 14607) itemoff 13133 itemsize 26
>>> root ref key dirid 28947 sequence 2 name snapshot
>>> item 21 key (256 ROOT_REF 14631) itemoff 13107 itemsize 26
>>> root ref key dirid 28995 sequence 2 name snapshot
>>> item 22 key (256 ROOT_REF 14640) itemoff 13081 itemsize 26
>>> root ref key dirid 29013 sequence 2 name snapshot
>>> item 23 key (256 ROOT_REF 14641) itemoff 13055 itemsize 26
>>> root ref key dirid 29015 sequence 2 name snapshot
>>> item 24 key (256 ROOT_REF 14642) itemoff 13029 itemsize 26
>>> root ref key dirid 29017 sequence 2 name snapshot
>>> item 25 key (256 ROOT_REF 14643) itemoff 13003 itemsize 26
>>> root ref key dirid 29019 sequence 2 name snapshot
>>> item 26 key (256 ROOT_REF 14644) itemoff 12977 itemsize 26
>>> root ref key dirid 29021 sequence 2 name snapshot
>>> item 27 key (256 ROOT_REF 14645) itemoff 12951 itemsize 26
>>> root ref key dirid 29023 sequence 2 name snapshot
>>> item 28 key (14428 ROOT_ITEM 1849346) itemoff 12512 itemsize 439
>>> generation 2025978 root_dirid 256 bytenr 71398781173760
>>> byte_limit 0 bytes_used 8815476736
>>> last_snapshot 2018745 flags 0x1(RDONLY) refs 1
>>> drop_progress key (0 UNKNOWN.0 0) drop_level 0
>>> level 3 generation_v2 2025978
>>> uuid 97cd122d-c519-8746-bdfe-13479bfefb9d
>>> parent_uuid eea49a45-adcf-4bff-a203-0f600f2db6a8
>>> received_uuid 00000000-0000-0000-0000-000000000000
>>> ctransid 1849346 otransid 1849346 stransid 0 rtransid 0
>>> ctime 1758406304.841464812 (2025-09-21 01:11:44)
>>> otime 1758406304.840394467 (2025-09-21 01:11:44)
>>> stime 0.0 (1970-01-01 02:00:00)
>>> rtime 0.0 (1970-01-01 02:00:00)
>>> item 29 key (14428 ROOT_BACKREF 256) itemoff 12486 itemsize 26
>>> root backref key dirid 28589 sequence 2 name snapshot
>>> item 30 key (14451 ROOT_ITEM 1899154) itemoff 12047 itemsize 439
>>> generation 2025981 root_dirid 256 bytenr 71398809468928
>>> byte_limit 0 bytes_used 6747799552
>>> last_snapshot 2018745 flags 0x1(RDONLY) refs 1
>>> drop_progress key (0 UNKNOWN.0 0) drop_level 0
>>> level 3 generation_v2 2025981
>>> uuid c5e2ba38-c982-8a4f-99e5-bb9ff8c5f7cd
>>> parent_uuid eea49a45-adcf-4bff-a203-0f600f2db6a8
>>> received_uuid 00000000-0000-0000-0000-000000000000
>>> ctransid 1897416 otransid 1899154 stransid 0 rtransid 0
>>> ctime 1758484800.817458724 (2025-09-21 23:00:00)
>>> otime 1758488400.101635440 (2025-09-22 00:00:00)
>>> stime 0.0 (1970-01-01 02:00:00)
>>> rtime 0.0 (1970-01-01 02:00:00)
>>> item 31 key (14451 ROOT_BACKREF 256) itemoff 12021 itemsize 26
>>> root backref key dirid 28635 sequence 2 name snapshot
>>> item 32 key (14475 ROOT_ITEM 1942246) itemoff 11582 itemsize 439
>>> generation 2025984 root_dirid 256 bytenr 71398831259648
>>> byte_limit 0 bytes_used 6755549184
>>> last_snapshot 2018745 flags 0x1(RDONLY) refs 1
>>> drop_progress key (0 UNKNOWN.0 0) drop_level 0
>>> level 3 generation_v2 2025984
>>> uuid 38b9ea09-54ef-5140-bddc-83dc884c31b3
>>> parent_uuid eea49a45-adcf-4bff-a203-0f600f2db6a8
>>> received_uuid 00000000-0000-0000-0000-000000000000
>>> ctransid 1940067 otransid 1942246 stransid 0 rtransid 0
>>> ctime 1758570000.151997903 (2025-09-22 22:40:00)
>>> otime 1758574800.777676964 (2025-09-23 00:00:00)
>>> stime 0.0 (1970-01-01 02:00:00)
>>> rtime 0.0 (1970-01-01 02:00:00)
>>> item 33 key (14475 ROOT_BACKREF 256) itemoff 11556 itemsize 26
>>> root backref key dirid 28683 sequence 2 name snapshot
>>> item 34 key (14499 ROOT_ITEM 1977241) itemoff 11117 itemsize 439
>>> generation 2025986 root_dirid 256 bytenr 71398873153536
>>> byte_limit 0 bytes_used 6538182656
>>> last_snapshot 2018745 flags 0x1(RDONLY) refs 1
>>> drop_progress key (0 UNKNOWN.0 0) drop_level 0
>>> level 3 generation_v2 2025986
>>> uuid 703f0298-831b-1e4d-b1f1-fc37ff582770
>>> parent_uuid eea49a45-adcf-4bff-a203-0f600f2db6a8
>>> received_uuid 00000000-0000-0000-0000-000000000000
>>> ctransid 1977241 otransid 1977241 stransid 0 rtransid 0
>>> ctime 1758661201.518446292 (2025-09-24 00:00:01)
>>> otime 1758661204.161207119 (2025-09-24 00:00:04)
>>> stime 0.0 (1970-01-01 02:00:00)
>>> rtime 0.0 (1970-01-01 02:00:00)
>>> item 35 key (14499 ROOT_BACKREF 256) itemoff 11091 itemsize 26
>>> root backref key dirid 28731 sequence 2 name snapshot
>>> item 36 key (14523 ROOT_ITEM 2001507) itemoff 10652 itemsize 439
>>> generation 2025988 root_dirid 256 bytenr 71398873497600
>>> byte_limit 0 bytes_used 6561398784
>>> last_snapshot 2018745 flags 0x1(RDONLY) refs 1
>>> drop_progress key (0 UNKNOWN.0 0) drop_level 0
>>> level 3 generation_v2 2025988
>>> uuid 9672abd0-7e7b-ab4f-9e0f-7183e58bb6c4
>>> parent_uuid eea49a45-adcf-4bff-a203-0f600f2db6a8
>>> received_uuid 00000000-0000-0000-0000-000000000000
>>> ctransid 2001507 otransid 2001507 stransid 0 rtransid 0
>>> ctime 1758747600.712874426 (2025-09-25 00:00:00)
>>> otime 1758747600.840460363 (2025-09-25 00:00:00)
>>> stime 0.0 (1970-01-01 02:00:00)
>>> rtime 0.0 (1970-01-01 02:00:00)
>>> item 37 key (14523 ROOT_BACKREF 256) itemoff 10626 itemsize 26
>>> root backref key dirid 28779 sequence 2 name snapshot
>>> item 38 key (14547 ROOT_ITEM 2017206) itemoff 10187 itemsize 439
>>> generation 2025990 root_dirid 256 bytenr 71398872924160
>>> byte_limit 0 bytes_used 6570868736
>>> last_snapshot 2018745 flags 0x1(RDONLY) refs 1
>>> drop_progress key (0 UNKNOWN.0 0) drop_level 0
>>> level 3 generation_v2 2025990
>>> uuid 671b4b4f-fd99-e140-8535-fce0a16babfb
>>> parent_uuid eea49a45-adcf-4bff-a203-0f600f2db6a8
>>> received_uuid 00000000-0000-0000-0000-000000000000
>>> ctransid 2017206 otransid 2017206 stransid 0 rtransid 0
>>> ctime 1758834001.88320469 (2025-09-26 00:00:01)
>>> otime 1758834001.271433540 (2025-09-26 00:00:01)
>>> stime 0.0 (1970-01-01 02:00:00)
>>> rtime 0.0 (1970-01-01 02:00:00)
>>> item 39 key (14547 ROOT_BACKREF 256) itemoff 10161 itemsize 26
>>> root backref key dirid 28827 sequence 2 name snapshot
>>> item 40 key (14559 ROOT_ITEM 2019735) itemoff 9722 itemsize 439
>>> generation 2025992 root_dirid 256 bytenr 75423231606784
>>> byte_limit 0 bytes_used 6576078848
>>> last_snapshot 2019735 flags 0x1(RDONLY) refs 1
>>> drop_progress key (0 UNKNOWN.0 0) drop_level 0
>>> level 3 generation_v2 2025992
>>> uuid 3ff52125-57ee-6140-87a5-4fb848ec4638
>>> parent_uuid eea49a45-adcf-4bff-a203-0f600f2db6a8
>>> received_uuid 00000000-0000-0000-0000-000000000000
>>> ctransid 2019711 otransid 2019735 stransid 0 rtransid 0
>>> ctime 1758919659.690576855 (2025-09-26 23:47:39)
>>> otime 1758920400.700930626 (2025-09-27 00:00:00)
>>> stime 0.0 (1970-01-01 02:00:00)
>>> rtime 0.0 (1970-01-01 02:00:00)
>>> item 41 key (14559 ROOT_BACKREF 256) itemoff 9696 itemsize 26
>>> root backref key dirid 28851 sequence 2 name snapshot
>>> item 42 key (14583 ROOT_ITEM 2022097) itemoff 9257 itemsize 439
>>> generation 2025994 root_dirid 256 bytenr 65812067024896
>>> byte_limit 0 bytes_used 6557646848
>>> last_snapshot 2022097 flags 0x1(RDONLY) refs 1
>>> drop_progress key (0 UNKNOWN.0 0) drop_level 0
>>> level 3 generation_v2 2025994
>>> uuid 860f0635-f296-a04b-9fc5-bd85d480799c
>>> parent_uuid eea49a45-adcf-4bff-a203-0f600f2db6a8
>>> received_uuid 00000000-0000-0000-0000-000000000000
>>> ctransid 2022097 otransid 2022097 stransid 0 rtransid 0
>>> ctime 1759006819.37527411 (2025-09-28 00:00:19)
>>> otime 1759006820.861182212 (2025-09-28 00:00:20)
>>> stime 0.0 (1970-01-01 02:00:00)
>>> rtime 0.0 (1970-01-01 02:00:00)
>>> item 43 key (14583 ROOT_BACKREF 256) itemoff 9231 itemsize 26
>>> root backref key dirid 28899 sequence 2 name snapshot
>>> item 44 key (14607 ROOT_ITEM 2024585) itemoff 8792 itemsize 439
>>> generation 2025996 root_dirid 256 bytenr 227573944696832
>>> byte_limit 0 bytes_used 6583533568
>>> last_snapshot 2024585 flags 0x1(RDONLY) refs 1
>>> drop_progress key (0 UNKNOWN.0 0) drop_level 0
>>> level 3 generation_v2 2025996
>>> uuid af3524d0-8a9a-894c-b5b7-705b10114326
>>> parent_uuid eea49a45-adcf-4bff-a203-0f600f2db6a8
>>> received_uuid 00000000-0000-0000-0000-000000000000
>>> ctransid 2024474 otransid 2024585 stransid 0 rtransid 0
>>> ctime 1759089642.387498362 (2025-09-28 23:00:42)
>>> otime 1759093200.412309185 (2025-09-29 00:00:00)
>>> stime 0.0 (1970-01-01 02:00:00)
>>> rtime 0.0 (1970-01-01 02:00:00)
>>> item 45 key (14607 ROOT_BACKREF 256) itemoff 8766 itemsize 26
>>> root backref key dirid 28947 sequence 2 name snapshot
>>> item 46 key (14631 ROOT_ITEM 2025813) itemoff 8327 itemsize 439
>>> generation 2025998 root_dirid 256 bytenr 178141351657472
>>> byte_limit 0 bytes_used 6602981376
>>> last_snapshot 2025813 flags 0x1(RDONLY) refs 1
>>> drop_progress key (0 UNKNOWN.0 0) drop_level 0
>>> level 3 generation_v2 2025998
>>> uuid 6f085114-93b0-d146-8997-9a41ff62f8db
>>> parent_uuid eea49a45-adcf-4bff-a203-0f600f2db6a8
>>> received_uuid 00000000-0000-0000-0000-000000000000
>>> ctransid 2025812 otransid 2025813 stransid 0 rtransid 0
>>> ctime 1759177902.175859896 (2025-09-29 23:31:42)
>>> otime 1759210423.120386595 (2025-09-30 08:33:43)
>>> stime 0.0 (1970-01-01 02:00:00)
>>> rtime 0.0 (1970-01-01 02:00:00)
>>> item 47 key (14631 ROOT_BACKREF 256) itemoff 8301 itemsize 26
>>> root backref key dirid 28995 sequence 2 name snapshot
>>> item 48 key (14640 ROOT_ITEM 2025865) itemoff 7862 itemsize 439
>>> generation 2026000 root_dirid 256 bytenr 194611771719680
>>> byte_limit 0 bytes_used 6603735040
>>> last_snapshot 2025865 flags 0x1(RDONLY) refs 1
>>> drop_progress key (0 UNKNOWN.0 0) drop_level 0
>>> level 3 generation_v2 2026000
>>> uuid a48f03d9-4847-654a-af1d-5e0eaf6ecd0c
>>> parent_uuid eea49a45-adcf-4bff-a203-0f600f2db6a8
>>> received_uuid 00000000-0000-0000-0000-000000000000
>>> ctransid 2025863 otransid 2025865 stransid 0 rtransid 0
>>> ctime 1759237252.139079795 (2025-09-30 16:00:52)
>>> otime 1759240800.56609287 (2025-09-30 17:00:00)
>>> stime 0.0 (1970-01-01 02:00:00)
>>> rtime 0.0 (1970-01-01 02:00:00)
>>> item 49 key (14640 ROOT_BACKREF 256) itemoff 7836 itemsize 26
>>> root backref key dirid 29013 sequence 2 name snapshot
>>> item 50 key (14641 ROOT_ITEM 2025870) itemoff 7397 itemsize 439
>>> generation 2026002 root_dirid 256 bytenr 65801342844928
>>> byte_limit 0 bytes_used 6603292672
>>> last_snapshot 2025870 flags 0x1(RDONLY) refs 1
>>> drop_progress key (0 UNKNOWN.0 0) drop_level 0
>>> level 3 generation_v2 2026002
>>> uuid 56e7aa4e-e166-504d-9a55-8c8b074c0fd9
>>> parent_uuid eea49a45-adcf-4bff-a203-0f600f2db6a8
>>> received_uuid 00000000-0000-0000-0000-000000000000
>>> ctransid 2025868 otransid 2025870 stransid 0 rtransid 0
>>> ctime 1759241717.101400473 (2025-09-30 17:15:17)
>>> otime 1759244400.232224532 (2025-09-30 18:00:00)
>>> stime 0.0 (1970-01-01 02:00:00)
>>> rtime 0.0 (1970-01-01 02:00:00)
>>> item 51 key (14641 ROOT_BACKREF 256) itemoff 7371 itemsize 26
>>> root backref key dirid 29015 sequence 2 name snapshot
>>> item 52 key (14642 ROOT_ITEM 2025874) itemoff 6932 itemsize 439
>>> generation 2026004 root_dirid 256 bytenr 187252895498240
>>> byte_limit 0 bytes_used 6603341824
>>> last_snapshot 2025874 flags 0x1(RDONLY) refs 1
>>> drop_progress key (0 UNKNOWN.0 0) drop_level 0
>>> level 3 generation_v2 2026004
>>> uuid f1761dfd-ec60-724a-9af0-dea952cc6771
>>> parent_uuid eea49a45-adcf-4bff-a203-0f600f2db6a8
>>> received_uuid 00000000-0000-0000-0000-000000000000
>>> ctransid 2025872 otransid 2025874 stransid 0 rtransid 0
>>> ctime 1759244441.841998010 (2025-09-30 18:00:41)
>>> otime 1759248000.122051877 (2025-09-30 19:00:00)
>>> stime 0.0 (1970-01-01 02:00:00)
>>> rtime 0.0 (1970-01-01 02:00:00)
>>> item 53 key (14642 ROOT_BACKREF 256) itemoff 6906 itemsize 26
>>> root backref key dirid 29017 sequence 2 name snapshot
>>> item 54 key (14643 ROOT_ITEM 2025904) itemoff 6467 itemsize 439
>>> generation 2026006 root_dirid 256 bytenr 227587769647104
>>> byte_limit 0 bytes_used 6603587584
>>> last_snapshot 2025904 flags 0x1(RDONLY) refs 1
>>> drop_progress key (0 UNKNOWN.0 0) drop_level 0
>>> level 3 generation_v2 2026006
>>> uuid 68fd5037-6c8a-c74e-b08f-cff4cdccf752
>>> parent_uuid eea49a45-adcf-4bff-a203-0f600f2db6a8
>>> received_uuid 00000000-0000-0000-0000-000000000000
>>> ctransid 2025904 otransid 2025904 stransid 0 rtransid 0
>>> ctime 1759251597.815452999 (2025-09-30 19:59:57)
>>> otime 1759251600.884521740 (2025-09-30 20:00:00)
>>> stime 0.0 (1970-01-01 02:00:00)
>>> rtime 0.0 (1970-01-01 02:00:00)
>>> item 55 key (14643 ROOT_BACKREF 256) itemoff 6441 itemsize 26
>>> root backref key dirid 29019 sequence 2 name snapshot
>>> item 56 key (14644 ROOT_ITEM 2025922) itemoff 6002 itemsize 439
>>> generation 2026008 root_dirid 256 bytenr 227594191208448
>>> byte_limit 0 bytes_used 6603653120
>>> last_snapshot 2025922 flags 0x1(RDONLY) refs 1
>>> drop_progress key (0 UNKNOWN.0 0) drop_level 0
>>> level 3 generation_v2 2026008
>>> uuid 07ccd2ae-f51d-2c46-82df-05e16964b2e5
>>> parent_uuid eea49a45-adcf-4bff-a203-0f600f2db6a8
>>> received_uuid 00000000-0000-0000-0000-000000000000
>>> ctransid 2025921 otransid 2025922 stransid 0 rtransid 0
>>> ctime 1759254975.20573006 (2025-09-30 20:56:15)
>>> otime 1759255200.196692319 (2025-09-30 21:00:00)
>>> stime 0.0 (1970-01-01 02:00:00)
>>> rtime 0.0 (1970-01-01 02:00:00)
>>> item 57 key (14644 ROOT_BACKREF 256) itemoff 5976 itemsize 26
>>> root backref key dirid 29021 sequence 2 name snapshot
>>> item 58 key (14645 ROOT_ITEM 2025951) itemoff 5537 itemsize 439
>>> generation 2026010 root_dirid 256 bytenr 193309358817280
>>> byte_limit 0 bytes_used 6603964416
>>> last_snapshot 2025951 flags 0x1(RDONLY) refs 1
>>> drop_progress key (0 UNKNOWN.0 0) drop_level 0
>>> level 3 generation_v2 2026010
>>> uuid b46ce558-2c39-3944-91d4-b2b229f04a16
>>> parent_uuid eea49a45-adcf-4bff-a203-0f600f2db6a8
>>> received_uuid 00000000-0000-0000-0000-000000000000
>>> ctransid 2025950 otransid 2025951 stransid 0 rtransid 0
>>> ctime 1759257514.988583086 (2025-09-30 21:38:34)
>>> otime 1759258800.482340435 (2025-09-30 22:00:00)
>>> stime 0.0 (1970-01-01 02:00:00)
>>> rtime 0.0 (1970-01-01 02:00:00)
>>> item 59 key (14645 ROOT_BACKREF 256) itemoff 5511 itemsize 26
>>> root backref key dirid 29023 sequence 2 name snapshot
>>> item 60 key (DATA_RELOC_TREE ROOT_ITEM 0) itemoff 5072 itemsize 439
>>> generation 2018764 root_dirid 256 bytenr 71399055278080
>>> byte_limit 0 bytes_used 16384
>>> last_snapshot 0 flags 0x0(none) refs 1
>>> drop_progress key (0 UNKNOWN.0 0) drop_level 0
>>> level 0 generation_v2 2018764
>>> uuid 00000000-0000-0000-0000-000000000000
>>> parent_uuid 00000000-0000-0000-0000-000000000000
>>> received_uuid 00000000-0000-0000-0000-000000000000
>>> ctransid 0 otransid 0 stransid 0 rtransid 0
>>> ctime 0.0 (1970-01-01 02:00:00)
>>> otime 0.0 (1970-01-01 02:00:00)
>>> stime 0.0 (1970-01-01 02:00:00)
>>> rtime 0.0 (1970-01-01 02:00:00)
>>
>> Qu Wenruo kirjoitti 5.10.2025 klo 1.07:
>>>
>>>
>>> 在 2025/10/5 08:23, Henri Hyyryläinen 写道:
>>>>> One extra thing, at the time of the initial "btrfs check
>>>>> --repair", there is no running dev-replace/balance or whatever
>>>>> running?
>>>>>
>>>>> Although those operations will be automatically paused by unmount,
>>>>> btrfs check is not going to be able to handle some of those paused
>>>>> operations.
>>>>
>>>> Is there a way for me to check that without mounting the
>>>> filesystem? As far as I could find, none of the balance / scrub
>>>> commands allow working on an unmounted filesystem. So I couldn't
>>>> find out if I had any in canceled state.
>>>
>>> # btrfs ins dump-tree -t root <device>
>>>>
>>>> Though, I'm pretty sure I let the last scrub and balance operation
>>>> I tried to fully complete before starting using the check and
>>>> repair commands. But I'm not absolutely certain that I didn't try
>>>> one of those a last time and didn't let it fully complete.
>>>>
>>>> I'll start that "btrfs check --readonly" command now. And I'll
>>>> report back once it is done (hopefully by the morning in my timezone).
>>>>
>>>> - Henri Hyyryläinen
>>>>
>>>> Qu Wenruo kirjoitti 4.10.2025 klo 23.55:
>>>>>
>>>>>
>>>>> 在 2025/10/5 07:14, Qu Wenruo 写道:
>>>>>>
>>>>>>
>>>>>> 在 2025/10/5 04:13, Henri Hyyryläinen 写道:
>>>>>>> Hello again.
>>>>>>>
>>>>>>> It took over 3 days, but the btrfs check --repair has now
>>>>>>> completed seemingly successfully. I mostly saw output about the
>>>>>>> file being placed in lost+found and and directory size being
>>>>>>> corrected. However, there were some messages about mismatch of
>>>>>>> used bytes.
>>>>>>>
>>>>>>> Unfortunately it seems like the situation has gotten worse since
>>>>>>> the repair, because now I cannot mount the filesystem at all.
>>>>>>> Instead I get an error like this:
>>>>>>>
>>>>>>>> BTRFS error (device sdc): dev extent physical offset
>>>>>>>> 19977638903808 on devid 4 doesn't have corresponding chunk
>>>>>>>> BTRFS error (device sdc): failed to verify dev extents against
>>>>>>>> chunks: -117
>>>>>>>> BTRFS error (device sdc): open_ctree failed: -117
>>>>>>> Even if I remove that one problematic device physically from my
>>>>>>> computer, the filesystem still refuses to mount with the same
>>>>>>> error. Maybe the problems with the device replace are again
>>>>>>> showing up with the actual size of the hard drive not being used
>>>>>>> correctly? I cannot try to remove the device slack as I cannot
>>>>>>> mount the filesystem.
>>>>>>
>>>>>> Nope, this is a different problem, and not related to dev replace.
>>>>>>
>>>>>> Unfortunately btrfs check has not implemented any repair for that.
>>>>>>
>>>>>> Overall if the dev extent is found but not corresponding chunk,
>>>>>> it should still be fine but some space unavailable.
>>>>>>
>>>>>> But the kernel is overly cautious on chunk tree, as it's a very
>>>>>> important and basic functionality.
>>>>>>
>>>>>> Please provide the full "btrfs check --readonly" output so that
>>>>>> we can evaluate and add the missing repair functionality.
>>>>>
>>>>> One extra thing, at the time of the initial "btrfs check
>>>>> --repair", there is no running dev-replace/balance or whatever
>>>>> running?
>>>>>
>>>>> Although those operations will be automatically paused by unmount,
>>>>> btrfs check is not going to be able to handle some of those paused
>>>>> operations.
>>>>>>
>>>>>> Thanks,
>>>>>> Qu
>>>>>>
>>>>>>>
>>>>>>> I did try to run a repair again, and this time I got a bunch of
>>>>>>> messages like:
>>>>>>>
>>>>>>>> repair deleting extent record: key [65795546775552,169,0]
>>>>>>>> adding new tree backref on start 65795546775552 len 16384
>>>>>>>> parent 65811674234880 root 65811674234880
>>>>>>>> adding new tree backref on start 65795546775552 len 16384
>>>>>>>> parent 0 root 14499
>>>>>>>> adding new tree backref on start 65795546775552 len 16384
>>>>>>>> parent 65791012274176 root 65791012274176
>>>>>>>> adding new tree backref on start 65795546775552 len 16384
>>>>>>>> parent 65806385807360 root 65806385807360
>>>>>>>> Repaired extent references for 65795546775552
>>>>>>>> ref mismatch on [65795548233728 16384] extent item 5, found 4
>>>>>>
>>>>>> That's fixing some backref mismatch, which you can ignore unless
>>>>>> "btrfs check --reaonly" later reports new problems.
>>>>>>
>>>>>>> But the filesystem still refuses to mount with the exact same
>>>>>>> error. I did not let the repair run entirely as it would have
>>>>>>> likely taken another 3 days. What should I do? This time I'm not
>>>>>>> finding any good information on what to do. For now, I've
>>>>>>> started the repair again, but it doesn't exactly sound like it
>>>>>>> is even fixing anything now. Still, I'll let it continue. The
>>>>>>> output so far is:
>>>>>>>
>>>>>>>> [1/8] checking log skipped (none written)
>>>>>>>> [2/8] checking root items
>>>>>>>> Fixed 0 roots.
>>>>>>>> [3/8] checking extents
>>>>>>>> Device extent[4, 19977638903808, 1073741824] didn't find the
>>>>>>>> relative chunk.
>>>>>>>> super bytes used 49454738989056 mismatches actual used
>>>>>>>> 49454738923520
>>>>>>>> Device extent[4, 19977638903808, 1073741824] didn't find the
>>>>>>>> relative chunk.
>>>>>>>> super bytes used 49454739005440 mismatches actual used
>>>>>>>> 49454738956288
>>>>>>>> Device extent[4, 19977638903808, 1073741824] didn't find the
>>>>>>>> relative chunk.
>>>>>>>> super bytes used 49454739021824 mismatches actual used
>>>>>>>> 49454738972672
>>>>>>>> Device extent[4, 19977638903808, 1073741824] didn't find the
>>>>>>>> relative chunk.
>>>>>>>> super bytes used 49454739005440 mismatches actual used
>>>>>>>> 49454738972672
>>>>>>>
>>>>>>>
>>>>>>> If I was able to somehow remove that one logically corrupt devid
>>>>>>> from the filesystem, or somehow correct the size, that would
>>>>>>> hopefully allow me to rebuild from the raid10 data then, but I
>>>>>>> can't do those with the unmountable filesystem.
>>>>>>>
>>>>>>>
>>>>>>> - Henri Hyyryläinen
>>>>>>>
>>>>>>> Qu Wenruo kirjoitti 30.9.2025 klo 0.52:
>>>>>>>>
>>>>>>>>
>>>>>>>> 在 2025/9/30 02:41, Henri Hyyryläinen 写道:
>>>>>>>>> Hello,
>>>>>>>>>
>>>>>>>>> I hope this is the right place to ask about a filesystem
>>>>>>>>> problem. Really shortly put, I have a file that both exists
>>>>>>>>> and doesn't and prevents the containing directory from being
>>>>>>>>> deleted. No matter what variant of rm and inode based deletion
>>>>>>>>> I try I get an error about the file not existing, and I also
>>>>>>>>> cannot try to read the file, but if I try to delete the
>>>>>>>>> directory I get an error that it is not empty (so the file
>>>>>>>>> kind of exists). Trying to ls the directory also gives a file
>>>>>>>>> doesn't exist error.
>>>>>>>>>
>>>>>>>>> Here's what btrfs check found, which I hope does better in
>>>>>>>>> illustrating the problem:
>>>>>>>>>
>>>>>>>>>> root 5 inode 25953213 errors 200, dir isize wrong
>>>>>>>>>> root 5 inode 27166085 errors 2000, link count wrong
>>>>>>>>>> unresolved ref dir 25953213 index 7 namelen 33 name
>>>>>>>>>> Microsoft.AspNetCore.Metadata.dll filetype 1 errors 1, no dir
>>>>>>>>>> item
>>>>>>>>>
>>>>>>>>> I've tried everything I've found suggested including a full
>>>>>>>>> scrub, balance with -dusage=75 -musage=75, resetting file
>>>>>>>>> attributes, deleting through the find command, and even some
>>>>>>>>> repair mount flags that don't seem to exist for btrfs.
>>>>>>>>
>>>>>>>> The fs is corrupted, thus none of those will help.
>>>>>>>> I'm more interested in how the corruption happened.
>>>>>>>>
>>>>>>>> Did you use some tools other than btrfs kernel module and
>>>>>>>> btrfs- progs?
>>>>>>>> Like ntfs2btrfs or winbtrfs?
>>>>>>>>
>>>>>>>> IIRC certain versions have some bugs related to extent tree,
>>>>>>>> but should not cause this problem.
>>>>>>>>
>>>>>>>>
>>>>>>>> The other possibility is hardware memory bitflip, which is more
>>>>>>>> common than you thought (almostly one report per month)
>>>>>>>>
>>>>>>>> In that case, a full memtest is always recommended, or you will
>>>>>>>> hit all kinds of weird corruptions in the future anyway.
>>>>>>>>
>>>>>>>>
>>>>>>>> With a full memtest proving the memory hardware is fine, then
>>>>>>>> "btrfs check --repair" should be able to fix it.
>>>>>>>>
>>>>>>>> Thanks,
>>>>>>>> Qu
>>>>>>>>
>>>>>>>>
>>>>>>>>> What I haven't tried is a full rebalance with no filters, but
>>>>>>>>> I did not try that yet as it would take quite a long time and
>>>>>>>>> if it only moves data blocks around without recomputing
>>>>>>>>> directory items, it doesn't seem like the right tool to fix my
>>>>>>>>> problem. So I'm pretty much stuck and to me it seems like my
>>>>>>>>> only option is to run btrfs check with the repair flag, but as
>>>>>>>>> that has big warnings on it I thought I would try asking here
>>>>>>>>> first (sorry if this is not the right experts group to ask).
>>>>>>>>> So is there still something I can try or am I finally
>>>>>>>>> "allowed" to use the repair command? Here's the full output I
>>>>>>>>> got from btrfs check:
>>>>>>>>>
>>>>>>>>>> Opening filesystem to check...
>>>>>>>>>> Checking filesystem on /dev/sdc
>>>>>>>>>> UUID: 2b4ad16d-e456-4adf-960b-dca43560b98b
>>>>>>>>>> [1/8] checking log skipped (none written)
>>>>>>>>>> [2/8] checking root items
>>>>>>>>>> [3/8] checking extents
>>>>>>>>>> [4/8] checking free space tree
>>>>>>>>>> We have a space info key for a block group that doesn't exist
>>>>>>>>>> [5/8] checking fs roots
>>>>>>>>>> root 5 inode 25953213 errors 200, dir isize wrong
>>>>>>>>>> root 5 inode 27166085 errors 2000, link count wrong
>>>>>>>>>> unresolved ref dir 25953213 index 7 namelen 33 name
>>>>>>>>>> Microsoft.AspNetCore.Metadata.dll filetype 1 errors 1, no dir
>>>>>>>>>> item
>>>>>>>>>> root 14428 inode 25953213 errors 200, dir isize wrong
>>>>>>>>>> root 14428 inode 27166085 errors 2000, link count wrong
>>>>>>>>>> unresolved ref dir 25953213 index 7 namelen 33 name
>>>>>>>>>> Microsoft.AspNetCore.Metadata.dll filetype 1 errors 1, no dir
>>>>>>>>>> item
>>>>>>>>>> root 14451 inode 25953213 errors 200, dir isize wrong
>>>>>>>>>> root 14451 inode 27166085 errors 2000, link count wrong
>>>>>>>>>> unresolved ref dir 25953213 index 7 namelen 33 name
>>>>>>>>>> Microsoft.AspNetCore.Metadata.dll filetype 1 errors 1, no dir
>>>>>>>>>> item
>>>>>>>>>> root 14475 inode 25953213 errors 200, dir isize wrong
>>>>>>>>>> root 14475 inode 27166085 errors 2000, link count wrong
>>>>>>>>>> unresolved ref dir 25953213 index 7 namelen 33 name
>>>>>>>>>> Microsoft.AspNetCore.Metadata.dll filetype 1 errors 1, no dir
>>>>>>>>>> item
>>>>>>>>>> root 14499 inode 25953213 errors 200, dir isize wrong
>>>>>>>>>> root 14499 inode 27166085 errors 2000, link count wrong
>>>>>>>>>> unresolved ref dir 25953213 index 7 namelen 33 name
>>>>>>>>>> Microsoft.AspNetCore.Metadata.dll filetype 1 errors 1, no dir
>>>>>>>>>> item
>>>>>>>>>> root 14523 inode 25953213 errors 200, dir isize wrong
>>>>>>>>>> root 14523 inode 27166085 errors 2000, link count wrong
>>>>>>>>>> unresolved ref dir 25953213 index 7 namelen 33 name
>>>>>>>>>> Microsoft.AspNetCore.Metadata.dll filetype 1 errors 1, no dir
>>>>>>>>>> item
>>>>>>>>>> root 14544 inode 25953213 errors 200, dir isize wrong
>>>>>>>>>> root 14544 inode 27166085 errors 2000, link count wrong
>>>>>>>>>> unresolved ref dir 25953213 index 7 namelen 33 name
>>>>>>>>>> Microsoft.AspNetCore.Metadata.dll filetype 1 errors 1, no dir
>>>>>>>>>> item
>>>>>>>>>> root 14545 inode 25953213 errors 200, dir isize wrong
>>>>>>>>>> root 14545 inode 27166085 errors 2000, link count wrong
>>>>>>>>>> unresolved ref dir 25953213 index 7 namelen 33 name
>>>>>>>>>> Microsoft.AspNetCore.Metadata.dll filetype 1 errors 1, no dir
>>>>>>>>>> item
>>>>>>>>>> root 14546 inode 25953213 errors 200, dir isize wrong
>>>>>>>>>> root 14546 inode 27166085 errors 2000, link count wrong
>>>>>>>>>> unresolved ref dir 25953213 index 7 namelen 33 name
>>>>>>>>>> Microsoft.AspNetCore.Metadata.dll filetype 1 errors 1, no dir
>>>>>>>>>> item
>>>>>>>>>> root 14547 inode 25953213 errors 200, dir isize wrong
>>>>>>>>>> root 14547 inode 27166085 errors 2000, link count wrong
>>>>>>>>>> unresolved ref dir 25953213 index 7 namelen 33 name
>>>>>>>>>> Microsoft.AspNetCore.Metadata.dll filetype 1 errors 1, no dir
>>>>>>>>>> item
>>>>>>>>>> root 14548 inode 25953213 errors 200, dir isize wrong
>>>>>>>>>> root 14548 inode 27166085 errors 2000, link count wrong
>>>>>>>>>> unresolved ref dir 25953213 index 7 namelen 33 name
>>>>>>>>>> Microsoft.AspNetCore.Metadata.dll filetype 1 errors 1, no dir
>>>>>>>>>> item
>>>>>>>>>> root 14549 inode 25953213 errors 200, dir isize wrong
>>>>>>>>>> root 14549 inode 27166085 errors 2000, link count wrong
>>>>>>>>>> unresolved ref dir 25953213 index 7 namelen 33 name
>>>>>>>>>> Microsoft.AspNetCore.Metadata.dll filetype 1 errors 1, no dir
>>>>>>>>>> item
>>>>>>>>>> root 14550 inode 25953213 errors 200, dir isize wrong
>>>>>>>>>> root 14550 inode 27166085 errors 2000, link count wrong
>>>>>>>>>> unresolved ref dir 25953213 index 7 namelen 33 name
>>>>>>>>>> Microsoft.AspNetCore.Metadata.dll filetype 1 errors 1, no dir
>>>>>>>>>> item
>>>>>>>>>> ERROR: errors found in fs roots
>>>>>>>>>> found 49400296812544 bytes used, error(s) found
>>>>>>>>>> total csum bytes: 48179330432
>>>>>>>>>> total tree bytes: 65067483136
>>>>>>>>>> total fs tree bytes: 12107431936
>>>>>>>>>> total extent tree bytes: 3194437632
>>>>>>>>>> btree space waste bytes: 4558984171
>>>>>>>>>> file data blocks allocated: 76487982252032
>>>>>>>>>> referenced 60030799097856
>>>>>>>>>
>>>>>>>>> So hopefully if I'm reading things right, running a repair
>>>>>>>>> would delete just that one file and directory (which itself is
>>>>>>>>> a backup so I will not miss that file at all)?
>>>>>>>>>
>>>>>>>>> I do not have enough disk space to copy off the entire
>>>>>>>>> filesystem and rebuild from scratch, without doing something
>>>>>>>>> like rebalancing all data from raid10 to single and then
>>>>>>>>> removing half the disks, but I assume that would take at least
>>>>>>>>> 4 weeks to process (as I just replaced a disk which took like
>>>>>>>>> a week).
>>>>>>>>>
>>>>>>>>> As to what originally caused the corruption, I think it was
>>>>>>>>> probably faulty RAM, because up to to like 3 weeks ago I had
>>>>>>>>> one really bad RAM stick in my computer where a certain memory
>>>>>>>>> region always had incorrectly reading bytes. I had seen
>>>>>>>>> intermittent quite high csum errors in monthly scrubs pretty
>>>>>>>>> randomly, which thankfully could almost always be corrected so
>>>>>>>>> I didn't have any major problems even though I had like
>>>>>>>>> totally broken RAM in my computer for who knows how long. So
>>>>>>>>> btrfs was able to protect my data quite impressively from bad
>>>>>>>>> RAM.
>>>>>>>>>
>>>>>>>>> Sorry for getting a bit sidetracked there, but what should I
>>>>>>>>> do in this situation?
>>>>>>>>>
>>>>>>>>> - Henri Hyyryläinen
>>>>>>>>>
>>>>>>>>>
>>>>>>>>
>>>>>>
>>>>>>
>>>>>
>>>
>>
>
next prev parent reply other threads:[~2025-10-05 8:20 UTC|newest]
Thread overview: 13+ messages / expand[flat|nested] mbox.gz Atom feed top
2025-09-29 17:11 How to remove an unremovable file and directory? Henri Hyyryläinen
2025-09-29 21:52 ` Qu Wenruo
2025-09-30 8:13 ` Henri Hyyryläinen
2025-10-04 17:43 ` Henri Hyyryläinen
2025-10-04 20:44 ` Qu Wenruo
2025-10-04 20:55 ` Qu Wenruo
2025-10-04 21:53 ` Henri Hyyryläinen
2025-10-04 22:07 ` Qu Wenruo
2025-10-04 22:36 ` Henri Hyyryläinen
2025-10-04 22:41 ` Qu Wenruo
2025-10-05 8:20 ` Henri Hyyryläinen [this message]
2025-10-05 8:37 ` Qu Wenruo
2025-10-05 10:44 ` Henri Hyyryläinen
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=e34577ac-3b2a-4fc8-8d04-b06f9b70cc5b@gmail.com \
--to=henri.hyyrylainen@gmail.com \
--cc=linux-btrfs@vger.kernel.org \
--cc=quwenruo.btrfs@gmx.com \
--cc=wqu@suse.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
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox