HDD от DVR (фс=XFS) проблемы при подключении к ПК

Думается мне, нужно делать fsck не всего диска, а только раздела на нём.

Имеет смысл прогнать testdisk по этому винчестеру.

>Думается мне, нужно делать fsck не всего диска, а только раздела на нём.
Гм. В смысле, чтобы поправил только таблицу разделов (там по идее должен быть один большой раздел с данными видеонаблюдения)? Я б уже давно пустился «во все тяжкие» (т.е. начал экспериментировать) если бы не боязнь потерять все данные? (терабайт к сожалению и забакапить-то некуда)

Имеет смысл прогнать testdisk по этому винчестеру.

Сейчас погляжу. Спасибо!

Я не упомянул, но диск должен быть полностью рабочим - снят с работающего ДВР там в нем софт на базе линуха.

Результаты запуска # testdisk /list
...
Disk /dev/sdc - 1000 GB / 931 GiB - CHS 121601 255 63, sector size=512
...
Disk /dev/sdc - 1000 GB / 931 GiB - CHS 121601 255 63
Partition Start End Size in sectors
P XFS 4 0 0 1 121601 80 63 1953525168
...

testdisk запрашивает тип таблицы, подозреваю, что нужно выбрать первое?

Please select the partition table type, press Enter when done.
[Intel ] Intel/PC partition
[EFI GPT] EFI GPT partition map (Mac i386, some x86_64...)
[Humax ] Humax partition table
[Mac ] Apple partition map

[None ] Non partitioned media

[Sun ] Sun Solaris partition
[XBox ] XBox partition
[Return ] Return to disk selection

А вот и нет. Выбрав None и прогнав анализ прога отобразила, что:

Disk /dev/sdc - 1000 GB / 931 GiB - CHS 121601 255 63
Current partition structure:
Partition Start End Size in sectors
P XFS 4 0 0 1 121601 80 63 1953525168

и после Quick Search:

Disk /dev/sdc - 1000 GB / 931 GiB - CHS 121601 255 63
Partition Start End Size in sectors

P XFS 4 0 0 1 121601 80 63 1953525168

Structure: Ok.

Т.е. получается, что диск размечен без таблицы разделов - как один раздел? Первый раз с таким сталкиваюсь. Тогда почему не видно файлов при монтировании?

>Тогда почему не видно файлов при монтировании?

без вариантов - бэкапь винт(dd) и прогоняй fsck и xfs_repair

> Т.е. получается, что диск размечен без таблицы разделов - как один раздел?

И это в принципе правильно. Возможно, если диск разбить на единственный раздел, устройство не схавает.

Тогда почему не видно файлов при монтировании?

Как монтируешь?

Подозреваю, на диске нет никаких разделов и MBR тоже нет — диск использовался как RAW-носитель без разметки на разделы, и XFS делалась на всём диске.

Винта нет подходящего под рукой. :-(

# mount -t xfs /dev/sdc /mnt

А что, есть варианты?

Ну, мало ли. Здесь народ разный бывает.

ну тогда 2 вариант:

1) найти винт
2) на страх и риск пробовать восстановить на живую. В случае похера данных - удар головой об стену

Ну да, я про это и сказал. Т.е. диск имхо исправен, просто надо «правильно» его подцепить. Как теперь быть?

А можно модель устройства?

Я кстати пробовал: # xfs_check -v /dev/sdc
В самом начале было:
dir 128 size is 25, should be 13
dir 128 offsets too high
root directory 128 has .. 0

Ну и до кучи такого рода сообщений: setting block 0/48398044 to free2
(я так понимаю - последовательно для всех блоков от 0 и до конца)

Как сказал iZEN

нет никаких разделов и MBR тоже нет — диск использовался как RAW-носитель без разметки на разделы

Покрайнемере в моем китайском DVR так. Для работы с жестким у меня в комплекте шла программка под офтопик. Называется HDD Download Tool.

HDD download tool is a tool to search and download the recorded file from HDD of DVR special file system. It has the following function and feature.

«правильно» его подцепить. Как теперь быть?

через loop device - так-же как образ отдельного раздела снятый dd

mount -o loop /dev/sdc /mnt

Microdigital MDR-8800P.

Для снятых с регистратора данных (EXE) написал свой конвертер EXE->AVI (штатный - просто ж...). Но учитывая, что сутки записи с одной камеры сливаются примерно минут 10, а камер много и период большой - сливать таким образом - смерти подобно... а тут «засада» и с винтом.

>setting block 0/48398044 to free2

это печально...

Кстати модель вот. 1604LE-A

Так результат-то тот же, что и при обычном монтировании. Т.е. каталог девственно чист, но по наличию свободного места выходит, что данные все же есть.

Было бы печально, если бы это был не чек, а репайр. А так - только вывод об ошибках...

Имхо - у каждого производителя - свои заморочки. Причем нередко даже раные - к разным моделям аппаратов. :-(

а что говорит xfs_db ?

ещё попробуй при монтировании принудительно задать другую fs, возможно вывод о наличии XFS на RAW диске сделан неверно.

p.s. если есть возможность, то эксперименты лучше делать с копией и монтировать с опцией ro. Возможно при первом монтировании mount воткнул метку времени в неподобающее :)

p.p.s: а диск то ещё жив ? Если его в текущем состоянии поставить в DVR - всё увидится ? Как-бе намёк: в самом DVR должна быть опция - проверка диска..

xfs_db еще не пробовал...
О системе (помимо разных программных средств) говорит маркер XFSB начала файловой системы и таки да - начинается сразу с 0 блока диска.
Сейчас глянул дамп первого гига диска - поискал по маркерам - контент там в наличии (!).

Ну понятное дело, что с копией надо бы... но некуда (1тб - куда ж его!?). Диск скорее всего жив и после подключения к регистратору (и небольшого шаманства с пультом) можно будет поглядеть инфу - не могу проверить - регистратор на объекте в районе - не наездешься. А в самом ДВР есть только «зачистсть всё!». ;-)

Вот что «накопал» xfs_db...

xfs_db> blockget
dir 128 size is 25, should be 13
dir 128 offsets too high
root directory 128 has .. 0
link count mismatch for inode 0 (name ?), nlink 0, counted 2
link count mismatch for inode 128 (name ?), nlink 3, counted 2
link count mismatch for inode 131 (name ?), nlink 2, counted 1

xfs_db> blockuse
block 0 (0/0) type sb

xfs_db> freesp -s
from to extents blocks pct
1 1 153 153 0,01
2 3 122 313 0,01
4 7 954 5402 0,21
8 15 28342 382654 14,85
16 31 33 613 0,02
32 63 68 2921 0,11
64 127 166 12891 0,50
128 255 112 17587 0,68
256 511 5 1586 0,06
512 1023 14 9633 0,37
4096 8191 1 4549 0,18
8192 16383 2 24982 0,97
32768 65535 1 36820 1,43
1048576 2097151 1 2077194 80,60
total free extents 29974
total free blocks 2577298
average free extent size 85,9845

прям таки даже интересно

может вот это поможет: http://xfs.org/index.php/XFS_FAQ#Q:_What_is_the_issue_with_directory_corrupti...

вкратце - смысл фокуса в том что если повреждён каталог, то выяснить который там повреждён, ручками пометить его inode на удаление, а потом поймать всё в lost+found.

Сейчас гляну, а пока вот:

# xfs_repair -v -n /dev/sdc
Phase 1 - find and verify superblock...
- block cache size set to 722544 entries
Phase 2 - using internal log
- scan filesystem freespace and inode maps...
- found root inode chunk
Phase 3 - for each AG...
- scan (but don't clear) agi unlinked lists...
- process known inodes and perform inode discovery...
- agno = 0
entry «» in shortform directory 128 references invalid inode 0
zero length entry in shortform dir 128, would set to 16
entry contains illegal character in shortform dir 128
would have junked entry «» in directory inode 128
would have corrected directory 128 size from 25 to 29
directory 128 offsets too high
would have corrected entry offsets in directory 128
bogus .. inode number (0) in directory inode 128, would clear inode number
- agno = 1
- agno = 2
- agno = 3
- process newly discovered inodes...
Phase 4 - check for duplicate blocks...
- setting up duplicate extent list...
- check for inodes claiming duplicate blocks...
- agno = 0
entry «» in shortform directory 128 references invalid inode 0
- agno = 2
zero length entry in shortform dir 128, would set to 16
entry contains illegal character in shortform dir 128
would have junked entry «» in directory inode 128
- agno = 1
- agno = 3
would have corrected directory 128 size from 25 to 29
directory 128 offsets too high
would have corrected entry offsets in directory 128
bogus .. inode number (0) in directory inode 128, would clear inode number
No modify flag set, skipping phase 5
Phase 6 - check inode connectivity...
- traversing filesystem ...
- agno = 0
- agno = 1
- agno = 2
- agno = 3
- traversal finished ...
- moving disconnected inodes to lost+found ...
disconnected dir inode 131, would move to lost+found
Phase 7 - verify link counts...
would have reset inode 128 nlinks from 3 to 2
No modify flag set, skipping filesystem flush and exiting.

XFS_REPAIR Summary Fri Aug 19 13:42:51 2011

Phase      Start      End      Duration
Phase 1:   08/19 13:40:41   08/19 13:40:42   1 second
Phase 2:   08/19 13:40:42   08/19 13:40:42   
Phase 3:   08/19 13:40:42   08/19 13:42:50   2 minutes, 8 seconds
Phase 4:   08/19 13:42:50   08/19 13:42:51   1 second
Phase 5:   Skipped
Phase 6:   08/19 13:42:51   08/19 13:42:51   
Phase 7:   08/19 13:42:51   08/19 13:42:51

в догонку -

пока изменения делаеш точеченые (не repair по всему разделу) - делай бекапы хотя-бы тех частей/блоков которые меняеш.

Угу. Это я уже подумал, но х.з. где именно проблема. Пока я ничего не правлю, только проверяю.
Сделал в файл вывод # xfs_ncheck /dev/sdc >> 1.txt
Получил файл на 43 тысячи строк, вида:
...
13139214 da06531
10359372 dx05314
9791418 di05073
8981028 da04853
8031714 di04329
8027628 da04269
7740246 da04187
6811362 di03785
2831598 da01763
2143788 di01591
1315692 di01207
330966 di00741
1362 di00281
0
30062065 di14094
27663583 da13118
26806885 dx12565
24802021 dx11733
24407041 dx11465
23800951 di11184
23469985 da11092
...

Получается 43тыс. файлов и все в корне?
Обрати внимание - строка с нулём выбивается из вида.

Получается 43тыс. файлов и все в корне?

многие dvr`ы любят писать кучу маленьких файлов - типа на каждый фрагмент.

Надо попробовать вытащить любой произвольный файл и посмотреть - насколько в нём внятная информация.

кстати, если «Снял с видеорегистратора винт с целью слить большой объём данных» то видимо всё-таки есть куда слить терабайт :) Мсье лукавит ?

в длинном списке присутсвует inode 128 ? и какой там inode самый меньший.

cat 1.txt | sort | head -n 32 

Судя по последним файлам (иноды глянул) метров по 50-70 файлы (по временным отрезкам видимо). Инфа внятная я ж выше писал, что контент валиндный! (это я по первому гигу глянул когда).
Насчёт «лукавит» - мне надо показания одной камеры за три недели (20*1,5гига = 30 гигов) - никто ж не собирался ВСЁ сливать...

Нет, ноды 128 в списке нет. Младшая (не считая строку с нулём) = 132 и дальше по возрастающей.

а модель DVR`а сама по себе старая ? может там XFS naming version 1, а в ней как раз блок каталогов подругому пишется, и современным драйвером уже вроде как и не поддерживается. Может от этого и вся свистопляска с inode корневого каталога и все файлы кажутся от корня.

можно проверить - попробовать на loop устройстве «mkfs.fxs -n version=1» и посмотреть куда корень попадает - на 128 или 132.

Так 132 это не корень, это первый файл. Модель регистратора вроде не старая... х.з. Я сейчас сделаю бакап последних 100 гигов винта и напишу парсер для извлечения нужных мне данных (так оно может быстрее будет). :-) Тем не менее идеи приветствуются!

Может кому будет интересно - после прогона # xfs_repair /dev/sdc все (по крайней мере пропусков не углядел) файлы были восстановлены и помещены в lost&found. Несколько было нулевой длины - бывает и при штатной работе при выключении питания - сам несколько раз так делал при зависаниях интерфейса (именно интерфейса - запись при этом шла).

Насколько могу судить данная странность ФС - штатная «фича», т.к. провел еще одну замену винта и поглядел второй винт в данными - та же ситуация. Хотя есть мыслишка, что «попортило» при первом подключении к ПК - при автомонтировании (гадство - совсем забыл, что автоматом подхватит с USB и не запретил заранее)...

В любом случае - всем спасибо за советы!

p.s.
По ходу выяснилось, что все же первые восемь файлов (по 65мб каждый) имеют нарушеня в структуре - чётко по блоковым смещениям (по контенту сужу). Т.е. все же имхо имело место затирание оригинальной фс при монтировании...