LINUX.ORG.RU

Стали появляться проблемы с диском.

 , , ,


1

2

Уже второй раз (первый был несколько дней назад) возникают ошибки ФС и диск перемонтируется в ро:

[ 6974.205725] EXT4-fs error (device sda2): ext4_iget:4761: inode #7699735: comm TaskSchedulerFo: bad extra_isize 65535 (inode size 256)
[ 6974.210925] Aborting journal on device sda2-8.
[ 6974.213421] EXT4-fs (sda2): Remounting filesystem read-only
[ 6974.214980] EXT4-fs error (device sda2): ext4_journal_check_start:61: Detected aborted journal
[ 6995.041017] systemd-journald[281]: Failed to write entry (26 items, 852 bytes), ignoring: Read-only file system
[ 6995.041254] systemd-journald[281]: Failed to write entry (26 items, 835 bytes), ignoring: Read-only file system
[ 6995.041313] systemd-journald[281]: Failed to write entry (26 items, 1059 bytes), ignoring: Read-only file system
[ 6995.041364] systemd-journald[281]: Failed to write entry (26 items, 852 bytes), ignoring: Read-only file system
[ 6995.041599] systemd-journald[281]: Failed to write entry (26 items, 852 bytes), ignoring: Read-only file system
[ 6995.041652] systemd-journald[281]: Failed to write entry (26 items, 852 bytes), ignoring: Read-only file system
[ 6995.041715] systemd-journald[281]: Failed to write entry (26 items, 852 bytes), ignoring: Read-only file system

Диск:

> sudo hdparm -i /dev/sda
[sudo] пароль для alex: 

/dev/sda:

 Model=SanDisk SD8TB8U256G1001, FwRev=X4120101, SerialNo=170617804405
 Config={ }
 RawCHS=16383/16/63, TrkSize=0, SectSize=0, ECCbytes=0
 BuffType=unknown, BuffSize=unknown, MaxMultSect=1, MultSect=off
 (maybe): CurCHS=16383/16/63, CurSects=16514064, LBA=yes, LBAsects=500118192
 IORDY=on/off, tPIO={min:120,w/IORDY:120}, tDMA={min:120,rec:120}
 PIO modes:  pio0 pio1 pio2 pio3 pio4 
 DMA modes:  mdma0 mdma1 mdma2 
 UDMA modes: udma0 udma1 udma2 udma3 udma4 udma5 *udma6 
 AdvancedPM=yes: unknown setting WriteCache=enabled
 Drive conforms to: unknown:  ATA/ATAPI-4,5,6,7

 * signifies the current active mode

Сам я в этом смарте ничерта не понимаю:

> sudo smartctl -A /dev/sda 
smartctl 6.6 2016-05-31 r4324 [x86_64-linux-4.15.0-39-generic] (local build)
Copyright (C) 2002-16, Bruce Allen, Christian Franke, www.smartmontools.org

=== START OF READ SMART DATA SECTION ===
SMART Attributes Data Structure revision number: 4
Vendor Specific SMART Attributes with Thresholds:
ID# ATTRIBUTE_NAME          FLAG     VALUE WORST THRESH TYPE      UPDATED  WHEN_FAILED RAW_VALUE
  5 Reallocated_Sector_Ct   0x0032   100   100   ---    Old_age   Always       -       0
  9 Power_On_Hours          0x0032   100   100   ---    Old_age   Always       -       4435
 12 Power_Cycle_Count       0x0032   100   100   ---    Old_age   Always       -       460
170 Unknown_Attribute       0x0032   100   100   ---    Old_age   Always       -       0
171 Unknown_Attribute       0x0032   100   100   ---    Old_age   Always       -       0
172 Unknown_Attribute       0x0032   100   100   ---    Old_age   Always       -       0
173 Unknown_Attribute       0x0032   100   100   ---    Old_age   Always       -       7
174 Unknown_Attribute       0x0032   100   100   ---    Old_age   Always       -       96
178 Used_Rsvd_Blk_Cnt_Chip  0x0032   100   100   ---    Old_age   Always       -       0
180 Unused_Rsvd_Blk_Cnt_Tot 0x0033   100   100   010    Pre-fail  Always       -       100
184 End-to-End_Error        0x0033   100   100   097    Pre-fail  Always       -       0
187 Reported_Uncorrect      0x0032   100   100   ---    Old_age   Always       -       0
194 Temperature_Celsius     0x0022   067   048   ---    Old_age   Always       -       33 (Min/Max 13/48)
199 UDMA_CRC_Error_Count    0x0032   100   100   ---    Old_age   Always       -       0
233 Media_Wearout_Indicator 0x0033   098   100   001    Pre-fail  Always       -       16278028
234 Unknown_Attribute       0x0032   100   100   ---    Old_age   Always       -       4297
241 Total_LBAs_Written      0x0030   253   253   ---    Old_age   Offline      -       3367
242 Total_LBAs_Read         0x0030   253   253   ---    Old_age   Offline      -       5468
249 Unknown_Attribute       0x0032   100   100   ---    Old_age   Always       -       1973
Вот что это за End-to-End_Error? 97 это плохо да? Это может быть следствием проблем со шлейфом или это однозначно сам диск?

После перезагрузки система не грузится и просит fsck. После проверки начинает работать нормально.

UPD: Проблема проявляется на всех ядрах от 4.15 до 4.19 включительно.

Пока всегда только с диском /dev/sda2 (но он и используется интенсивнее). На данный момент диски смонтированы так:

UUID=27652258-937c-4be5-b12b-83ade6d5ff80	/               	ext4    errors=remount-ro,discard,commit=60		0       1
UUID=f1e0b59c-9f19-427c-acb2-f3f45d2eca55	/home/alex/misc         ext4    errors=remount-ro,noatime,discard	0       1
UUID=5667-4C56					/boot/efi       vfat    umask=0077			0       1
/home/alex/misc/swapfile			none            swap    sw				0       0

tmpfs						/tmp				tmpfs	rw,noatime,nosuid,mode=01777,size=2g						0	0
tmpfs						/var/tmp			tmpfs	rw,size=1g									0	0
tmpfs						/var/cache/apt/archives		tmpfs	rw,noatime,nosuid,size=1g							0	0
commit на /dev/sda2 и перенос swapfile на /dev/sda3 сделал недавно с целью увеличить интенсивность его использования и попробовадь получить ошибку на нем, чтобы убедится, что проблема свойственно железу или непосредственно дику, а не конкретному разделу.

Сервис Lenovo с помощью встроенного тестировния выявил неисправность планки RAM, которую надо сказать к чести Lenovo заменили в течении недели у меня на дому и мне даже не пришлось никуда ехать.

Тест железа встроенный прогнал 4 раза - никаких ошибок ниразу не вылезло. Следующим этапом по совету сервисника обновил BIOS (была и правда очень старая версия). Потом скачал SanDisk Dashboard и проверил диск им (пришлось венду на флэшку ради этого вкорячить), в том числе расширенное тестирование SMART. Прошивка диска последняя.

Проблема сохраняется.

UPD:
С момента переустановки прошел месяц. Полет нормальный. Нужно констатировать следующее - источником проблем стала оперативная память, что привело к повреждению данных записываемых на диск, а это в свою очередь повлекло все остальные последствия. Считаю что сервис Lenovo отработал оперативно - от момента обращение в чат, на сайте производителя, до замены планки памяти прошло 6 дней. Учитывая погодные условия и то что я не в ДС считаю это хорошей реакцией + мне не пришлось никуда ехать - специалист СЦ, приехал для выполнения работ ко мне, в тот же день когда в СЦ поступила деталь, не смотря на то, что к этому времени рабочий день уже завершился.

★★★★★

Последнее исправление: Suntechnic (всего исправлений: 4)
Ответ на: комментарий от Deleted

4.19 сейчас работает. невидия завелась. Но:

[    0.000000] microcode: microcode updated early to revision 0xc6, date = 2018-04-17
[    0.000000] Linux version 4.19.2-041902-generic (kernel@kathleen) (gcc version 8.2.0 (Ubuntu 8.2.0-9ubuntu1)) #201811132032 SMP Tue Nov 13 20:34:19 UTC 2018
[    0.000000] Command line: BOOT_IMAGE=/boot/vmlinuz-4.19.2-041902-generic root=UUID=27652258-937c-4be5-b12b-83ade6d5ff80 ro nopti pti=off spectre_v2=off
.............   
32.038756] EXT4-fs error (device sda2): ext4_iget:4851: inode #7660575: comm TaskSchedulerFo: checksum invalid
[   32.039292] Aborting journal on device sda2-8.
[   32.039909] EXT4-fs (sda2): Remounting filesystem read-only
[   32.040658] EXT4-fs error (device sda2): ext4_journal_check_start:61: Detected aborted journal
[   32.241053] EXT4-fs error (device sda2): ext4_iget:4851: inode #7660563: comm TaskSchedulerFo: checksum invalid
[   32.468527] EXT4-fs error (device sda2): ext4_iget:4851: inode #7660576: comm TaskSchedulerFo: checksum invalid
[   32.501245] EXT4-fs error (device sda2): ext4_iget:4831: inode #7660561: comm TaskSchedulerFo: bad extra_isize 254 (inode size 256)
[   32.515680] EXT4-fs error (device sda2): ext4_iget:4831: inode #7660566: comm TaskSchedulerFo: bad extra_isize 28271 (inode size 256)
[   32.520685] EXT4-fs error (device sda2): ext4_iget:4851: inode #7660572: comm TaskSchedulerFo: checksum invalid
[   32.635488] EXT4-fs error (device sda2): ext4_iget:4831: inode #7660568: comm TaskSchedulerFo: bad extra_isize 109 (inode size 256)
[   32.661495] EXT4-fs error (device sda2): ext4_iget:4851: inode #7660571: comm TaskSchedulerFo: checksum invalid
[   32.705044] EXT4-fs error (device sda2): ext4_iget:4851: inode #7660573: comm TaskSchedulerFo: checksum invalid
[   32.799552] EXT4-fs error (device sda2): ext4_iget:4831: inode #7660564: comm TaskSchedulerFo: bad extra_isize 30228 (inode size 256)
[   39.323980] kauditd_printk_skb: 34 callbacks suppressed
[   39.323982] audit: type=1400 audit(1542362050.708:46): apparmor="DENIED" operation="capable" profile="/usr/sbin/cupsd" pid=943 comm="cupsd" capability=12  capname="net_admin"
[  159.072614] systemd-journald[306]: Failed to write entry (21 items, 608 bytes), ignoring: Read-only file system
[  159.072742] systemd-journald[306]: Failed to write entry (21 items, 699 bytes), ignoring: Read-only file system
[  159.072846] systemd-journald[306]: Failed to write entry (21 items, 608 bytes), ignoring: Read-only file system
[  159.072957] systemd-journald[306]: Failed to write entry (21 items, 699 bytes), ignoring: Read-only file system
Так что дело похоже не в ядре.

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

На неделю не обязательно — можно на ночь поставить какой-нибудь intel iometer с паттерном ~50% записи, если что-то не так, он ФС попортит. А за неделю этот SSD можно в 0 ушатать хорошей нагрузкой.

И оно мне положит диск? Мне работать надо. Раньше вторника я в цивилизацию, чтобы купить новый, не попаду.

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

Основные подозреваемые — неоттестированное ядро и дешманское железо.
ТС просто заняться нечем
безымянный диск выбросил бы сразу
безымянный
SanDisk

Если бы все слушали таких, как ты - давно бы в мире уже армагеддец наступил.

По поводу ядра - он как раз проблему то и решит, скорее всего, установкой rc.

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

Как ДО текущей? М... кажется с этим же.

https://yadi.sk/i/FC6p_bHrqzvBlA
https://yadi.sk/i/gRdJeGohIHwyXw
https://yadi.sk/i/fl8DDBB9FogQ5g

> sudo smartctl -t long /dev/sda
[sudo] пароль для alex: 
smartctl 6.6 2016-05-31 r4324 [x86_64-linux-4.19.2-041902-generic] (local build)
Copyright (C) 2002-16, Bruce Allen, Christian Franke, www.smartmontools.org

=== START OF OFFLINE IMMEDIATE AND SELF-TEST SECTION ===
Sending command: "Execute SMART Extended self-test routine immediately in off-line mode".
Drive command "Execute SMART Extended self-test routine immediately in off-line mode" successful.
Testing has begun.
Please wait 10 minutes for test to complete.
Test will complete after Fri Nov 16 14:57:28 2018

Use smartctl -X to abort test.
Suntechnic ★★★★★
() автор топика
Ответ на: комментарий от Suntechnic

Имелось в виду, что, возможно, старое ядро испортило ФС.

Раз замены нет — то да, лучше тестированием не заниматься. Опасно.

anonymous
()
Ответ на: комментарий от Deleted

Мне работать надо
установкой rc

=))

anonymous
()
Ответ на: комментарий от Suntechnic

ФС падает за 32 секунды. Попробуйте загрузить нормальное ядро, сделать fsck, примонтировать и чрутнуться. Если через несколько минут не упадет — то, видимо, дело в ядре.

В любом случае, загружать систему с поврежденной ФС — опасное занятие.

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

Так ото ж. Я пока в fstab так сделал:

tmpfs						/home/alex/.cache		tmpfs	rw,noatime,nosuid,mode=01777,size=2g						0	0
Чтобы кэшами не насиловать диск дополнительно.

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

Ну вот я работаю уже несколько часов - пока все ок.

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

Хорошо, что работает! Судя по логам, кэши и посыпались, в основном.

Я просто не понял сразу, что задача — протянуть несколько дней. Как выяснить причину — вы, безусловно, и без нашей помощи разберетесь, когда появится возможность.

anonymous
()
Ответ на: комментарий от Suntechnic

Так. Именно ДО текущей загрузки. Тут фс УЖЕ повреждена. Это происходит либо из-за багов с trim, либо из-за проблем в ядре.

Deleted
()
Ответ на: комментарий от anonymous

Какие-то еще есть идеи как снизить нагрузку на диск?

Индексации поисковиком нет, типа recoll. /tmp и прочая фигня давно в tmpfs туда же сунул все кэши. Что-то еще?

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

Вроде как discard убрать достаточно, трим по расписанию ЕМНИП работает иначе.

Deleted
()
Ответ на: комментарий от Suntechnic

Эти утилиты просто берут инфу из procfs, где разбивки по разделам нет.

Боюсь, что это только btrace даст. Ибо сказано:

Если нечем заняться в выходные, то отладчик, strace в зубы — и вперед.

Извиняюсь за самоцитирование.

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

Я за время которое на это потрачу тупо на новый заработаю.

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

Хм... сасибо за инфу. Однако там пишут что даже в 4.18 это не встречелось. А у меня и на 4.15 Были ошибки.

Ща дополню еще по развитию событий. Минут через 15.

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

Как я понимаю, и в 4.19 далеко не у всех встречается.

https://lkml.org/lkml/2018/11/28/856

Пишут, что влияет флаг CONFIG_EXT4_ENCRYPTION (даже если само шифрование не используется).

For me - switching off CONFIG_EXT4_ENCRYPTION helps. machine survive
run updatedb & kernel compile. Switch it back to ON - crashed again:

Какой io-scheduler используется? В 4.19 поменяли планировщик по-умолчанию, может быть поэтому баг вылез..?

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

Нельзя. Обратился в чат. В итоге специалист контактного центра SanDisk перезвонила, уточнила модель и серийник устройства, после чего проверила и сообщила, что с этой неисправностью надо обращаться к производителю ноута - поддержка этих экземпляров только через Lenovo.

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

Вот сижу в недоумении - SSD это по их мнению тоже RAM, не поладки с рамой могут влиять на работу диска или девушка просто описалась? Вопрос задал - пока жду ответа...

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

Как бы если у тебя глючит оперативка - это вообще может вызвать и запись битых данных на диск. Ничего удивительного.

Deleted
()
Ответ на: комментарий от Suntechnic

не поладки с рамой могут влиять на работу диска

Могут.

anonymous
()
Ответ на: комментарий от Deleted

Похоже на то. Ответ ТП:

Согласно результатам диагностики из предоставленного отчёта, неисправным компонентом является RAM (ОЗУ).
Работа ОЗУ определенно влияет на SSD, храня в себе входные, выходные и промежуточные данные, обрабатываемые процессором.
«В общем случае ОЗУ содержит программы и данные ОС и запущенные прикладные программы пользователя и данные этих программ» - специфика работы ОЗУ может влиять на удаление данных/их потерю.

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

Ну они настаивают на этой версии. У меня есть очень серьезные основания сомневаться, о которых я пока не хотел бы говорить.

Пока жду когда они привезут планку в Ростов, а уже пока будут менять поговорю непосредственно со специалистом сервиса. По идеи он же будет не по логу гадать, а смотреть на месте ну и типа специалист.

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

С тех пор как его выпилил из GRUB в Ubuntu, я не знаю как его запустить. Но встроенный в ноут тест похоже он же. Есть вот такой лог полной проверки памяти - https://pastebin.com/UvkbDZk8

С 59 строки видно что сыпятся ошибки. Есть только один вопрос - это действительно проблема памяти, а не контроллера? И тут у меня сомнения - я как раз подорзеваю, что проблема может крыться в контроллере оперативке, северном мосте или что там сейчас вместо него. Или к таким ошибка может приводить только неисправность ячеек опертаивки только?

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

Убунты под рукой нету — не могу сказать, как это в ней делается.

У нас memtest никто не выпиливал, все на месте:

https://access.redhat.com/solutions/15693

Может, и в Убунте так же — просто memtest86+ установить надо.

Вместо контроллера оперативки и северного моста сейчас проц.=) Судя по всему, действительно память: как будто несколько рядом расположенных адресов биты. Правда, не очень ясно, что это за утилита и что конкретно она делает. Я бы прогнал всем известный и однозначно интерпретируемый мемтест.

А так — да, пусть производитель разбирается. Они за ноут деньги получили, и приличные деньги.

Интересный случай, на самом деле. Единственный симптом битой памяти — рассыпавшаяся ФС. И это не какая-нибудь ZFS с жирным ARC. Удивительно.

anonymous
()
Ответ на: комментарий от Suntechnic

Кстати, ядру можно запретить использовать битую память. Только адреса лучше получить от мемтеста.

Keywords: memmap kernel option; BadRAM

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

Интересный случай, на самом деле. Единственный симптом битой памяти — рассыпавшаяся ФС. И это не какая-нибудь ZFS с жирным ARC. Удивительно.

Не удивительно потому что проблемы с диском имеют 100% другую природу. У меня просто есть другая планка памяти.

Suntechnic ★★★★★
() автор топика

2ALL: А подскажите как бы подобные ошибки выглядили в Windows. Все же с вендой таких ноутов сильно больше - а я не знаю как гуглить. Просто thinkpad P50s detection error on ssd мало что дает.

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

Приехал сегодня мастер и заменил планку (кстати на другую - Smasung, подробности еще не смотрел, но он сказал что по ТТХ такая же). На мои сомнения по поводу того что это память сказал - ну да, скорее всего мать. Ставь на тест - если опять вылезут ошибки в оперативе - это оно. Пиши туда же в сапорт - пришлют и заменим.

Как-то так. Сейчас крутится внутренний тест встроенный в ноут.

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

Тест прогнал 4 раза - никаких ошибок ниразу не вылезло. Следующим этапом по совету сервисника обновил BIOS (была и правда очень старая версия). Потом скачал SanDisk Dashboard и проверил диск им (пришлось венду на флэшку ради этого вкорячить), в том числе расширенное тестирование SMART. Прошивка диска последняя.

Проблема никуда не исчезла.

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

С памятью разобрались, значит.

Теперь загружайте стабильное ядро (RHEL или Windows), исправляйте ФС, и смотрите на поведение системы. С диска систему не загружайте: память убила ФС и ваша Ubuntu может быть повреждена неочевидным образом. СМАРТ — в пользу бедных, он становится плохим, когда уже все рассыпалось.

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

Теперь загружайте стабильное ядро (RHEL или Windows)

Windows работает с флэшки USB 3.0 на MLC с такой скоростью, что я между нажатиями клавиш чайку успевал попить. Поэтому наверное RHEL.

исправляйте ФС

ФС вроде исправлена. А как проверить? Из венды не получается - оно вообще не видит разделов, ни то что ФС. Встроенное в BIOS средство по всей видимости низкоуровневое - запустил на нем тестирование на бэдблоки - оно не выявило.

С диска систему не загружайте: память убила ФС и ваша Ubuntu может быть повреждена неочевидным образом

Вот об этом я и думаю. Может просто форматнуть диск, переразбить его и заново установить систему? Хомяка можно на флэху временно скинуть - ничо даже перенастраивать не придется. Но это только на случай если проблема действительно может быть софтовая.

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

Тогда да, RHEL. Есть Live образы CentOS, с них можно загрузиться и работать.

ФС вроде исправлена. А как проверить?

fsck.ext4? Но это проверка и исправление ФС, а не данных. После такой катастрофы с памятью данные заведомо повреждены, и, видимо, проще все переставить. Хомяк, разумеется, тоже в какой-то степени поврежден и могут быть всякие глюки, например, из-за битых конфигов.

Ext4 — это не btrfs/ZFS, целостность данных тут никак не контролируется. Это невозмоожно проверить.

С этим, кстати, связан, предрассудок, что для ZFS нужна обязательно ECC. Дело в том, что при ошибках в памяти ZFS/btrfs scrub громко кричит, тогда как остальные ФС тихо портят данные.

Проблема может быть софтовой теоретически. Просто поработайте из Шляпы какое-то время. Будут появляться еще ошибки — тогда диску ппц.

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

Просто поработайте из Шляпы какое-то время. Будут появляться еще ошибки — тогда диску ппц.

Не знаю насколько это возможно - проблема плавающая. Однажды возникла через минуту после загрузки. Другие разы по нескольку дней проблем не было. Сколько из шляпы то работать придется? Ну я попробую поставить на флэху сегодня.

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

Тогда сразу переставляйте. Это уже нетехнический вопрос, прошу прощения.

Крайте не советую играться ядрами: если Убунту, то это должна быть ЛТС с дефолтным ядром. Вероятность багов, ломающих ФС будет минимальной (в rh kernel их совершенно точно нет). Насколько я понял, вам ведь работать надо.

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

Ядро 4.19 поставил потому что появилось предположение, что проблема в 4.15 :(

Тогда сразу переставляйте. Это уже нетехнический вопрос, прошу прощения.

Переставляю уже. Точнее даже уже поставлил, влил старый хомяк и пакеты накатываю.

Suntechnic ★★★★★
() автор топика
9 января 2019 г.
Ответ на: комментарий от Suntechnic

С момента переустановки прошел месяц. Полет нормальный. Нужно констатировать следующее - источником проблем стала оперативная память, что привело к повреждению данных записываемых на диск, а это в свою очередь повлекло все остальные последствия. Считаю что сервис Lenovo отработал оперативно - от момента обращение в чат, на сайте производителя, до замены планки памяти прошло 6 дней. Учитывая погодные условия и то что я не в ДС считаю это хорошей реакцией + мне не пришлось никуда ехать - специалист СЦ, приехал для выполнения работ ко мне, в тот же день когда в СЦ поступила деталь, не смотря на то, что к этому времени рабочий день уже завершился.

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

Интересный кейс.

И все же зря решили btrfs выкинуть. Поддерживать ее, конечно, дорого, но в некоторых случаях она может оказаться полезной.

anonymous
()
28 февраля 2019 г.

UPD:С момента переустановки прошел месяц. Полет нормальный. Нужно констатировать следующее - источником проблем стала оперативная память,

спасибо, пну ТП хецнера, сеймщит...

darkenshvein ★★★★★
()

спасибо за тред, сейчас стала возникать точно такая же проблема. только у меня SSD (Kingston A400 120G) лежит ~месяц без дела, подключаю его чтобы обновить на нём линукс и снова забыть на месяц, и каждый раз он сыпит непонятными ошибками. если оставить железку с системой работать на пару суток — всё работает как часы, но как SSD полежит немного, начинается свистопляска с просьбой выполнить fsck. странно, блин.

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

если оставить железку с системой работать на пару суток — всё работает как часы, но как SSD полежит немного, начинается свистопляска с просьбой выполнить fsck. странно, блин.

Это то, что «в народе» называют «прогрев» устройства. Выглядит, как мистическая хрень. В техническом плане означает какие-либо неполадки с компонентами устройства, которые в процессе работы как-бы «исчезают». Вполне возможно, что «финал» работы устройства не за горами.

Я наблюдал схожее «поведение» на старом IDE HDD-диске. Он служил системным диском. Подключался в SATA через переходник IDE-SATA. При старте система часто тормозила из-за ошибок диска. Но, когда загружалась сбоев не было (возможно, просто не замечали). Заменили его из-за нехватки свободного места. А так бы работал до физического «финала»...

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

Контрольные суммы файлов не пробовал сверять?

greenman ★★★★★
()
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.