Hi!
> > I was able to recover from bad blocks, though of course no Reiser that I
> > know of has had bad block relocation built in... But I got all my files
> > off of it, fortunately.
>
> My experience shows that you've been very, very lucky. I hope r4 is
> better in that regard.
>
> If you want to try with r3, take a well-used partition[1] and copy it
> at block level to another partition or a file. Then zero some random
> spans of blocks in the copy and reiserfsck --rebuild-tree it. My
> experience is that you'll usually get the files names and directory
> tree but their contents will have been scattered all over the place.
Actually it would be nice to have a script to automate this, and test
various filesystems for robustness :-). I done something similar, and
it uncovered few bugs in ext2fsck and vfatfsck; perhaps it is time to
try it on other filesystems, too?
Pavel
#!/bin/bash
#
# fscktest
#
# Usage:
# Make sure output is logged somewhere
# First, run fscktest -p as root
# Then you can run fscktest as normal user...
#
prepare() {
SIZE=100000
echo "Creating file..."
cat /dev/zero | head -c $[$SIZE*1024] > test
echo "Making filesystem..."
/sbin/mkfs.$FS test
echo "Mounting..."
mount test -o loop /mnt || exit "Cant mount"
echo "Copying files..."
cp -a /bin /mnt
cp -a /usr/bin /mnt
cp -a /usr/src/linux /mnt
echo "Syncing..."
sync
echo "Unmounting..."
umount /mnt
echo "Moving..."
mv test fsck.okay
echo "All done."
}
FS=ext2
if [ .$1 == .-p ]; then
prepare
exit
fi
RUN=0
while true; do
RUN=$[$RUN+1]
echo "Run #$RUN"
echo Preparing...
cat fsck.okay > fsck.damaged
echo Damaging...
dd if=/dev/urandom of=fsck.damaged count=10240 seek=7 conv=notrunc
cp fsck.damaged fsck.test
echo First check...
/sbin/fsck.$FS -fy fsck.damaged
RESULT=$?
if [ $RESULT != 1 -a $RESULT != 2 -a $RESULT != 0 ]; then
echo "Fsck failed in bad way (result = $RESULT)"
exit
fi
echo Second check...
/sbin/fsck.$FS -fy fsck.damaged
RESULT=$?
if [ $RESULT != 0 ]; then
echo "Fsck lied about its success (result = $RESULT)"
exit
fi
done
--
teflon -- maybe it is a trademark, but it should not be.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[Index of Archives]
[Kernel Newbies]
[Netfilter]
[Bugtraq]
[Photo]
[Stuff]
[Gimp]
[Yosemite News]
[MIPS Linux]
[ARM Linux]
[Linux Security]
[Linux RAID]
[Video 4 Linux]
[Linux for the blind]
[Linux Resources]
