LinuxForum.Fans
Тема

Создание образа раздела занимает очень много времени

Автор: xxblx 27 сообщений 7435 просмотров
#305482

Принесли сегодня мне ноутбук, с бука надо выдрать данные с ntfs-раздела размером в 60Гб, раздел почти полон.
У бука проблемы с HDD.
Сначала решил прогнать badblocks, после плохие блоки в игнорирование, загрузиться, скопировать все данные и дело с концом. Но плохих блоков оказалось слишком много, процесс шел ооооочень медленно. По этому решил пойти другим путем - сделать образ раздела, смонтировать на другом компе и оттуда выдрать данные.

Съемного HDD под рукой не было, на имеющихся под рукой ПК с Linux с местом на разделах совсем туго. Но в сети есть одна машина с Win7, где место на разделах есть - пришлось прибегнуть к ее услугам, создал на ней папку backup и расшарил ее на чтение и запись для всех.

Мои действия на буке:

text
mkdir /mnt/backupsmb
mount -t cifs //192.168.1.5/backup /mnt/backupsmb
dd if=/dev/sda1 conv=sync,noerror bs=7208K | gzip -c > /mnt/backupsmb/sda1.img.gz

bs=7208K ввел исходя из вывода hdparm -i, в котором был BuffSize=7208kB.

Процесс идет уже часов 5. На данный момент скопировано 16Гб... закончится все видать только к утру.

В связи с чем вопрос, это я что-то неверно сделал? Или настолько долгий процесс нормален в связи с плохим состоянием hdd, сжатием gzip и записью образа на шару?

#305483
"xxblx" написал:
Или настолько долгий процесс нормален в связи с плохим состоянием hdd

Думаю, в основном из-за этого.

#305485
"xxblx" написал:
bs=7208K

А почему такой "нестандартный" размер блока? Или я чего-то упустил?

#305486
"Lupo Alberto" написал:
Думаю, в основном из-за этого.

Ясно, спасибо. Видать я все-таки зря панику поднял.

"yars" написал:
А почему такой "нестандартный" размер блока?

Я где-то читал, что лучше указать размер = BuffSize из hdparm -i.
hdparm -i выдал BuffSize=7208kB.

#305488

Хм, какой-то он "нестандартный" все равно :)
У меня:

text
$ su -c "hdparm -i /dev/sda"
Пароль: 

/dev/sda:

Model=ST3160827AS, FwRev=3.42, SerialNo=4MT15CPG Config={ HardSect NotMFM HdSw>15uSec Fixed DTR>10Mbs RotSpdTol>.5% } RawCHS=16383/16/63, TrkSize=0, SectSize=0, ECCbytes=4 BuffType=unknown, BuffSize=8192kB, MaxMultSect=16, MultSect=16 CurCHS=16383/16/63, CurSects=16514064, LBA=yes, LBAsects=312579695 IORDY=on/off, tPIO={min:240,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=no WriteCache=enabled Drive conforms to: ATA/ATAPI-6 T13 1410D revision 2: ATA/ATAPI-1,2,3,4,5,6

* signifies the current active mode

#305490
"yars" написал:
Хм, какой-то он "нестандартный" все равно ab

Такой вот дефолтный HDD у Lenovo IdeaPad S10-2.

#305491

для сбойных дисков надо читать объёмом не больше блока ФС... а ещё лучше блоками HDD (512 или 4 К, в зависимости от диска)... т.к. если хотя бы один сектор из блока не считался, то хер знает, что со всем блоком будет...
кстати, вывод dd в stderr лучше сохранять.... его можно потом про'sed'ить и попробовать перечитать сбойные блоки ещё раз....

ЗЫ: и образ создавать на локальной ФС надёжней... хотя это не очень принципиально...

#305658

Процесс создания образа шел примерно до 5 утра (начат был в ~16:30).
Сегодня ради интереса решил прогнать другие разделы (фс ext4) на этом же жестком диске ноутбука через badblocks. И у / (sda5), и /home (sda7) - выдало по 0 ошибок. %)

Если два раздела ext4 в нормальном состоянии, а один ntfs "убитый", то выходит что проблема с блоками на ntfs-разделе скорее софтварная, чем физическая?
Чем еще стоит прогнать жесткий диск для проверки, MHDD?

#305678
"xxblx" написал:
Чем еще стоит прогнать жесткий диск для проверки, MHDD?

Насколько я знаю, нативных средств для проверки разделов NTFS у нас нету, надо бы виндовым chkdsk, или как его там, уже забыл. Иногда похожее бывает, если винду усыпить и загрузиться в Линукс.
UPD: MHDD - это если подозрение на физические повреждения поверхности "блина" винчестера.

#305695
"xxblx" написал:
Если два раздела ext4 в нормальном состоянии, а один ntfs "убитый", то выходит что проблема с блоками на ntfs-разделе скорее софтварная, чем физическая?

тогда бы dd не тормозил...

#305701
"yars" написал:
Насколько я знаю, нативных средств для проверки разделов NTFS у нас нету, надо бы виндовым chkdsk, или как его там, уже забыл. Иногда похожее бывает, если винду усыпить и загрузиться в Линукс.
UPD: MHDD - это если подозрение на физические повреждения поверхности "блина" винчестера.

Так мне и надо на целостность проверить сам HDD, а не конкретно раздел ntfs. Я уже образ раздела сделал - данные оттуда выдеру все. Теперь хочу определить поработает ли еще этот HDD или пришло время заказывать новый.

"Fat-Zer" написал:
тогда бы dd не тормозил...

Т.е. диск все-таки скорее всего битый?
Значит стоит его тогда мне проверить чем-нибудь еще.

#305702
"xxblx" написал:
Значит стоит его тогда мне проверить чем-нибудь еще.

smart можно глянуть.

#305739
"xxblx" написал:
Т.е. диск все-таки скорее всего битый?
Значит стоит его тогда мне проверить чем-нибудь еще.

дык какая задача то? спасти как можно больше живых данных пока большой ПЕ не нагрянул? или проверить, можно ли диском ещё пользоваться?
если первое, то создавай образ через dd или что-то более специализированное вроде dd-rescue и монтируй... с самим диском даже не думай работать... только проблем больше создашь...
если второе, то
0) бекапь данные, если нужны
1) смотри smart... если есть реалокация или настоящие беды, то диск можно прибить гвоздями к стенке...
2) запускай деструктивный badblocks... если что-то покажет, то тоже самое...

#305743
"Fat-Zer" написал:
дык какая задача то? спасти как можно больше живых данных пока большой ПЕ не нагрянул? или проверить, можно ли диском ещё пользоваться?

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

#305752

А что за ошибки возникают, может, подскажем чего?

#305786

Подозрения у меня на неправильный размер блока при копировании раздела, как уже говорили, и образ может быть неправильный,...
ы. А вот как при bs=7208k dd запишет последний блок раздела, если он другой?

#305789

Я наоборот, указываю bs=512, т.е., стандартный размер сектора. dd же в «обход» файловой системы копирует. А размер буфера данных - это совсем другое.

#305796
"yars" написал:
А что за ошибки возникают, может, подскажем чего?

Да там ntfs-3g ругается, что образ поврежденного раздела, предлагает chkdisk сделать или что-то в этом роде :D точное название этой вин-утилиты не помню.
Попробую его через ddrescue прогнать.

"zenon" написал:
Подозрения у меня на неправильный размер блока при копировании раздела, как уже говорили, и образ может быть неправильный,...

А как правильный определить?
Если брать по bs из hdparam, то 7208kB. Или надо было все-таки написать, например, 512 и не заморачиваться?

#305798
"xxblx" написал:
Если брать по bs из hdparam, то 7208kB. Или надо было все-таки написать, например, 512 и не заморачиваться?

Так я же и говорю, это размер кэш-памяти, а не реальный размер сектора.

#305799
"yars" написал:
ак я же и говорю, это размер кэш-памяти, а не реальный размер сектора.

Я где-то читал, что размер блок лучше указывать = размеру буфера (кеша, "cache size"). Или это, наоборот, неправильно?

Войдите или зарегистрируйтесь, чтобы ответить.