LINUX.ORG.RU
ФорумAdmin

Посыпался Samsung SSD 870 QVO 2TB

 , ,


0

4

Пишу из горящего танка. Комп внезапно перезагрузился во время активной записи на диск. В журнале ошибки:

июн 21 18:10:37 abc kernel: BTRFS warning (device sda1): csum failed root 318 ino 39231141 off 105160704 csum 0x75d6d775 expected csum 0x4a24269a mirror 1
июн 21 18:10:37 abc kernel: BTRFS error (device sda1): bdev /dev/sda1 errs: wr 0, rd 0, flush 0, corrupt 1, gen 0
июн 21 18:10:37 abc kernel: BTRFS warning (device sda1): csum failed root 318 ino 39231141 off 105164800 csum 0x8298fde5 expected csum 0x2d726d5d mirror 1

Выкидывать его или забить и продолжить использовать пока совсем плохо не станет? После перезагрузки пока что работает. Как узнать на каком файле произошла ошибка? trim регулярно запускается.

P.S. на этом диске у меня swap

P.S. P.S.

uname -a
Linux abc 6.3.4-arch1-1 #1 SMP PREEMPT_DYNAMIC Wed, 24 May 2023 17:44:00 +0000 x86_64 GNU/Linux

sudo smartctl -a /dev/sda              
smartctl 7.3 2022-02-28 r5338 [x86_64-linux-6.3.4-arch1-1] (local build)
Copyright (C) 2002-22, Bruce Allen, Christian Franke, www.smartmontools.org

=== START OF INFORMATION SECTION ===
Model Family:     Samsung based SSDs
Device Model:     Samsung SSD 870 QVO 2TB
Serial Number:    S5SUNF0NC11331N
LU WWN Device Id: 5 002538 f40c044dd
Firmware Version: SVQ01B6Q
User Capacity:    2 000 398 934 016 bytes [2,00 TB]
Sector Size:      512 bytes logical/physical
Rotation Rate:    Solid State Device
Form Factor:      2.5 inches
TRIM Command:     Available, deterministic, zeroed
Device is:        In smartctl database 7.3/5319
ATA Version is:   ACS-4 T13/BSR INCITS 529 revision 5
SATA Version is:  SATA 3.3, 6.0 Gb/s (current: 6.0 Gb/s)
Local Time is:    Wed Jun 21 18:12:46 2023 MSK
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:  (0x00) Offline data collection activity
                                        was never started.
                                        Auto Offline Data Collection: Disabled.
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:                (    0) seconds.
Offline data collection
capabilities:                    (0x53) SMART execute Offline immediate.
                                        Auto Offline data collection on/off support.
                                        Suspend Offline collection upon new
                                        command.
                                        No Offline surface scan supported.
                                        Self-test supported.
                                        No 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:        (   2) minutes.
Extended self-test routine
recommended polling time:        ( 160) minutes.
SCT capabilities:              (0x003d) SCT Status supported.
                                        SCT Error Recovery Control supported.
                                        SCT Feature Control supported.
                                        SCT Data Table supported.

SMART Attributes Data Structure revision number: 1
Vendor Specific SMART Attributes with Thresholds:
ID# ATTRIBUTE_NAME          FLAG     VALUE WORST THRESH TYPE      UPDATED  WHEN_FAILED RAW_VALUE
  5 Reallocated_Sector_Ct   0x0033   100   100   010    Pre-fail  Always       -       0
  9 Power_On_Hours          0x0032   097   097   000    Old_age   Always       -       11228
 12 Power_Cycle_Count       0x0032   099   099   000    Old_age   Always       -       525
177 Wear_Leveling_Count     0x0013   099   099   000    Pre-fail  Always       -       10
179 Used_Rsvd_Blk_Cnt_Tot   0x0013   100   100   010    Pre-fail  Always       -       0
181 Program_Fail_Cnt_Total  0x0032   100   100   010    Old_age   Always       -       0
182 Erase_Fail_Count_Total  0x0032   100   100   010    Old_age   Always       -       0
183 Runtime_Bad_Block       0x0013   100   100   010    Pre-fail  Always       -       0
187 Uncorrectable_Error_Cnt 0x0032   100   100   000    Old_age   Always       -       0
190 Airflow_Temperature_Cel 0x0032   063   042   000    Old_age   Always       -       37
195 ECC_Error_Rate          0x001a   200   200   000    Old_age   Always       -       0
199 CRC_Error_Count         0x003e   100   100   000    Old_age   Always       -       0
235 POR_Recovery_Count      0x0012   099   099   000    Old_age   Always       -       30
241 Total_LBAs_Written      0x0032   099   099   000    Old_age   Always       -       40050852631

SMART Error Log Version: 1
No Errors Logged

SMART Self-test log structure revision number 1
No self-tests have been logged.  [To run self-tests, use: smartctl -t]

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
  256        0    65535  Read_scanning was never started
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.
★★★★★

Последнее исправление: ox55ff (всего исправлений: 1)
Ответ на: комментарий от MoldAndLimeHoney

Ну если котиков в интернете лайкать, то никогда не возникнет. А я гоняю алгоритмы видеообработки и легко могу выжрать весь объём. У меня 64 ГБ ОЗУ + 20 ГБ своп.

ox55ff ★★★★★
() автор топика
Ответ на: комментарий от Exmor_RS

Брехня. Подтормаживания - да, но не колом. И я успеваю убить жрущий процесс. Без свопа пришлось бы жать сброс. На OOM надежды нет. У меня нет времени ждать 20 минут когда он соизволит убить процесс.

ox55ff ★★★★★
() автор топика
Ответ на: комментарий от ox55ff

У меня нет времени ждать 20 минут когда он соизволит убить процесс.

Ух ты какой занятой!

Брехня.

Нет.
А вот ты сталкивался лишь с самыми простейшими случаями.
В линуксе ПЛОХОЙ дизайн работы с памятью.
Из-за этого возможен такой бред в 2023 году, при наличии порой десятков гигабайт ОЗУ.

Тебе самому-то НЕ КРИНЖОВО выполнять роль КОСТЫЛЯ мониторящего ОЗУ?

А вообще попробуй https://github.com/hakavlad/prelockd / nohang
ну и zramswap конечно

Exmor_RS ★★★
()
Последнее исправление: Exmor_RS (всего исправлений: 1)
Ответ на: комментарий от MoldAndLimeHoney

Зачем вообще своп в 2k23?

Как там в будущем?

Есть какие-то причины, чтобы его создавать?

Да. Мозги могут закончится не обращая внимания на календарную дату.

anc ★★★★★
()
Ответ на: комментарий от Exmor_RS

У меня как раз граблей нет. Это вы отчего то начали рекламировать всякие zswap и ко. Возможно травмирующий опыт в прошлом. Не понятно почему вы на меня его проецируете.

ox55ff ★★★★★
() автор топика
Ответ на: комментарий от anc

Такое число (100) или больше, если используют zram или своп на быстром диске, типа SSD.

Обсуждалось много раз на страницах ЛОРа, надо искать.

krasnh ★★★★
()
Последнее исправление: krasnh (всего исправлений: 2)
Ответ на: комментарий от krasnh

На самом деле все эти виляния жёпой в sysctl + swappines не играют особой роли.
Если начнётся хеви-своппинг и ты прозеваешь момент, то система встанет раком/колом, т.к. у тебя банально важные либы выгрузятся в своп, формально кернел работать будет, но ты данные не сохранишь, в TTY не переключишься.

Удивительно, что такая картина на десктопах и серверах — на андроиде давно есть планировщики которые надёжно предохраняют сохранение отзывчивости системы.

Решение описал выше, особенно прелокд.

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

Exmor_RS ★★★
()
Ответ на: комментарий от anc

Нищеброды?

А swap кто использует? Богачи? Если у тебя кончилась РАМ, кончится и СВОП. В чем смысл? Если у тебя регулярно возникают задачи, когда кончается РАМ, наверное стоит обновить железо?

MoldAndLimeHoney
()
Ответ на: комментарий от Exmor_RS

особенно прелокд

prelockd >> le9 >> mglru. Ядро ≥ 6.1 (mglru).

Но на самом деле, то что пишет ТС, типа своп, чтобы вовремя заметить утечку памяти и пресечь, вот это точно устаревшие методы. С этим как раз и могли бы справиться «пользовательские oom-killer`s», типа nohang, earlyoom и подобных:

На OOM надежды нет. У меня нет времени ждать 20 минут когда он соизволит убить процесс.

krasnh ★★★★
()
Последнее исправление: krasnh (всего исправлений: 2)
Ответ на: комментарий от Exmor_RS

Вы описываете какой-то экстрим. Жили со свопом на древнем железе, так с чего бы на современном внезапно все колом должно встать? Хреново работать, это да, но не совсем же колом. Да и либы не выгрузятся, точнее это надо постараться с ограничением по мозгам, что бы до либ дошло.

anc ★★★★★
()
Ответ на: комментарий от MoldAndLimeHoney

А swap кто использует? Богачи?

Все кто с головой дружит.

Если у тебя кончилась РАМ, кончится и СВОП.

Ну в таком ключе и место на hdd можно приплести и возможности cpu в ущербность добавить.

anc ★★★★★
()
Ответ на: комментарий от krasnh

mglru

Ну вот в теме человек))

Надеюсь в будущем совсем всё хорошо это подружат с сигруппами (или как-то иначе).

пользовательские oom-killer`s

Они изначально не работают, просто как идея, такая же старпёрская хрень, придуманная на коленке.

Прелокд/мглру это не киллеры, а больше высокоуровневые менеджеры (раутеры если угодно) памяти.

Exmor_RS ★★★
()
Ответ на: комментарий от Exmor_RS

пользовательские oom-killer
Они изначально не работают, просто как идея

Наверно здесь возникло недопонимание в терминах userspace OOM-killer или я коряво высказался:

earlyoom — Simple userspace OOM-killer implementation written in C.

Там же и nohang:

nohang — Sophisticated OOM handler written in Python, with optional PSI support, more configurable than earlyoom.

krasnh ★★★★
()
Последнее исправление: krasnh (всего исправлений: 1)
Ответ на: комментарий от krasnh

Правильно ты высказался, просто я в целом все OOM считаю неверным решением проблемы.

Технически они конечно должны быть в системе, в качестве самой последней меры.

Сама проблема в другом: выгрузка важных либ при любом количестве ОЗУ, будь у тебя 4 или 1024ГБ — система всё равно начнёт их выгружать в своп — в 2019 (а сейчас вообще 2023) это бред и оскорбительный маразм.

Короче тут сигруппы и улучшенные менеджеры памяти решают, а не тупое киляние процессов.

Exmor_RS ★★★
()
Ответ на: комментарий от ox55ff

Без свопа пришлось бы жать сброс. На OOM надежды нет. У меня нет времени ждать 20 минут когда он соизволит убить процесс.

Достаточно просто нажать alt+sysrq+f (в Debian необходимо в /etc/sysctl.d/99-sysctl.conf подправить маску kernel.sysrq=..., у меня было 438, стало 502).

Год назад упоминал об этом в Когда линь перестанет виснуть при исчерпании памяти? (2022) (комментарий).

gag ★★★★★
()
Ответ на: комментарий от anc

ext2 более нативный для линукса.

Расскажите уж, чем он такой плохой? У меня только одна гипотеза - тем, что нет контрольных сумм на содержимое файлов. Но их можно навернуть внешним каталогизатором.

Shushundr ★★★★
()