[image]

Сбои в файлах при длительном хранении

Перенос из темы «Разговоры о компьютерах»
 
+
-
edit
 

Balancer

администратор
★★★★★
ext4 Linux xfs данные файлы
В который раз натыкаюсь на потерю данных в файле. В фотке. Случаи единичные на многие десятки тысяч фото, но нет-нет, а наткнёшься на фотку, отображаемую лишь до половины, например. Размер тот же, нулей внутри не видно, таймстамп прежний. exiftool возвращает корректные данные. Но если сравнить с бэкапом — md5 файла отличается. Можно бы было винить железо, но это уже третья машина с таким поведением. Было подозрение на xfs, но сейчас случай с ext4. Натыкался на такую потерю данных при переполнении раздела с ext4 при копировании (на уже скопировавшихся файлах), но сейчас копирования нет, на разделе свободно 96Гб из 690Гб. Такие же проблемы иногда всплывают в видеоколлекции. Только там обнаружить сложнее, при просмотре столь короткий сбой в глаза не бросается, а вот при пересчёте хеша торрента, нет-нет, да попадётся раз в несколько месяцев «закачано на 99.8%». За секунды докачивается до 100%, но такое дело есть. Единственное, что объединяет все эти случаи — Gentoo. Но ситуация повторяется регулярно в течении многих лет (не меньше 10), за это время и ядер сколько сменилось, и настройки компиляции... А вот на ntfs/windows многие файлы лежать ещё с середины 1990-х гг., пережив десятки копирований, начиная с винчестеров по 133..270Мб... К сожалению, по той же Ubuntu такой статистики нет, все её инсталляции у меня «временные», основные архивы или в ntfs/windows, или ext4/xfs/gentoo.

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

// Транслировано с juick.com
   
RU VVSFalcon #10.12.2014 20:38  @Balancer#10.12.2014 06:20
+
+1
-
edit
 

VVSFalcon

аксакал

Мыслей нет, но эффект "99.8%" с торрентами вполне себе наблюдается и под Windows.
   39.0.2171.7139.0.2171.71

AXT

инженер вольнодумец
★☆
Balancer> Есть мысли, что это может быть? А сами вы с таким сталкивались?

Под виндой было. Причём как-то специфически, установщик (официально скачанный с сайта производителя) от Altera Quartus погибал два раза подряд. Прямо паранойю вызывает...
   13.0.782.22013.0.782.220
RU я уехал #10.12.2014 21:37  @Sandro#10.12.2014 21:22
+
-
edit
 

я уехал
TEvg-2

мракобес

Тож наблюдал подобный торрент и под фат32 под виндами и на райзерФС в лине. Только бывает это очччень редко и блин очень трудно поставить опыт по отлову таких дефектов.

Если часто бьются фотки, надо во-1 иметь полные копии на другом носителе, во-2 сравнивая битую с целой понять где побилось, в-3 выяснить как физически и логически лежал файл на диске. В-4 ставить опыты в разных средах. В-5 контролировать бы чем и как идет обращение к файлам. В-6 постоянно делать и проверять хеши файлов на предмет побитости.
Авось какая-нить зацепка вылезет.
   
+
-
edit
 

Balancer

администратор
★★★★★
я.у.> Авось какая-нить зацепка вылезет.

Не вылезет. Проблема в том, что сбои единичные на годы-сотни гигабайт. И обнаружить сложно, так как внешне ничего не меняется, атрибуты файлов те же самые... Постоянно считать контрольные суммы и сравнивать с эталоном — тоже не выход. Задолбаешься регулярно пересчитывать терабайт данных, особенно, когда начинаешь массово модифицировать файлы, тот же порядок в фотоколлекции наводить, тысячи новых фото добавлять и т.п.
   39.0.2171.7139.0.2171.71
+
-
edit
 

Floyd

аксакал

я.у.>> Авось какая-нить зацепка вылезет.
Balancer> Не вылезет. Проблема в том, что сбои единичные на годы-сотни гигабайт. И обнаружить сложно,

Если вообще возможно.
Может быть как то связано с накаткой журналов и ошибками fsck.
   34.034.0
+
-
edit
 

Balancer

администратор
★★★★★
Floyd> Если вообще возможно.

Если писать для каждого файла контрольную сумму, то обнаружить сбой легко. Проблема именно в объёмах сканирования и фильтрации корректных изменений...

О! При корректно изменении обычно меняются и атрибуты файла. А вот при таком сбое — нет. Значит, можно ловить ситуации, когда файл с виду не изменён, а контрольная сумма поменялась. Это не позволит вычислить уже потерянное (в случае фоток, правда, есть инструменты проверки целостности JPEG), но позволит находить будущие потери и восстанавливать их из бэкапа.
   39.0.2171.7139.0.2171.71
+
-
edit
 

Balancer

администратор
★★★★★
Floyd> Может быть как то связано с накаткой журналов и ошибками fsck.

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

AXT

инженер вольнодумец
★☆
я.у.> Авось какая-нить зацепка вылезет.

С CD в своё время ВНЕЗАПНО был косяк с работой скремблера. Суть в том, что при некоторых битовых последовательностях некоторые (не все) приводы теряли синхронизацию с потоком данных. С USB сталкивался лично, там при специально сконструированном потоке данных можно получить 100% битых пакетов. Чисто записать нужный файлик на флешку, и всё. Под большинством операционок прочитать не выйдет. USB конструировали ... очень странные люди.
   13.0.782.22013.0.782.220

AXT

инженер вольнодумец
★☆
Balancer> Это не позволит вычислить уже потерянное (в случае фоток, правда, есть инструменты проверки целостности JPEG), но позволит находить будущие потери и восстанавливать их из бэкапа.

А в случае MPEG — позволит! Ваш непокорный слуга лично делал такую софтину. Суть, естественно, в интерполяции по соседним кадрам и обнаружении битых блоков. Была смешная история, когда нам подсунули посмотреть запоротый DVD, мы из патриотических соображений смотрели своим проигрывателем, и всё было нормально, только звук периодически "затыкался". А потом кто-то таки попробовал использовать WMP :)
   13.0.782.22013.0.782.220
RU VVSFalcon #11.12.2014 16:24  @Balancer#10.12.2014 22:18
+
-
edit
 

VVSFalcon

аксакал

Хмм . . . Обнаружил что некоторые (выборка мала) видео из архива "квадратят". Кое что я перед закладкой перекодировал, видеоадаптер менял, да и систему недавно пришлось переустанавливать. Однако есть и файлы которые почти точно не перекодировал. Грехи видеоадаптера и переуствноыки системы (косо поставленные кодеки и драйверы) проверил отнеся один из файлов на работу - так же "квадратит" (но, это не отсеяло варианта "перекодировал и не посмотрел, что получилось"). Что-то я насторожился. Будем потихоньку исследовать вопрос.

Ах, да, как-то немного странно повела себя DFSR. На днях провёл начальную репликацию (после переустановки системы) части данных (музыка, книжки и т.п.). Далее, поставил видео. Тут у меня система что-то позависала, но вроде отошло. Зато теперь DFSR вновь шерстит первую часть реплицированного. Активно сверяет файлы и даже пишет в лог, что "конфликт устранён, правильная копия выбрана бла бла бла". Ессно пока первичная репликация видео встала на 55 Гб (из Тб+). Я далёк от конспирологии, но посмотрим что будет в итоге. Пару FLAC из "конфликт устранён, правильная копия выбрана . . ." проверил, вроде нормально всё. Да и вообще, я музыку довольно много слушаю, по идее сбойные файлы должны были обнаруживаться если появляются.

Словом, да, мнения нету, но, будем посмотреть.
   39.0.2171.7139.0.2171.71

+
-
edit
 

Balancer

администратор
★★★★★
Просканировал ночью домашний фотоархив с помощью jpeginfo -c (странно, что раньше руки не доходили) и на 74 тыс. фотографий архива обнаружил 657 сбоев. Из них 563 случая обнуления файлов (это может объясняться тем, что архив несколько лет жил на XFS и не самым благоприятным электропитанием, без ИБП) и 94 случая повреждения данных во внешне целом файле. Как раз, тот случай, про который говорю. Архиву около 12 лет. Если считать, что его объём рос примерно линейно и среднее время хранения в нём файла составляет 74000/2*12 = 444 тыс. «файлолет», то один сбой приходится, в среднем, на 4700 «файлолет» хранения.

Если средний размер файла считать за 2Мб, то, в среднем, 1Мб данных повреждается за 9400 лет хранения. В видеоколлекции на 1Тб размером таким образом каждый год должно накапливаться около 100 сбоев. Вот тут встречно проверить точность оценки не могу. На хранящихся файлах сбои так просто не заметить, ну, мелькнёт в процессе воспроизведения сбойный блок, так они иногда и на свежевыкаченных 100% файлах бывают. А при пересчёте хешей раздач сбои (когда 100% закачки превращаются в «99.98%») встречаются не редко, но нет данных для статистики за какой период и т.п.
   3838
+
-
edit
 

Balancer

администратор
★★★★★
AXT> С CD в своё время ВНЕЗАПНО был косяк с работой скремблера. Суть в том, что при некоторых битовых последовательностях некоторые (не все) приводы теряли синхронизацию с потоком данных.

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

Сбой в 1Мб на (округлённо) 10 тыс. лет хранения, скорее намекает, всё же, на какую-то статистическую ошибку. Очень похоже на физический сбой в самом носителе, на блине HDD. Но тогда непонятно, какого фига он не возвращает современный аналог пресловутого досовского (R)etry/(A)bort/(I)gnore....
   3838
+
-
edit
 

Balancer

администратор
★★★★★
Кажется, докопался до причин.

Я недавно (25 июля) переносил данные со старого на новый HDD (выводил из LVM 2Тб с дохнущей механикой в пользу нового 4Тб). Но считал, что бэкап, в котором цел ряд файлов, повреждённых сейчас в основной копии, делал уже после этого переноса. Поднял форумные архивы (хорошо, когда сам для себя такие отчёты пишешь :D), оказалось, я бэкап через btsync делал аж за месяц до переноса, процесс начался 27 июня и занимал несколько дней.

Так что, видимо, данные бились в процессе чтения и сбой оставался незамеченным. И писались уже битые. Похоже, собака тут порылась.
   3838
RU VVSFalcon #11.12.2014 17:28  @Balancer#11.12.2014 17:13
+
-
edit
 

VVSFalcon

аксакал

Я нашёл на работе файлик годичной давности. Играет без сбоев. И, это 100% копия именно такого же файла из моего архива. Вечером посмотрю дома как оно играется (стащу домой на флэшке и сравню с архивным). Разница между ними - год на разных винтах. Конечно у меня дома колонки недалеко стоят, но и на работе тоже (даже ближе). Кроме того, для эм полей без разницы, файл или логическая структура диска. Но вот сбоев дисковых вроде не замечал за последний год.
   39.0.2171.7139.0.2171.71
US Иван Нью-Джерсийский #11.12.2014 22:28  @Balancer#10.12.2014 06:20
+
-
edit
 
Balancer> Есть мысли, что это может быть? А сами вы с таким сталкивались?

Нет. Проверил самые-самые первые фотки, скачанные из Инета еще в далеком 98-м и кочевавшей с 98-й "Винды" на "Миллениум", затем на ХР, затем на 7. Все ОК. Видимо, проблема в "Линуксе" - система передовая, сама решает, что пользователю нужно, а что нет. :F
   34.034.0
RU VVSFalcon #12.12.2014 02:32
+
-
edit
 

VVSFalcon

аксакал

@$$%$^&(*&%^^%^$^% мать!
И видео (почти 2 ТБ), и аудио (более Тб). Но, слава богу не диски. При копировании рабочего файла - проигрывается сразу "квадратично". В общем, полетел SATA контроллер (Sil 3512). Подключил диск на встроенный - всё играет нормально. А то уж совсем кисло сделалось, всё что нажито непосильным торрентованием :) Поехал в Юлмарт.

Правда начальную репликацию придётся о новой провести.
   10.010.0
RU Balancer #12.12.2014 05:23  @AGRESSOR#11.12.2014 22:28
+
-
edit
 

Balancer

администратор
★★★★★
И.Н.> Нет. Проверил самые-самые первые фотки, скачанные из Инета еще в далеком 98-м

А объём суммарный какой? И как проверял?

И.Н.> Видимо, проблема в "Линуксе" - система передовая, сама решает, что пользователю нужно, а что нет. :F

Если бы ты читал внимательно комментарии, то увидел бы, что у народа и под Windows такая же проблема встречается :)
   39.0.2171.7139.0.2171.71
RU Balancer #12.12.2014 05:27  @VVSFalcon#12.12.2014 02:32
+
-
edit
 

Balancer

администратор
★★★★★
VVSFalcon> А то уж совсем кисло сделалось, всё что нажито непосильным торрентованием :) Поехал в Юлмарт.

Я же теперь решил твёрдо заняться контрольными суммами личных архивов и обязательными проверками при копировании. С последнием, кстати, хреновый момент очень есть. Привык, что при работе с LVM при заменах диска всё автоматом делается по pvmove. А копию таким образом не проверить. Придётся полагаться на резервные копии и сверять с ними. В общем, геморрой... И не то, чтобы сотня сбоев за 10 лет на 500Гб — много, но когда речь об уникальном контенте, уже неприятно. Хорошо ещё, что есть привычка фоткать сериями с избыточностью и потом лень вычищать до одной лучшей фотки в серии :) Так что есть надежда, что ничего серьёзного не пропало.
   39.0.2171.7139.0.2171.71
US Иван Нью-Джерсийский #12.12.2014 06:54  @Balancer#12.12.2014 05:23
+
-
edit
 
Balancer> А объём суммарный какой? И как проверял?

У меня файловый коммандер, набиваешь поиск по атрибутам, и все дела. Нашлись в моей помойке как раз именно те, что были первыми - я их помню. Никаких дефектов на изображении. Просмотрел из ностальгии штук 50 - все ОК.

Balancer> Если бы ты читал внимательно комментарии, то увидел бы, что у народа и под Windows такая же проблема встречается :)

Я внимательно все прочитал. Я иронизирую, потому что думаю, что это не проблема из-за сроков хранения, а просто-напросто битые файлы. Когда закачка или перезапись с носителя на носитель дает сбои, получается, что часть снимка есть, остальная часть пустыми байтами забита. Такое и у меня случалось, причем сразу же, при скачке. Иногда качаешь/перегружаешь, не особо глядя на результат, а потом, спустя какое-то время обнаруживаешь. Тип ОС тут не причем.
   34.034.0
RU Balancer #12.12.2014 15:42  @AGRESSOR#12.12.2014 06:54
+
-
edit
 

Balancer

администратор
★★★★★
И.Н.> Просмотрел из ностальгии штук 50 - все ОК.

У меня со сбоями — сотня файлов на 70 тыс. Как думаешь, какова вероятность, что я наткнусь на сбойный, взяв 50 произвольных фоток? :D Я фотки очень часто смотрю, а сбойные попадаются ОЧЕНЬ редко. Иначе бы я тревогу много лет назад забил.
   3838
US Иван Нью-Джерсийский #12.12.2014 19:31  @Balancer#12.12.2014 15:42
+
-
edit
 
Balancer> У меня со сбоями — сотня файлов на 70 тыс. Как думаешь, какова вероятность, что я наткнусь на сбойный, взяв 50 произвольных фоток?

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

В режиме превьюшек, кстати, файлы даже открывать не надо - достаточно папку прокрутить.
   34.034.0
RU Balancer #13.12.2014 07:04  @AGRESSOR#12.12.2014 19:31
+
-
edit
 

Balancer

администратор
★★★★★
И.Н.> В режиме превьюшек, кстати, файлы даже открывать не надо - достаточно папку прокрутить.

В режиме превьюшек показывается обычно не содержимое файла, а встроенная превьюшка в заголовке файла. Так что файл, битый от середины и до конца, покажет корректную превьюшку.
   39.0.2171.7139.0.2171.71
+
+1
-
edit
 
Прикольно. Вот так живешь-живешь и случайно узнаешь, что в jpg формате в заголовке превью хранится.
   34.034.0

Balancer

администратор
★★★★★
GOGI> Прикольно. Вот так живешь-живешь и случайно узнаешь, что в jpg формате в заголовке превью хранится.

Иначе на фотике с тормозной флешкой задолбаешься листать фотки по 20Мпкс :) Хотя изначально оно было добавлено из-за тормозных процессоров древних фотиков, которые очень медленно ресайзили полный размер до превью.
   39.0.2171.7139.0.2171.71

в начало страницы | новое
 
Поиск
Настройки
Твиттер сайта
Статистика
Рейтинг@Mail.ru