Ext4 fs error device sda2

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

[ 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 дней. Учитывая погодные условия и то что я не в ДС считаю это хорошей реакцией + мне не пришлось никуда ехать — специалист СЦ, приехал для выполнения работ ко мне, в тот же день когда в СЦ поступила деталь, не смотря на то, что к этому времени рабочий день уже завершился.

I have a pretty basic system running Ubuntu 16.04 (this question is not specific to Ubuntu, but rather ext4 partitions), 1 HDD, running a few partitions:

sda1 - EXT4 - 100G   - /
sda2 - EXT4 - 723.5G - /home
sda3 - NTFS - 100G   - (windows)
sda5 - SWAP - 8G

Whenever I try to access one of 3-4 files in a specific directory in the /home partition, (the specific folder causing the issues is /home/path/to/broken/folder), the /home partition will error and remount read-only. dmesg shows the following errors:

EXT4-fs error (device sda2): ext4_ext_check_inode:497: inode #1415: comm rm: pblk 0 bad header/extent: invalid magic - magic 0, entries 0, max 0(0), depth 0(0)
Aborting journal on device sda2-8.
EXT4-fs (sda2): Remounting filesystem read-only
EXT4-fs error (device sda2): ext4_ext_check_inode:497: inode #1417: comm rm: pblk 0 bad header/extent: invalid magic - magic 0, entries 0, max 0(0), depth 0(0)
EXT4-fs error (device sda2): ext4_ext_check_inode:497: inode #1416: comm rm: pblk 0 bad header/extent: invalid magic - magic 0, entries 0, max 0(0), depth 0(0)

So I understand what is going on…some bad block is causing an error and is remounting the drive read-only to prevent further corruption. I know it is these specific files because I can undo the error by

1. Logging in as root
2. Running sync
3. Stopping lightdm (and all sub-processes)
4. Stop all remaining open files on /home by finding them with lsof | grep /home
5. Unmounting /home
6. Running fsck /home (fixing the errors)
7. Remount /home

Everything is fine again, read and write, until I try to access the same files again, then this entire process is repeated to fix it again.

The way I’ve tried to access the files is by running ls /home/path/to/broken/folder and rm -r /home/path/to/broken/folder, so it seems any kind of HDD operation on that part of the drive errors it and throws it into read-only again.

I honestly don’t care about the files, I just want them gone. I am willing to remove the entire /home/path/to/broken/folder folder, but every time I try this, it fails and throws into read-only.

I ran badblocks -v /dev/sda2 on my hard drive, but it came out clean, no bad blocks. Any help would still be greatly appreciated.

Still looking for a solution to this. Some information that might be useful below:

$ debugfs -R 'stat <1415>' /dev/sda2
debugfs 1.42.13 (17-May-2015)
Inode: 1415   Type: regular    Mode:  0644   Flags:  0x80000
Generation: 0    Version: 0x00000000
User:     0   Group:     0   Size: 0
File ACL: 0    Directory ACL: 0
Links: 1   Blockcount: 0
Fragment:  Address: 0    Number: 0    Size: 0
ctime: 0x5639ad86 -- Wed Nov  4 01:02:30 2015
atime: 0x5639ad86 -- Wed Nov  4 01:02:30 2015
mtime: 0x5639ad86 -- Wed Nov  4 01:02:30 2015
Size of extra inode fields: 0
EXTENTS:

Now I looked at this myself and compared it to what I suspect to be a non-corrupted inode:

$ debugfs -R 'stat <1410>' /dev/sda2
debugfs 1.42.13 (17-May-2015)
Inode: 1410   Type: regular    Mode:  0644   Flags:  0x80000
Generation: 0    Version: 0x00000000
User:     0   Group:     0   Size: 996
File ACL: 0    Directory ACL: 0
Links: 1   Blockcount: 0
Fragment:  Address: 0    Number: 0    Size: 0
ctime: 0x5639ad31 -- Wed Nov  4 01:01:05 2015
atime: 0x5639ad31 -- Wed Nov  4 01:01:05 2015
mtime: 0x5639ad31 -- Wed Nov  4 01:01:05 2015
Size of extra inode fields: 0
EXTENTS:
(0):46679378

I have bolded what I believe are the key differences here. I looked at other non-corrupted inodes and they display something similar to the 1410 that has a non-zero size and an extent.

Bad header/extent makes sense here…it has no extent….how do I fix this without reformatting my entire /home partition?

_{I really feel like I’ve handed this question to someone smarter than me on a silver platter, I just don’t know what the meal (answer) is!}

Hi kind people,

First of all: I do not have physical access to the pi. just ssh.

The problem:
I have a Pi 3b+ booting form an 1tb usb hdd with stretch.
Someone there unplugged the power and the Pi was gone for some days. Now its back online but i found some kernel messages at kern.log:

Jul 8 06:25:51 kernel: [56256.560073] EXT4-fs error (device sda2): ext4_lookup:1578: inode #1516286: comm updatedb.mlocat: deleted inode referenced: 1517646
Jul 8 06:25:51kernel: [56256.575081] EXT4-fs error (device sda2): ext4_lookup:1578: inode #1516286: comm updatedb.mlocat: deleted inode referenced: 1517644
Jul 8 06:25:51 kernel: [56256.586311] EXT4-fs error (device sda2): ext4_lookup:1578: inode #1516286: comm updatedb.mlocat: deleted inode referenced: 1517648
Jul 8 06:25:54 kernel: [56259.776821] EXT4-fs error (device sda2): ext4_lookup:1578: inode #37191: comm updatedb.mlocat: deleted inode referenced: 1517629
Jul 9 06:25:03 kernel: [142608.634548] EXT4-fs error (device sda2): ext4_lookup:1578: inode #1516286: comm updatedb.mlocat: deleted inode referenced: 1517646
Jul 9 06:25:03 kernel: [142608.656301] EXT4-fs error (device sda2): ext4_lookup:1578: inode #1516286: comm updatedb.mlocat: deleted inode referenced: 1517644
Jul 9 06:25:03 kernel: [142608.667414] EXT4-fs error (device sda2): ext4_lookup:1578: inode #1516286: comm updatedb.mlocat: deleted inode referenced: 1517648
Jul 9 06:25:03 kernel: [142608.898870] EXT4-fs error (device sda2): ext4_lookup:1578: inode #37191: comm updatedb.mlocat: deleted inode referenced: 1517629
Jul 9 06:56:14 kernel: [144479.464526] EXT4-fs (sda2): error count since last fsck: 8
Jul 9 06:56:14 kernel: [144479.464535] EXT4-fs (sda2): initial error at time 1562559951: ext4_lookup:1578: inode 1516286
Jul 9 06:56:14 kernel: [144479.464545] EXT4-fs (sda2): last error at time 1562646303: ext4_lookup:1578: inode 37191

I have no idea why its back online (if it was doing something while booting or someone attached power to it again).

Whats the best practice now?

Internet says running fsck at sda2 is a bad idea because its mounted as /.

Adding fsck.mode=force to cmdline.txt is suggested but the official docs doesn’t say anything about this parameter.

I asked at the chat and someone said since its not documented he would run fsck even if the partition is mounted. But im not feeling good with it, to be honest. So im asking for some help here.

My current cmdline.txt is the following:

dwc_otg.lpm_enable=0 console=serial0,115200 console=tty1 root=PARTUUID=0862402d-02 rootfstype=ext4 elevator=deadline fsck.repair=yes rootwait ipv6.disable=1

Thank you in advance!

Страницы: [1]   Вниз

0 Пользователей и 1 Гость просматривают эту тему.

Страницы: [1]   Вверх