Кастуем i-rinat

Вопрос: может стать хуже или нет?

Да, может стать хуже, как и при любой починке. И поставь reiserfsprogs 3.6.23, недавно релиз был.

Count of blocks on the device: 240485008

У тебя раздел в 917 GiB? Некоторые параметры выглядят нормальными, а некоторые странными. Например, занятых блоков нет вообще, но положение журнала и его размер стандартные.

А вообще я бы сохранил метаданные (debugreiserfs -p /dev/sdXX > sdXX.metadata) и запустил --rebuild-sb с последующим --rebuild-tree.

Да, раздел 917 GiB.
Блин, я забыл, запускал я уже --rebuild-tree или только --fix-fixable. Помню лишь, что завершилось неудачей. Наверно от этого параметры выглядят странными.

я забыл

--rebuild-tree занимает несколько часов, потому что требует чтения всех данных с диска. Если это внешний диск через usb 2.0, то как минимум 8 часов. Плюс время на скачки головки туда-сюда.

--fix-fixable обходит только дерево метаданных, оно намного меньше.

Решил сделать бэкап ddrescueм, и попробовать ваш совет

Интересно услышать, чем всё в итоге закончилось.

А как там зовут того мультяшного персонажа, всегда кукарекающего, что reiser3.6 никогда не ломается и оплодотворяет бесплодных?

reiser3.6 никогда не ломается

А reiserfs3.6 никогда и не ломается, ибо не может ломаться то, чего нет. Нет чистого 3.6, есть только смесь 3.5+3.6.

итог

ddrescue копировал образ дней десять Оо. По закону подлости, конечно же, в последний день, когда оставалось ~30 гигов докопировать, вырубили свет на полдня. Падла.

http://storage2.static.itmages.ru/i/13/0720/h_1374344377_9742950_3cc9fbc2c6.jpeg

Я потом продолжил ddrescue из лога, оно докопировалось конечно, но сдается мне как-то жопно, судя по тому, что оно пишет будь-то 985Gb в образе, раазмером 917Gb.

fdisk -l:

root@PartedMagic:~# fdisk -l /dev/sda

Disk /dev/sda: 1500.3 GB, 1500301910016 bytes
255 heads, 63 sectors/track, 182401 cylinders, total 2930277168 sectors
Units = sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes
Disk identifier: 0x0002cc34

   Device Boot      Start         End      Blocks   Id  System
/dev/sda1              63  1923880139   961940038+  83  Linux
/dev/sda2   *  1923880140  2028736394    52428127+   7  HPFS/NTFS/exFAT
/dev/sda3      2028736395  2930272064   450767835    7  HPFS/NTFS/exFAT

root@PartedMagic:~# fdisk -l /dev/sda1

Disk /dev/sda1: 985.0 GB, 985026599424 bytes
255 heads, 63 sectors/track, 119755 cylinders, total 1923880077 sectors
Units = sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes

root@PartedMagic:~#

Только толку пока нет. --rebuild-sb не смог определить начало раздела в образе, хотя там всего один раздел снят. Спрашивал про размер блока (512), default ли journal, раз не указано устройство с журналом (y). Предложил в конце --rebuild-header (y/n), я согласился (y).

--rebuild-sb листинг:

Will check superblock and rebuild it if needed
Will put log info to '/media/sdb5/BACKUP/sunduk.img-dev-loop.rebuild-sb.log'

Do you want to run this program?[N/Yes] (note need to type Yes if you do):Yes
Reiserfs super block in block 128 on 0x702 of format 3.6 with standard journal
Count of blocks on the device: 1923880064
Number of bitmaps: 0 (really uses 469698)
Blocksize: 512
Free blocks (count of blocks - used [journal, bitmaps, data, reserved] blocks): 0
Root block: 0
Filesystem is NOT clean
Tree height: 0
Hash function used to sort names: "r5"
Objectid map size 2, max 76
Journal parameters:
	Device [0x0]
	Magic [0x0]
	Size 3966 blocks (including 1 for journal header) (first block 130)
	Max transaction length 128 blocks
	Max batch size 112 blocks
	Max commit age 30
Blocks reserved by journal: 0
Fs state field: 0xfa03:
	FATAL corruptions exist.
	 some corruptions exist.
sb_version: 2
inode generation number: 0
UUID: 8342abc3-e183-41d4-9a77-3f769f433c95
LABEL: 
Set flags in SB:
Mount count: 1
Maximum mount count: 30
Last fsck run: Thu Jul 18 23:55:25 2013
Check interval in days: 180
Is this ok ? (y/n)[n]: y
The fs may still be unconsistent. Run reiserfsck --check.
root@PartedMagic:~#

Ещё вот-так ругался:

--rebuild-sb листинг:

rebuild-sb: wrong bitmap number occured (10946), fixed (0) (really 469698)

--check образа сказал, что --rebuild-tree не закончен, и тут я вспомнил, что такое уже было, когда --rebuild-tree оборвался вырубанием света в доме, когда я запускал его ещё на свежеполоманном харде первый раз. Падла.

Ещё вот-так ругался:

--check листинг:

Zero bit found in on-disk bitmap after the last valid bit.

--rebuild-tree образа теперь мрет вот так:

--rebuild-tree листинг:

Will rebuild the filesystem (/dev/loop2) tree
Will put log info to '/media/sdb5/BACKUP/sunduk.img-dev-loop.rebuild-tree.log'

Do you want to run this program?[N/Yes] (note need to type Yes if you do):Yes
Replaying journal: No transactions found
###########
reiserfsck --rebuild-tree started at Fri Jul 19 20:26:27 2013
###########

Pass 0:
Loading on-disk bitmap .. ok, 916652209 blocks marked used
Skipping 473793 blocks (super block, journal, bitmaps) 1492594745 blocks will be read
0%                                                           left 0, 53409 /sec
	"r5" hash is selected
Flushing..finished
	Read blocks (but not data blocks) 1492594745
		Leaves among those 151830
			- leaves all contents of which could not be saved and deleted 151830
		Objectids found 2

Pass 1 (will try to insert 0 leaves):
Killed
root@PartedMagic:~#

Зато лог весит 50Mb епт:

--rebuild-tree лог:

Zero bit found in on-disk bitmap after the last valid bit. Fixed.
####### Pass 0 #######
init_source_bitmap: Bitmap 0 (of 4096 bits) is wrong - mark all blocks [0 - 4096] as used
init_source_bitmap: Bitmap 1 (of 4096 bits) is wrong - mark all blocks [4096 - 8192] as used
init_source_bitmap: Bitmap 2 (of 4096 bits) is wrong - mark all blocks [8192 - 12288] as used
...
block 8442040: The number of items (1) is incorrect, should be (0) - corrected
block 8442040: The free space (0) is incorrect, should be (488) - corrected
block 8466416: The number of items (1) is incorrect, should be (0) - corrected
...
pass0: vpf-10110: block 42936565, item (0): Unknown item type found [327936 1644236564 0xf79454352554f53 ??? (6)] - deleted
...
pass0: vpf-10200: block 996847314, item 0: The item [286331153 65537 0x111111111111111 IND (1)] with wrong offset is deleted
...
block 1138494256: The number of items (13) is incorrect, should be (0) - corrected
block 113849

В общем нифига не монтируется.

будь-то 985Gb в образе, размером 917Gb.

985 * 1000 * 1000 * 1000 приблизительно равно 917 * 1024 * 1024 * 1024. Просто разница в единицах измерения.

Спрашивал про размер блока (512)

Вот тут, наверное, ошибка. Если при создании раздела ты не указывал особо размер блока, он устанавливается в 4096 байт. (В той документации, что я читал, автор вообще считал, что reiserfs на блоках не равных 4096 байт вообще функционировать не может. Хотя с тех пор это вроде исправили.)

Если это действительно так, то rebuid-tree искал битмапы не там, и пытался найти узлы не того размера.

Предлагаю экспериментировать на небольшом куске от начала раздела, пары гигабайт думаю будет достаточно. Метаданные обычно раскиданы по всему диску, битмапы лежат каждые 128 MiB, суперблок и журнал находятся в самом начале.

Нов ведь когда я первый самый раз запускал --rebuild-tree на реальном харде он ведь не спрашивал про размер блока, просто искал-искал... а потом свет, падла, вырубили. Ну он ведь наверно определил как-то сам размер блока, прежде чем искать то? (раз не спрашивал),

а fdisk показывает Sector size 512 bytes таки. На реальном харде. Значит и в снятом образе по 512.

В общем вопрос: если все-таки на самом деле 4096, а оно искало по 512, и может даже при этом чего-то заребилдило уже, значит кирдык, или не кирдык?

Sector size 512 bytes таки. На реальном харде. Значит и в снятом образе по 512.

Это размер сектора жёсткого диска, записать или считать с железа меньше 512 байт невозможно. Файловые системы имеют размер кластера (или размер блока, вопрос терминологии) кратным размеру сектора. По умолчанию в reiserfs размер блока равен 4096 байт.

если все-таки на самом деле 4096, а оно искало по 512, и может даже при этом чего-то заребилдило уже, значит кирдык, или не кирдык?

Скорее всего, образ оно попортило. Но если это копия, то стоит попробовать второй раз на этой копии прогнать сначала rebuild-sb, затем rebuild-tree, уже с указанием размера блока == 4096. Либо попробовать на новой копии. Для начала на первых гигабайтах.

Багодарю за просвещение. А вот оно больше не спрашивает про размер, его можно как-то параметром задать?

А вот оно больше не спрашивает про размер, его можно как-то параметром задать?

Насколько я знаю, нет.

а-а-а, блин. Новый образ фигачить ... это ад.

Запилил образ второй раз, на этот раз не в файл а сразу на раздел. Так оно вместо 10 дней - 2 дня копировало... не пойму в чем прикол.

Запустил комманды:

root@PartedMagic:~# debugreiserfs -p /dev/sde1 > /media/sdb5/BACKUP/debugreiserfs.sunduk-clone.metadata
debugreiserfs 3.6.21 (2009 www.namesys.com)

reiserfsck --rebuild-sb /dev/sde1 -l /media/sdb5/BACKUP/sunduk-clone.rebuild-sb.logLoading on-disk bitmap .. 220600160 bits set - done
super block..ok
bitmaps..(7340).. ok
journal (from 18 to 8210)..
ok
Super block, bitmaps, journal - 15534 blocks - done, 220584626 blocks left
0%....                                                            left 0, 8790 /sec
Packed 264663 blocks:
	compessed 253630
	full blocks 11033
		leaves with broken block head 80
		corrupted leaves 12
		internals 2517
		descriptors 0
data packed with ratio 0.08

root@PartedMagic:~# reiserfsck --rebuild-sb /dev/sde1 -l /media/sdb5/BACKUP/sunduk-clone.rebuild-sb.log
reiserfsck 3.6.21 (2009 www.namesys.com)

*************************************************************
** If you are using the latest reiserfsprogs and  it fails **
** please  email bug reports to reiserfs-list@namesys.com, **
** providing  as  much  information  as  possible --  your **
** hardware,  kernel,  patches,  settings,  all reiserfsck **
** messages  (including version),  the reiserfsck logfile, **
** check  the  syslog file  for  any  related information. **
** If you would like advice on using this program, support **
** is available  for $25 at  www.namesys.com/support.html. **
*************************************************************

Will check superblock and rebuild it if needed
Will put log info to '/media/sdb5/BACKUP/sunduk-clone.rebuild-sb.log'

Do you want to run this program?[N/Yes] (note need to type Yes if you do):

Не пойму чего оно второй раз запустило комманду, вто думаю теперь, заребилдилось, или это только метада писалась (лог 80 MB) этим debugreiserfsом? Потому-что когда я ввел debugreiserfs -p /dev/sde1 > /media/sdb5/BACKUP/debugreiserfs.sunduk-clone.metadata, оно думало-думало, и я сразу добавил reiserfsck --rebuild-sb /dev/sde1 -l /media/sdb5/BACKUP/sunduk-clone.rebuild-sb.log, и теперь не втыкаю чего именно сработало

Не пойму чего оно второй раз запустило комманду

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

или это только метада писалась (лог 80 MB) этим debugreiserfsом?

Ты скопировал метаданные раздела в файл. Этот файл можно использовать для отладки (там есть структура, но нет самих данных). Никаких изменений на диск эта команда не вносит.

и теперь не втыкаю чего именно сработало

Сработали обе команды, на текущий момент у тебя исправлен суперблок ФС. Дальше надо сделать reiserfsck --check, чтобы удостовериться, что суперблок теперь корректный, а дальше запускать reiserfsck --rebuild-tree.

спс, ща прроверим

--rebuild-tree завершился, раздел монтируется ☻! Благодарю за помощь!

раздел монтируется

Ну и отлично.