ru.linux

 
 - RU.LINUX ---------------------------------------------------------------------
 From : Vladimir Bormotov                    2:5020/400     06 Jun 2001  19:15:04
 To : Serg Oskin
 Subject : Re: ext3fs
 -------------------------------------------------------------------------------- 
 

 
    Hi, Serg!
 
 >>>>> "SO" == Serg Oskin <Serg.Oskin@f20.n5020.z2.fidonet.org> writes:
 
  
 b>>  ок. Все что смогла - это вываливание номеров inodes и спрашивание "<y>???
 b>>  Что-то мне верится с трудом.
  
 b>>  можно было хотя-бы выдать вот те самые адрбуты файлов?
 
  SO> Выдать куда?
 
   а куда мне выдают номера инодов, и где у меня спрашивают Fix<y>? 
   (или как там)?
   
   вот ровно туда-же и выдавать, только не номера, а любую дополнительную
   информацию, на основе которой я смогу решить fix его, или ну его нафиг.
   
 b>>  Я вот например знаю, что в мой fs нет объектов типа "устроясво", у которых 
 b>>  в прописан РАЗМЕР, больший чем размер fs. Hе говоря уже о странных
 b>>  uid/gid, и пр. Еслиб у меня спрашивали не просто номер inode, а дали еще
 b>>  хоть какую-то информацию, я бы отвечал более осмыслено.
 
  SO> fsck "вынула файлы из небытия" и сложила их в lost+found оставив
  SO> "атрибуты" неизмененными, т.е. те, что были прописаны в
  SO> суперблоке. Если атрибуты странные - это означает, что такие они в
  SO> суперблоке, т.е. он поломан.  
  
  
  ...или fsck решил что это был файл, а на самом деле, это кусок службной
  структуры ext2
  
  SO> Или ты хочешь, чтоб fsck затерла эту оставшуюся информацию и прописала
  SO> туда какие-то левые значения?
 
  Hи в коем случае. С другой стороны - на каую информацию может "ссылаться"
  элемент файловой системы типа Block/Character Device? А PIPE? А FIFO?
  
  
  SO> Жестокий пример: если обвалился жилой дом, как лучше разгребать?
  SO> Вдумчиво и осторожно по кирпичику, в надежде, что кто-то еще жив или
  SO> сразу бульдозерами и сделать вид, что никакого дома небыло?
 
  оооо... В случае "дома" мы четко видим, что вот это КИРПИЧИ, а это ЛЮДИ.
  В случае с ext2 - fsck делает вид что он совсем никак не может отличить
  куски служебной иннформации ext2, от пользовательских данных.
  
  Hапример, служебную информацию я бы предпочел увидеть не в виде _файла_, в 
  которым не ясно что делать. 
  
  скажем так - неужели никак по седрежимому блока нельзя угадать что это?
  Пусть даже такого рода ИИ не будет давать 100%, всегда можно на консоль
  спросить что-то типа 
  
  "вот эти блоки очень похоже на direct_block и indirect_block, котоыре
  ссылаются на то-то и то-то. Хотите их записать как просто файл, или
  проследить цепочку, и попытться восстановить данные на которые они
  ссылаются?" А если дадут посмотреть например начало сектора, на который
  "это возможно ссылается" - так я вообще однозначно скажу, в каком виде мне 
  это писать (собвенно что я и делал с помощью lde).
  
  С другой стороны - если "по всем параметрам это похоже на indirect block", 
  но ссылается он на блок с номером, который невозможен на данной fs, то это 
  гораздо более похоже на пользовательские данные, хотя можно уточнить ровно 
  той-же формулировкой, разве что только сказать "даже если это и ссылка, то 
  ссылается она вникуда, на нашей fs такого номера блока не бывает".
 
  В нашем-же случае (fsck.ext2), караз больше похоже на бульдозер. Все
  свалили в lost+found, и копайся там, как хочешь, чем хочешь...
  
  Да много как можно было облегчить восстановление. Причем, тот, кто хорошо
  знает структуры ext2, наверняка бы потратил не очень много времени.
  Просто никому это не було нужно (боюсь что и не нужно до сих пор).
 
  
 -- 
    Bor.
 --- ifmail v.2.15dev5
  * Origin: BorHomeLand (2:5020/400)
 
 

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