LINUX.ORG.RU

Reiserfs superblock

 ,


0

2

Поломался хард, не читается суперблок, хочу считать файлы, запускаю

reiserfsck --rebuild-sb /dev/sdb1
Вывод:

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 'stdout'

Do you want to run this program?[N/Yes] (note need to type Yes if you do):Yes
rebuild-sb: wrong tree height occured (65535), zeroed
Reiserfs super block in block 16 on 0x811 of format 3.6 with standard journal
Count of blocks on the device: 240485008
Number of bitmaps: 7340
Blocksize: 4096
Free blocks (count of blocks - used [journal, bitmaps, data, reserved] blocks): 240485008
Root block: 0
Filesystem is NOT clean
Tree height: 0
Hash function used to sort names: "r5"
Objectid map size 84, max 972
Journal parameters:
	Device [0x0]
	Magic [0x6ba361d7]
	Size 8193 blocks (including 1 for journal header) (first block 18)
	Max transaction length 1024 blocks
	Max batch size 900 blocks
	Max commit age 30
Blocks reserved by journal: 0
Fs state field: 0x3:
	FATAL corruptions exist.
	 some corruptions exist.
sb_version: 2
inode generation number: 495821
UUID: 102f1b99-22c8-4c69-97c3-e3b4384b2f7a
LABEL: sunduk
Set flags in SB:
	ATTRIBUTES CLEAN
Mount count: 23
Maximum mount count: 30
Last fsck run: Thu Jul  5 15:42:07 2012
Check interval in days: 180
Is this ok ? (y/n)[n]: 

Ok или не OK?

Показывает что FATAL corruptions exist, если ввести y, суперблок запишется. Вопрос: может стать хуже или нет?

Говорят оффтопиковый UFS Explorer умеет файлы с reiserfs восстанавливать и без читабельности суперблока, вот и думаю, есть ли риск.

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

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

Count of blocks on the device: 240485008

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

i-rinat ★★★★★ ()

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

i-rinat ★★★★★ ()
Ответ на: комментарий от i-rinat

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

Flashwalker ()
Ответ на: комментарий от Flashwalker

я забыл

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

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

i-rinat ★★★★★ ()

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

anonymous ()
Ответ на: комментарий от anonymous

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

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

i-rinat ★★★★★ ()
Ответ на: комментарий от i-rinat

итог

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

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

Flashwalker ()
Ответ на: итог от Flashwalker

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

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

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

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

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

i-rinat ★★★★★ ()
Ответ на: итог от Flashwalker

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

i-rinat ★★★★★ ()
Ответ на: комментарий от i-rinat

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

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

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

Flashwalker ()
Ответ на: комментарий от Flashwalker

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

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

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

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

i-rinat ★★★★★ ()
Ответ на: комментарий от i-rinat

Запилил образ второй раз, на этот раз не в файл а сразу на раздел. Так оно вместо 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, и теперь не втыкаю чего именно сработало

Flashwalker ()
Ответ на: комментарий от Flashwalker

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

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

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

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

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

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

i-rinat ★★★★★ ()
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.