ru.linux

 
 - RU.LINUX ---------------------------------------------------------------------
 From : Serg Oskin                           2:5020/20      06 Jun 2001  22:16:15
 To : bor@vb.dn.ua
 Subject : Re: ext3fs
 -------------------------------------------------------------------------------- 
 

 .RFC-X-Complaints-To: news@spider.ncc.macomnet.ru
 .RFC-NNTP-Posting-Date: 6 Jun 2001 18:16:18 GMT
 
 >>>>> "b" == bor  writes:
 
 b> ок. Все что смогла - это вываливание номеров inodes и спрашивание "<y>???
 b> Что-то мне верится с трудом.
  
 b> можно было хотя-бы выдать вот те самые адрбуты файлов?
 
 SO> Выдать куда?
 
 b>   а куда мне выдают номера инодов, и где у меня спрашивают Fix<y>? 
 b>   (или как там)?
   
 b>   вот ровно туда-же и выдавать, только не номера, а любую дополнительную
 b>   информацию, на основе которой я смогу решить fix его, или ну его нафиг.
 
 А ты обрати внимание на слова, которые выдает fsck: что-то предлагает сразу
 стереть, например файл без имени и с нулевыми длиной и временем создания, а
 те, для которых выделено место помещает в lost+found, чтоб можно было
 посмотреть содержимое.
 
 b> Я вот например знаю, что в мой fs нет объектов типа "устроясво", у которых
 
 "твоя" fs - случай очень редкий и ты запросто можешь написать myfsck. :)
 А вот обычный админ должен предполагать, что юзеры могут насоздавать в
 $HOME тех-же socket'ов и pipe'ов...
 
 b> в прописан РАЗМЕР, больший чем размер fs. Hе говоря уже о странных
 b> uid/gid, и пр. Еслиб у меня спрашивали не просто номер inode, а дали еще
 b> хоть какую-то информацию, я бы отвечал более осмыслено.
 
 Какую именно?
 Чем отличается устройство от файла? Только комбинацией битиков в
 определенном месте. А вдруг это место попортилось?.. Тоже и с размерами:
 был файлик на килобайт, а прописались пара битиков не туда и получились
 гигабайты.
 
 SO> fsck "вынула файлы из небытия" и сложила их в lost+found оставив
 SO> "атрибуты" неизмененными, т.е. те, что были прописаны в
 SO> суперблоке. Если атрибуты странные - это означает, что такие они в
 SO> суперблоке, т.е. он поломан.  
  
  
 b>  ...или fsck решил что это был файл, а на самом деле, это кусок службной
 b>  структуры ext2
 
 Т.к. fsck не может решить этот вопрос однозначно, то весь кусок помещается
 в lost+found для последующего анализа соотв. инструментами.
  
 SO> Или ты хочешь, чтоб fsck затерла эту оставшуюся информацию и прописала
 SO> туда какие-то левые значения?
 
 b>  Hи в коем случае. С другой стороны - на каую информацию может "ссылаться"
 b>  элемент файловой системы типа Block/Character Device? А PIPE? А FIFO?
 
 См. выше: ты уверен, что это Block/Character Device, PIPE или FIFO?
  
 SO> Жестокий пример: если обвалился жилой дом, как лучше разгребать?
 SO> Вдумчиво и осторожно по кирпичику, в надежде, что кто-то еще жив или
 SO> сразу бульдозерами и сделать вид, что никакого дома небыло?
 
 b>  оооо... В случае "дома" мы четко видим, что вот это КИРПИЧИ, а это ЛЮДИ.
 b>  В случае с ext2 - fsck делает вид что он совсем никак не может отличить
 b>  куски служебной иннформации ext2, от пользовательских данных.
 
 Т.е. если из-под груды кирпичей торчит не человеческая рука, а всего лишь
 ручка детской коляски, то по этой груде можно спокойно ехать на бульдозере?..
 
 b>  Hапример, служебную информацию я бы предпочел увидеть не в виде _файла_, в 
 b>  которым не ясно что делать. 
 
 Попробуй в качестве примера придумать другой вариант представления нужной
 тебе информации.
 
 b>  скажем так - неужели никак по седрежимому блока нельзя угадать что это?
 b>  Пусть даже такого рода ИИ не будет давать 100%, всегда можно на консоль
 b>  спросить что-то типа 
  
 b>  "вот эти блоки очень похоже на direct_block и indirect_block, котоыре
 b>  ссылаются на то-то и то-то. Хотите их записать как просто файл, или
 b>  проследить цепочку, и попытться восстановить данные на которые они
 b>  ссылаются?" А если дадут посмотреть например начало сектора, на который
 b>  "это возможно ссылается" - так я вообще однозначно скажу, в каком виде мне 
 b>  это писать (собвенно что я и делал с помощью lde).
  
 b>  С другой стороны - если "по всем параметрам это похоже на indirect block", 
 b>  но ссылается он на блок с номером, который невозможен на данной fs, то это 
 b>  гораздо более похоже на пользовательские данные, хотя можно уточнить ровно 
 b>  той-же формулировкой, разве что только сказать "даже если это и ссылка, то 
 b>  ссылается она вникуда, на нашей fs такого номера блока не бывает".
 
 b>  В нашем-же случае (fsck.ext2), караз больше похоже на бульдозер. Все
 b>  свалили в lost+found, и копайся там, как хочешь, чем хочешь...
 
 Корректнее сравнивать не с бульдозером, а со специально обученными
 спасателями с собаками, которые подозрительные места ограждают флажками с
 надписью lost+found, а ты уже можешь решать какой именно инструмент
 применить в каждом конкретном случае.
 И разбираться с такими файлами ты можешь не спеша. Чтоб через некоторое
 время после удаления из lost+found файла с мусором не оказалось, что у тебя
 (или кого-то из юзеров) пропал файл с бесценной шифрованной информацией...
  
 b>  Да много как можно было облегчить восстановление. Причем, тот, кто хорошо
 b>  знает структуры ext2, наверняка бы потратил не очень много времени.
 b>  Просто никому это не було нужно (боюсь что и не нужно до сих пор).
 
 Что ты предпочтешь для слесарной работы: набор слесарного инструмента
 (молоток, напильник, сверлильный станок...) или сверлильный станок, у
 которого с одной стороны есть насечка для обтачивания деталей?.. :)
 
 -- 
   Serg (mailto:oskin@macomnet.ru http://www.macomnet.ru/~oskin/).
 
 P.S. Давно домой пора, а я тут азбучные истины пишу... :(
 ~
 ~
 :q!
 --- Gnus v5.6.45/XEmacs 21.1 - "Channel Islands"
  * Origin: Macomnet (2:5020/20@fidonet)
 
 

Вернуться к списку тем, сортированных по: возрастание даты  уменьшение даты  тема  автор