Date: Fri, 22 Aug 2008 21:12:17 +0200 From: Polytropon <freebsd@edvax.de> To: freebsd-questions@freebsd.org, Polytropon <freebsd@edvax.de> Cc: Oliver Fromme <olli@lurza.secnetix.de>, freebsd-questions@freebsd.org Subject: Re: Again: fsck_ffs memory requirements Message-ID: <20080822211217.b5e404e2.freebsd@edvax.de> In-Reply-To: <200808220829.m7M8T5Is048761@lurza.secnetix.de> References: <20080822021926.d2d9ee0f.freebsd@edvax.de> <200808220829.m7M8T5Is048761@lurza.secnetix.de>
next in thread | previous in thread | raw e-mail | index | archive | help
On Fri, 22 Aug 2008 10:29:05 +0200 (CEST), Oliver Fromme <olli@lurza.secnetix.de> 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, ...
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20080822211217.b5e404e2.freebsd>