On Fri, 22 Aug 2008 10:29:05 +0200 (CEST), Oliver Fromme <[EMAIL PROTECTED]> wrote: > Unfortunately fsck isn't able to cope with any arbitrary > level of damage. If certain kinds of unexpected problems > occur, it throws in the towel. In theory it might be > possible to deal with your particular problem, but nobody > has implemented it in fsck yet.
I've examined some of the data contained in the error message, I inserted some "pretty printing code" to see which condition was present at abort time: --- condition: inumber > lastvalidinum --- inumber=306176 lastvalidinum=306175, lastinum=306176 fsck_ffs: bad inode number 306176 to nextinode I commented out this errx() block and found out: --- condition: inum > maxino --- inum=11116545 maxino=11116544 fsck_ffs: inoinfo: inumber 11116545 out of range It seems that some values (lastvalidinum, maxino) are retrieved incorrectly, given the assumption that one inode is needed per file (and directory). Conslusion: Too few of them. > Someone with intimate knowledge of UFS2 might be able to > help you, possibly using fsdb(8), [...] Yes, fsdb is a very good tool. I did dive into the filesystem and found out that many files are still there. I'll take some time to learn more about UFS and fsdb. Maybe there's a way to restore files - as I mentioned, "Windows" recovery software is able to retrieve arbitrary files and subtrees from the dd image. So should BSD, too. > [...] but this requires direct > access to the file system image and is beyond what can be > done through a mailing list. If I found enough information, I'll ask again, with more substance and less assumptions. > Usually such services cost > money. (The price to pay for not having backups.) In Germany, this is called "Lehrgeld". :-) But as I found out by calling some recovery services, they've got no big clue about BSD file systems, their main business is FAT and NTFS stuff, along with disassembling drives in cleanrooms. > You might also have success using one of the various > recovery or forensic toolkits out there, e.g. sleuthkit > (it's in ports). Tools like dls, ils and fls (from The Sleuth Kit) are very promising. Maybe they can help. Other tools that allow to create images from defective media (e. g. ddrescue) are nice, too, but don't help here because image retrieval has been no problem. > Well, there's nothing an OS can do against hardware failure > (such as a crash because of power loss). It hasn't been a power loss. At some point in ordinary working, I think I'd been surfing the Web at this time, the machine stopped, stood still for approx. 5 seconds, then dropped to the console /dev/ttyv0, put an error message and rebooted. After this, fsck_ffs found many errors on /, /var and /usr (e. g. /usr/X11R6/ had disappeared and was restored in pieces into lost+found/), the system didn't boot anymore. So I took another system to copy important data from the drive, which worked for everything except _my_ home directory. I have _no_ clue what happened... and I think all I need to do is to have fsck_ffs iterate on all the inodes that are not connected to my home directory anymore, or, create a new inode that connects to all these inodes that had been the content of my home directory. I hope there is a way to do this. > Such failures can > cause arbitrary damage to mass storage, especially if the > power failure happens in the middle of writing a track, and > especially when using "consumer grade" disks. People want cheap, they get cheap. You can't imagine how I hate this crappy cheap stuff... Except of an power outage, there could be other things imaginable that could leat to the destruction of an inode. Writing processes are "more dangerous" than reading processes. BUT DID IT HAVE TO BE _MY_ HOME DIRECTORY?! :-) Yes, it had to, because I relied to much on the fact that FreeBSD served me well for more than 5 years so I didn't see a neccessartity for backups ("I'll do them next week."), and that's the revenge. > Disks are cheap these days. Cheaper than your valuable > data. That's why I bought 2 x 500 GB WD drives to make a copy pf everything I still have, and I put them onto the shelf. > So, a simple way to make backups is to buy an > external disk (USB2, Firewire/IEEE1394, eSATA, or even > a hot-swappable PATA drive tray), sync your system to it > once per week, and store it in a safe place. I have an USB 2.0 carrier where I'll put an PATA disk in. At the moment, I'm doing the backups by putting the drive directly into the machine (ATA-100 cable). > If you're paranoid, then use two such disks alternating, > so you have one good (safe, i.e. disconnected) copy at > every point in time. If you're even more paranoid, store > multiple backup disks in different places (e.g. one at > home at one at your office, or at a friend's place, or > even in a safe deposit box at your bank company), so you > still have a good backup if your house burns down or an > alien space ship crashes on it. I have an anti-alien laser gun on my roof, so this won't happen. :-) Other kinds of external backups are welcome, too. For example, I gave some scripts I coded to others, so they can be retrieved from their mail folders. Up to this point, many thanks for your help. We'll meet again when I found out some more about this topic. I'll have to read up some more how UFS works. If I don't understand the mechanisms under the hood, I surely won't be able to recover my data, because this doesn't seem to be a "point and click" problem. -- Polytropon >From Magdeburg, Germany Happy FreeBSD user since 4.0 Andra moi ennepe, Mousa, ... _______________________________________________ firstname.lastname@example.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to "[EMAIL PROTECTED]"