LINUX.ORG.RU

побились файлы на ext4 после отключения электричества

 , ,


1

3

При запуске ПК после неожиданного отключения электричества на одном из дисков обнаружились ошибки ФС. УПСа нет и не планирую, бэкап важных данных имеется, упала ФС с коллекцией фильмов - не критично, но неприятно. Отключил его в fstab, стартанул систему, запустил fsck:

fsck из util-linux 2.29.2
e2fsck 1.43.4 (31-Jan-2017)
films contains a file system with errors, check forced.
Pass 1: Checking inodes, blocks, and sizes

Running additional passes to resolve blocks claimed by more than one inode...
Pass 1B: Rescanning for multiply-claimed blocks
Multiply-claimed block(s) in inode 11:............

Pass 1C: Scanning directories for inodes with multiply-claimed blocks
Pass 1D: Reconciling multiply-claimed blocks
(There are 48 inodes containing multiply-claimed blocks.)

В процессе исправления ошибок выяснилось, что данные на диске модифицировались 9 сентября, т.е. почти месяц назад (аптайм ПК при этом был более месяца):

File /file (inode #11, mod time Mon Sep  9 21:05:40 2019) 
  has 809944 multiply-claimed block(s), shared with 17 file(s):

Данные на других дисках повреждены не были... WTF? почему попортились файлы, к которым не обращался несколько недель, но все ОК с системной ФС, /home , в которые данные пишутся постоянно? ФС смонтированы следующим образом:

UUID=de2c6818-640d-49bc-ba92-3b90769b40bb / ext4 errors=remount-ro 0 1
UUID=de415bb6-052b-4417-80d2-84ef31bcee9b /home ext4 defaults        0 2
UUID=ca49ef00-b6b8-4441-b93d-e456042fdaf9 /mnt/films ext4 errors=remount-ro 0 1 
Вопрос - каким образом попытаться избежать подобного? sync может помочь (если, напр., кинуть его в cron на повторение каждые 30 мин)? Или может еще варианты есть?