BtrFS ошибка incorrect extent count в dmesg [РЕШЕНО]

Атв smart что происходит?

sudo smartctl -a /dev/sdb
[sudo] пароль для dna: 
smartctl 7.2 2020-12-30 r5155 [x86_64-linux-5.11.7-139-tkg-pds] (local build)
Copyright (C) 2002-20, Bruce Allen, Christian Franke, www.smartmontools.org

=== START OF INFORMATION SECTION ===
Model Family:     Seagate Barracuda 7200.14 (AF)
Device Model:     ST500DM002-1BD142
Serial Number:    Z6E7TMPK
LU WWN Device Id: 5 000c50 0676ee9a1
Firmware Version: KC45
User Capacity:    500 107 862 016 bytes [500 GB]
Sector Sizes:     512 bytes logical, 4096 bytes physical
Rotation Rate:    7200 rpm
Device is:        In smartctl database [for details use: -P show]
ATA Version is:   ATA8-ACS T13/1699-D revision 4
SATA Version is:  SATA 3.0, 6.0 Gb/s (current: 6.0 Gb/s)
Local Time is:    Tue Apr  6 00:43:06 2021 +06
SMART support is: Available - device has SMART capability.
SMART support is: Enabled

=== START OF READ SMART DATA SECTION ===
SMART overall-health self-assessment test result: PASSED

General SMART Values:
Offline data collection status:  (0x82) Offline data collection activity
                                        was completed without error.
                                        Auto Offline Data Collection: Enabled.
Self-test execution status:      (   0) The previous self-test routine completed
                                        without error or no self-test has ever 
                                        been run.
Total time to complete Offline 
data collection:                (  600) seconds.
Offline data collection
capabilities:                    (0x7b) SMART execute Offline immediate.
                                        Auto Offline data collection on/off support.
                                        Suspend Offline collection upon new
                                        command.
                                        Offline surface scan supported.
                                        Self-test supported.
                                        Conveyance Self-test supported.
                                        Selective Self-test supported.
SMART capabilities:            (0x0003) Saves SMART data before entering
                                        power-saving mode.
                                        Supports SMART auto save timer.
Error logging capability:        (0x01) Error logging supported.
                                        General Purpose Logging supported.
Short self-test routine 
recommended polling time:        (   1) minutes.
Extended self-test routine
recommended polling time:        (  84) minutes.
Conveyance self-test routine
recommended polling time:        (   2) minutes.
SCT capabilities:              (0x303f) SCT Status supported.
                                        SCT Error Recovery Control supported.
                                        SCT Feature Control supported.
                                        SCT Data Table supported.

SMART Attributes Data Structure revision number: 10
Vendor Specific SMART Attributes with Thresholds:
ID# ATTRIBUTE_NAME          FLAG     VALUE WORST THRESH TYPE      UPDATED  WHEN_FAILED RAW_VALUE
  1 Raw_Read_Error_Rate     0x000f   111   099   006    Pre-fail  Always       -       34020256
  3 Spin_Up_Time            0x0003   100   098   000    Pre-fail  Always       -       0
  4 Start_Stop_Count        0x0032   098   098   020    Old_age   Always       -       2607
  5 Reallocated_Sector_Ct   0x0033   100   100   036    Pre-fail  Always       -       0
  7 Seek_Error_Rate         0x000f   073   060   030    Pre-fail  Always       -       25915595373
  9 Power_On_Hours          0x0032   091   091   000    Old_age   Always       -       8563
 10 Spin_Retry_Count        0x0013   100   100   097    Pre-fail  Always       -       0
 12 Power_Cycle_Count       0x0032   098   098   020    Old_age   Always       -       2247
183 Runtime_Bad_Block       0x0032   100   100   000    Old_age   Always       -       0
184 End-to-End_Error        0x0032   100   100   099    Old_age   Always       -       0
187 Reported_Uncorrect      0x0032   100   100   000    Old_age   Always       -       0
188 Command_Timeout         0x0032   100   100   000    Old_age   Always       -       0 0 0
189 High_Fly_Writes         0x003a   100   100   000    Old_age   Always       -       0
190 Airflow_Temperature_Cel 0x0022   066   057   045    Old_age   Always       -       34 (0 10 34 22 0)
194 Temperature_Celsius     0x0022   034   043   000    Old_age   Always       -       34 (128 0 0 0 0)
195 Hardware_ECC_Recovered  0x001a   053   039   000    Old_age   Always       -       34020256
197 Current_Pending_Sector  0x0012   100   100   000    Old_age   Always       -       0
198 Offline_Uncorrectable   0x0010   100   100   000    Old_age   Offline      -       0
199 UDMA_CRC_Error_Count    0x003e   200   200   000    Old_age   Always       -       2
240 Head_Flying_Hours       0x0000   100   253   000    Old_age   Offline      -       8604h+44m+13.849s
241 Total_LBAs_Written      0x0000   100   253   000    Old_age   Offline      -       1823685135
242 Total_LBAs_Read         0x0000   100   253   000    Old_age   Offline      -       2962128783

SMART Error Log Version: 1
No Errors Logged

SMART Self-test log structure revision number 1
Num  Test_Description    Status                  Remaining  LifeTime(hours)  LBA_of_first_error
# 1  Short offline       Completed without error       00%      8563         -
# 2  Short offline       Completed without error       00%      7725         -

SMART Selective self-test log data structure revision number 1
 SPAN  MIN_LBA  MAX_LBA  CURRENT_TEST_STATUS
    1        0        0  Not_testing
    2        0        0  Not_testing
    3        0        0  Not_testing
    4        0        0  Not_testing
    5        0        0  Not_testing
Selective self-test flags (0x0):
  After scanning selected spans, do NOT read-scan remainder of disk.
If Selective self-test is pending on power-up, resume after 0 minute delay.

Я не шибко понимаю что пишет Смарт, но DislMonitorNotifer пишет что все ОК.

Диск выглядит живым. Однако 199 UDMA_CRC_Error_Count возможно имеет связь с этим сообщением. Рекомендую понаблюдать за этим и за тем будет ли появляться ещё такое сообщение в dmesg. Но переживать скорее всего не о чем. ЗЫ я бы саташный шлейф заменил ко всем чертям при такой картинке, ну так на всякий случай.

Спроси в IRC. Можешь снять образ и попробовать btrfs check --repair --init-extent-tree.

erfea — смарт ни при чём от слова совсем. При вылете или ошибке диска ты поймаешь несовпадение чексумм, а не высокоуровневую логическую проблему.

Я бы не был так категоричен. Что означает «incorrect extent count» подозреваю Вы, товарищ, тоже не можете точно сказать. А вот 199 в смарте на лицо. И это штука более или менее понятная, ошибка передачи данных, от неё каких только чудес не случается. Не понятно только когда она была и есть ли связь между этими событиями.

Сама ФС работает как всегда

А не должна. Хорошо бы еще выяснить, какая из 4 функций пишет это в лог. А так – присоединяюсь к intelfx. --repair на образе/копии, а если важны данные, то попробовать сделать бекап(если вы их еще не делаете), смонтировав ФС в ro.

А вот 199 в смарте на лицо.

2 ошибки UDMA_CRC_Error_Count за 8563 часов - по вашему это проблемма? а 199 - это номер теста в списке.

У Вас может и не проблема, у меня 0 на всей технике что обслуживаю. 199 - это не 197 чтобы паниковать, но это ошибка и не имеющая права присутствовать в исправной технике. А главное что не понятно когда она возникла, может она ещё в начале жизни диска была.

А не должна

Это почему?

Хорошо бы еще выяснить, какая из 4 функций пишет это в лог.

А вот главный вопрос «пишет в лог» или это разовая акция. Я ТС понял что там одно сообщение.

И это штука более или менее понятная, ошибка передачи данных, от неё каких только чудес не случается.

Вот именно, что чудес. Какова вероятность того, что в ходе ошибки передачи данных сгенерируется искажённый, но валидный блок метаданных, и заодно искажённая, но подходящая чексумма (которая вообще хранится в другом месте диска, если я правильно помню диск формат btrfs)?

Посмотрел в код.

ТС, пересобери space cache и заодно переключись на space tree — оно защищено CoW-механизмом, а битмапы нет.

mount /path/to/filesystem -o remount,clear_cache,space_cache=v2

Где /path/to/filesystem — путь до точки монтирования твоего sdb5.

И покажи сразу после этого лог ядра (journalctl -k -e -n50).

Что означает incorrect extent count и при каком сценарии драйвер btrfs это мог выдать? При чём тут чексума? Мне видится что он мог отловить от ведра ошибку, выплюнуть в лог сообщение и продолжить корректно работать. Что со сценарием 199 по смарту бьётся вполне. Вопрос в том что это разовая акция или у ТС это рисуется в логе регулярно.

Что означает incorrect extent count и при каком сценарии драйвер btrfs это мог выдать?

Ну я только что посмотрел. Повреждение free space cache v1.

При чём тут чексума?

При том, что внутри btrfs все данные, хранимые на диске, защищены чексуммами (кроме случаев, когда они явно выключены, но это не тот случай).

free space cache v1
данные, хранимые на диске, защищены чексуммами.

???

???

Что?

Ну то что я не думаю что чексумы это про кеш свободного места ) В любом случае, рецепт по ремонту кеша выше Вы дали верный. Раз уж сообщение оттуда, думаю, можно считать вопрос закрытым.

Я бы таки сначала посмотрел, какая функция вызывает это.

И да, главный совет – бекап. Хотя и с исходной ФС поиграться было бы интересно: уж больно редкая и необычная ошибка.

Бекап должен быть и без советов, полностью согласен. Ну а по функции тут товарищ чуть повыше не поленился откопал, дал правильный рецепт ремонта.

Перемонтировал. <<<

journalctl -k -e -n50
апр 07 23:58:16 NeGenadyi kernel: amdgpu 0000:09:00.0: amdgpu: ring vcn_dec uses VM inv eng 1 on hub>
апр 07 23:58:16 NeGenadyi kernel: amdgpu 0000:09:00.0: amdgpu: ring vcn_enc0 uses VM inv eng 4 on hu>
апр 07 23:58:16 NeGenadyi kernel: amdgpu 0000:09:00.0: amdgpu: ring vcn_enc1 uses VM inv eng 5 on hu>
апр 07 23:58:16 NeGenadyi kernel: amdgpu 0000:09:00.0: amdgpu: ring jpeg_dec uses VM inv eng 6 on hu>
апр 07 23:58:16 NeGenadyi kernel: [drm] Initialized amdgpu 3.40.0 20150101 for 0000:09:00.0 on minor>
апр 07 23:58:17 NeGenadyi kernel: BTRFS info (device sdc2): cleaning free space cache v1
апр 07 23:58:17 NeGenadyi kernel: BTRFS info (device sdc2): checking UUID tree
апр 07 23:58:17 NeGenadyi kernel: Adding 5242876k swap on /mnt/Disk_D/Swap/swapfile1.  Priority:10 e>
апр 07 23:58:28 NeGenadyi kernel: Generic FE-GE Realtek PHY r8169-800:00: attached PHY driver (mii_b>
апр 07 23:58:28 NeGenadyi kernel: r8169 0000:08:00.0 enp8s0: Link is Down
апр 08 00:04:18 NeGenadyi kernel: wlp9s0f4u1: authenticate with 90:f0:52:76:40:a3
апр 08 00:04:18 NeGenadyi kernel: wlp9s0f4u1: send auth to 90:f0:52:76:40:a3 (try 1/3)
апр 08 00:04:18 NeGenadyi kernel: wlp9s0f4u1: authenticated
апр 08 00:04:18 NeGenadyi kernel: wlp9s0f4u1: associate with 90:f0:52:76:40:a3 (try 1/3)
апр 08 00:04:18 NeGenadyi kernel: wlp9s0f4u1: RX AssocResp from 90:f0:52:76:40:a3 (capab=0x8431 stat>
апр 08 00:04:18 NeGenadyi kernel: wlp9s0f4u1: associated
апр 08 00:04:18 NeGenadyi kernel: IPv6: ADDRCONF(NETDEV_CHANGE): wlp9s0f4u1: link becomes ready
апр 08 00:13:39 NeGenadyi kernel: mt7601u 5-1:1.0: Warning: mt7601u_mcu_wait_resp retrying
апр 08 00:13:39 NeGenadyi kernel: mt7601u 5-1:1.0: Warning: mt7601u_mcu_wait_resp retrying
апр 08 00:13:40 NeGenadyi kernel: mt7601u 5-1:1.0: Warning: mt7601u_mcu_wait_resp retrying
апр 08 00:13:40 NeGenadyi kernel: mt7601u 5-1:1.0: Warning: mt7601u_mcu_wait_resp retrying
апр 08 00:14:34 NeGenadyi kernel: BTRFS error (device sdb5): incorrect extent count for 141764329472>
апр 08 00:14:34 NeGenadyi kernel: BTRFS error (device sdb5): incorrect extent count for 329669148672>
апр 08 00:14:34 NeGenadyi kernel: BTRFS error (device sdb5): incorrect extent count for 322152955904>
апр 08 00:28:36 NeGenadyi kernel: BTRFS info (device sdb5): max_inline at 256
апр 08 00:28:36 NeGenadyi kernel: BTRFS info (device sdb5): force clearing of disk cache
апр 08 00:28:36 NeGenadyi kernel: BTRFS info (device sdb5): using free space tree

defaults,max_inline=256,noatime,space_cache=v2,autodefrag,compress=zstd:15 0 0

Ну, сообщение о битых экстентах появляются каждый раз при записи на этот диск. Всего таких экстентов 3:

[ 1000.927343] BTRFS error (device sdb5): incorrect extent count for 141764329472; counted 36, expected 37
[ 1000.960058] BTRFS error (device sdb5): incorrect extent count for 329669148672; counted 49, expected 50
[ 1000.960070] BTRFS error (device sdb5): incorrect extent count for 322152955904; counted 3, expected 4

Пишет каждый раз про одни и те же экстенты (что собственно ожидаемо).

А btrfs check –repair –init-extent-tree Данные не навернет? Бекапиться сейчас банально некуда.

Перемонтировал

Помогло же?

У меня и так в Fstab...

Не тоже самое, вся магия в опции clear_cache. Не добавляй только в fstab.

А btrfs check –repair –init-extent-tree Данные не навернет?

Не стоит этого делать. Проблема, как выяснил товарищ выше, в другом.

Бекапиться сейчас банально некуда.

Бекап важной информации должен быть банально всегда.

Поглядывай иногда на 199 в smart. Не понятно откуда там 2 взялось, если однажды подрастёт, замени шлейф.

Помогло же?

Нет. Те же, три поврежденных экстента.

Не тоже самое,…

Я к тому, что у меня и так cache v2

Бекап важной информации должен быть банально всегда.

Это-то понятно, но «маемо шо маемо».

А нет способа «изолировать» кривые экстенты? Бэд-блоки же изолируют что бы система на них не писала.

Нет. Те же, три поврежденных экстента.

Грусть.

Я к тому, что у меня и так cache v2

Не в версии дело, а в том чтобы его перестроить. Почитай последний, выложеный, dmesg: force clearing of disk cache.

А нет способа «изолировать» кривые экстенты? Бэд-блоки же изолируют что бы система на них не писала.

Не знаю такого. А вот погонять бы диск в виктории не мешало. В любом случае считаю необходимым делать бекап если данные нужны. А там уже разбираться. Я бы прогнал в виктории, если проблем нет, тупо форматнул бы.

А нет способа «изолировать» кривые экстенты? Бэд-блоки же изолируют что бы система на них не писала.

У тебя нет кривых экстентов. Система жалуется на счётчик экстентов в блокгруппе.

И это всё очень странно. Во-первых, странно, что очистка free space cache не помогла, т. к. это сообщение встречается в коде btrfs только два раза, и оба в подсистеме free space cache v1. А во-вторых, у тебя используется v2.

Попробуй отмонтировать и примонтировать с опциями -o clear_cache,nospace_cache. Не ремаунтом, а именно примонтировать с нуля.

Но вообще я хз.

А вот это, кажется помогло. Погоняю пару дней под нагрузкой и если все нормально - помечу тему как РЕШЕНО.

Спасибо всем кто откликнулся!

оба в подсистеме free space cache v1

4 раза. И в обеих.

Странно, очень. Доктор, а откуда у вас такие картинки? ТС, а что у вас за ядро? uname -a

Сейчас 5.11.11-xanmod1, до этого было linux-tkg-pds-zen (вроде бы на нем и вылезла ошибка).

Вот и причина.

1. Делайте бекап. Кривое ядро могло испортить фс. +хз, что еще в нем сломано.
2. Никогда не ставье левые ядра, которые никто не поддерживает.

Сейчас 5.11.11-xanmod1, до этого было linux-tkg-pds-zen (вроде бы на нем и вылезла ошибка).

Что это за калище? Кто посоветовал это ставить?

Так-то их вполне поддерживают. ФС врядли побилась, scrub и btrfsck ошибок на ней не видят.

В стандартном ядре увы нет fsync (который futex) и планировщика pds.

Можешь исправить опечатку в названии темы?

?

В заголовке — «RtrFS» вместо «BtrFS». Под сообщением должна быть ссылка «Править».

И правда. Спасибо, не заметил.