Re: Congratulations! we have got hash function screwed up
Matthias Andree <[EMAIL PROTECTED]> writes: > All private machines I deal with are reiserfs-free as of a few hours > ago. What do you use instead? I really don't like that there is no undelete feature in reiserfs - it's not planned for reiserfs-4 either. I see desperate users all the time trying to get back what they mistakenly removed. It shouldn't be hard with reiserfs either. There should be a selection of what files to restore, so we can avoid the file merging problem with rebuilding the tree from leaf nodes. > I have seen too many bugs in reiserfs3. Is there a list of these current issues? > "Who cares, not us for the past five years" is not a proper response > to a real-world problem. I also reacted to this response. A flaw in the filesystem, in my opinion, is equivalent to the space ship crashing and all crew members die. -- Esben Stien is [EMAIL PROTECTED] http://www.esben-stien.name irc://irc.esben-stien.name/%23contact [sip|iax]:[EMAIL PROTECTED]
Re: Congratulations! we have got hash function screwed up
Sander <[EMAIL PROTECTED]> writes: > If you 'see desperate users all the time' you might be amoung the > wrong people ;-) ;), on the lists and on user groups. > Maybe you can clue them in the wonderful world of making backups? I always promote bacula, but you will always have those who don't do the dance. > Next time it is not their mistake, but instead a broken harddisk. > Undelete wont save them then. We got pretty good tools to restore from a hd with bad blocks. dd it, loop it, fsck it. > Or they just edited it instead of rm. This is handled in user space. -- Esben Stien is [EMAIL PROTECTED] http://www.esben-stien.name irc://irc.esben-stien.name/%23contact [sip|iax]:[EMAIL PROTECTED]
Re: Congratulations! we have got hash function screwed up
Sander <[EMAIL PROTECTED]> writes: > Maybe you can clue them in the wonderful world of making backups? This is not always the case, btw This might be caused by a faulty application as well if the system is not secure enough. Tools to scan the partition and give a list of possible restores should not be hard to implement. -- Esben Stien is [EMAIL PROTECTED] http://www.esben-stien.name irc://irc.esben-stien.name/%23contact [sip|iax]:[EMAIL PROTECTED]
Re: Congratulations! we have got hash function screwed up
"Burnes, James" <[EMAIL PROTECTED]> writes: >> dd it, loop it, fsck it. > That won't help you if a circuit board, spindle, read head or other > mechanism fails. Sure, but that is not a simple case of bad blocks;) > Then you better hope the data wasn't *that* valuable or you know > good platter recovery shop. We got IBAS in Norway; the price for an evaluation is close to a handful of gold. > Backups are cheap. Recovery is very expensive. Sure, but your not factoring in murphys law here. A tool to undelete would come many people in handy who even got proper backup solutions. Besides, a recovery is not the same as a feature to undelete. Such a feature would maybe save a days work, which is a lot in some circles. -- Esben Stien is [EMAIL PROTECTED] http://www.esben-stien.name irc://irc.esben-stien.name/%23contact [sip|iax]:[EMAIL PROTECTED]
Re: Congratulations! we have got hash function screwed up
Sander <[EMAIL PROTECTED]> writes: >> dd it, loop it, fsck it. > > I'm sure a friend of mine disagrees with you after paying big bucks > to a Norway based disk recovery company after a disk crash and zero > backups. A Dutch recovery company couldn't recover the disk. Probably IBAS;). What was the problem of the hd then?. Why couldn't the dutchies do the job? > And restore from backup is always quicker and less stressful on the > nerves. Like I said to James, this might not only be the fault of the user. > Maybe in your situation. But in general I advice everybody to make > backups. Might also be the reason nobody wrote a reiser4 undelete > plugin yet. It's no use to talk about backups when we talk about undelete features; backups are for recovery after nuclear explosions, faulty hardware which makes it inaccessible to even retrieve data out of it or something similar. It would be too expensive to do all this backup'ing in userspace. When a file gets deleted, a proper procedure to retrieve it would be to umount the filesystem, scan it for the data which was removed and then put it back in the tree again. It's not like reiserfs overwrites this data, it's still there, so why should there be an artificial barrier to getting this data back?. -- Esben Stien is [EMAIL PROTECTED] http://www.esben-stien.name irc://irc.esben-stien.name/%23contact [sip|iax]:[EMAIL PROTECTED]
Re: Congratulations! we have got hash function screwed up
Sander <[EMAIL PROTECTED]> writes: > I did recover data that way several times back when I didn't do backups. > The problem is though that one file does not occupy one spot on the > harddisk. It might be spread all over the place. While the data might > still be there (on an idle disk), you miss the much needed pointers to > the data. I'm not talking about grep here. I'm talking about a reiser tool to scan the partition for metadata and use this to recover the file by putting it back in the tree. Methods like grep is an absolute last resort, if, like in this case, there is no tool that does the job. -- Esben Stien is [EMAIL PROTECTED] http://www.esben-stien.name irc://irc.esben-stien.name/%23contact [sip|iax]:[EMAIL PROTECTED]
Re: Congratulations! we have got hash function screwed up
Hans Reiser <[EMAIL PROTECTED]> writes: > I may still put it in someday and just not tell him.;-) > I'll just let the users know about it and not him.;-) Hehe, nice;) -- Esben Stien is [EMAIL PROTECTED] http://www.esben-stien.name irc://irc.esben-stien.name/%23contact [sip|iax]:[EMAIL PROTECTED]
Encounter of the Bad Block Kind
All filesystems herein are reiserfs'ed.
I was entering a directory called foo/ on hda1 (hda = 203Go), then bad
blocks were found.
Here's a shortened and modified sample:
end_request: I/O error, dev hda, sector z
hda:dma_intr:status=0x51{DriveReady SeekComplete Error}
hda:dma_intr:error=0x40{UncorrectableError},LBAsect=x,high=17,low=y,sector=z
ide: failed opcode was: unknown
#umount /dev/hda1
#dd_rescue -l hda1.dd.p1.log -A -B 4096 -b 1M /dev/hda1 /mnt/fs2/hda1.img
I umount'ed the partition, called up shop, ordered a new 200Go hd and
transferred hda1.img to a filesystem on the new hd.
Because the partition I was transferring hda1.img to was smaller I had
to cancel the dd_rescue operation. This was because hda itself was
about 203Go and the new hd I had was 199Go. I had to cancel dd_rescue
several Go before the job was complete.
#losetup /dev/loop0 /mnt/hda1.img
#reiserfsck --logfile hda1.fsck.p1.log /dev/loop0
#reiserfsck --logfile hda1.fsck.p1.rsb.log --rebuild-superblock /dev/loop0
#reiserfsck --logfile hda1.fsck.p1.rt.log --rebuild-tree /dev/loop0
I then losetup'ed the image and ran reiserfsck on it. Because the
hda1.img was smaller in size, the superblock holding the information
on the partition size was wrong. I then --rebuild-sb and ran
reiserfsck again, which adviced me to run --rebuild-tree; ..and so I
did.
#mount /dev/loop0 /mnt/image
When it was finished, I mounted the hda1.img only to find about 90% of
the files fubar'ed. My hda1 was only containing movies in several
directories and I was unable to play most fubar'ed files and those
borken files I managed to play were very annoying to look at. The
remaining 10% which were intact, played fine. There were also many
files missing; f.ex I had part 1 of one movie and part 2 of
another.
#dd_rescue -l hda1.dd.p2.log -A -B 4096 -b 1M /dev/hda1 /mnt/fs2/hda1.img
#losetup /dev/loop0 /mnt/hda1.img
#reiserfsck --logfile hda1.fsck.p2.log /mnt/image
I then decided to get a bigger hd, so I bought a 250Go hd. I then
dd_rescue'ed the whole image to the new filesystem and losetup'ed
it. I noted that dd_rescue found 52 errors in 208kio of data. I
proceeded with reiserfsck which told me to run --rebuild-tree.
#mount /dev/loop0 /mnt/image
#cp -a /mnt/image/* /mnt/fs4/muhaha
I was sceptic this time around to run --rebuild-tree since the last
time I ran it, it destroyed 90% of my files so I just mounted the
hda1.img without --rebuild-tree'ing it. All my files except foo/ and
bar.mtk were intact. I cp'ed all these files to another filesystem.
#reiserfsck --logfile hda1.fsck.p2.rt.log --rebuild-tree /mnt/image
#mount /dev/loop0 /mnt/image
I then --rebuild-tree as reiserfsck adviced me to; just to see what
happened. It ran until it was finished, then I mounted it. All my
files except foo/ and bar.mtk were intact. Now they were found in
lost_and_found, as expected. Some files that were in foo/ I could also
play;), but bar.mtk is gone forever it seems.
Guess we can't work on incomplete images..!
--
Esben Stien is [EMAIL PROTECTED]
http://www.esben-stien.name
irc://irc.esben-stien.name/%23contact
[sip|iax]:[EMAIL PROTECTED]
Re: Plugin for corruption resistance?
Gregory Maxwell <[EMAIL PROTECTED]> writes: > Anyone ever given a though to adding support to reiserfs to store a > cryptographic checksum along with a file? Yes, I thought about putting it there as an extended attribute -- Esben Stien is [EMAIL PROTECTED] http://www.esben-stien.name irc://irc.esben-stien.name/%23contact [sip|iax]:[EMAIL PROTECTED]
Re: Partial data loss with reiserfs3
Laurynas Biveinis <[EMAIL PROTECTED]> writes: > I do not remember well and .bash_history isn't very helpful > there. It's very likely that mkfs was the first thing after boot. Check out ttyrpld, http://ttyrpld.sf.net -- Esben Stien is [EMAIL PROTECTED] http://www.esben-stien.name irc://irc.esben-stien.name/%23contact [sip|iax]:[EMAIL PROTECTED]
Re: Partial data loss with reiserfs3
Vitaly Fertman <[EMAIL PROTECTED]> writes: > reboot is required between repartitioning a drive and starting to > use moved/created partitions. Will there ever be an end to this misery?. Is noone planning to fix this? -- Esben Stien is [EMAIL PROTECTED] http://www.esben-stien.name irc://irc.esben-stien.name/%23contact [sip|iax]:[EMAIL PROTECTED]
A Little Bitty Panic
/0x110 .[<>] .. ( <= stext+0x3feffdd8/0x8) .. [] __up_mutex+0x4ac/0x520 .[<>] .. ( <= stext+0x3feffdd8/0x8) .. [] print_traces+0x14/0x40 .....[<>] .. ( <= stext+0x3feffdd8/0x8) -- Esben Stien is [EMAIL PROTECTED] s a http://www. s tn m irc://irc. b - i . e/%23contact [sip|iax]: e e jid:b0ef@n n
