|
From: Richard R. <ri...@fl...> - 2001-07-10 01:38:06
|
Hi Anton, > But I don't agree about "all repairs", see end of message. I suppose it's a fine line for some possible fixes. > > ext2 for example will allow you to use a backup superblock for recovery > > purposes. We'd just be doing the same thing. > Yes. So you agree we shouldn't try to use any backups without an explicit > mount option. That saves us from all dangers when mounting, then. Yeah, let the user decide how much damage we inflict. > > Taking things further, how much do we actually NEED to recover data? > You really need the whole MFT. > But the list is shorter: dot is not needed at all. What for? It only > contains copies of info already present in the mft records. If the volume gets corrupted, them for a file as large as the MFT, we're going to lose a few records. But you're right, that's the definitive reference. As long as we can find the runlists for the MFT we're OK. > Assuming you have a complete and not corrupt MFT, you can reconstruct > a whole NTFS 1.2 volume including the directory tree. Rebuilding the directory tree would NOT be pleasant. Userland/ntfsck? Fair enough. > If the mft is corrupt then you would > need the directory tree and the bitmap to be able to resolve what is > corrupt and what not... in that context to know > $Volume is quite important...which ntfs version Do we care about this? If we encounter an ungraded volume we could find either small (old) attributes or larger (new) ones. The code would have to check the attribute's size anyway. As for the new metadata, well we can't really do much with it yet :-) > > $AttrDef > It is completely pointless. :-) At least M$ don't still waste 36K on it. > > > 3. backup boot sector. run chkdsk to recover > I do think the driver needs hotfix capabilities for many things. OK, go on... > For example fixing inconsistencies between mft and mft mirror on mount. That's fairly crucial. > Or do you think the driver should just crash out in some way when it sees that > the fs is corrupt? Hey yeah, lets oops^U There may be another solution. How anti-social would it be to become read-only on a serious error. We find a problem that we can't solve without user intervention, so we log everything we know, and "remount" ourselves read-only. > I would prefer the driver to try to recover the fs if possible We'd have to start listing the possible problems. For example: If $Bitmap has a bit reset (0) when we KNOW it is in use it makes sense for us to correct it. If it has a bit set (1) when we think it shouldn't be we can't do anything about it. (chkdsk should find the orphan and save it to a file). We could end up with a filesystem with a config file :-) > If the corruption is minor we might very well be able to recover internally > warning message that a hotfix was applied. > Having said all that, that could be applied to the boot sector as well. So Yep, lots of logging. > -o repair / -o damaged ... the driver will do it's best to mount a damaged > fs and recover as much data as possible. repair sounds less negative, sounds like we know what we're doing. > The fixups unfortunately can be fine and the underlying data can be crap. > It happens. Even the windows driver sometimes causes that kind of corruption > to an ntfs volume... Argh! That would be harder to spot. At least it will be obvious when someone else (mke2fs) has trashed our volume. FlatCap (Rich) nt...@fl... |
