Are these files corrupted for good?
Amaranth
happened to these files?
http://img144.imageshack.us/my.php?image=corruptedfiles.gif
Is it a hard disk problem or software one?
If I rsync'ed backup files from one Linux box to another, would it
successfully overwrite them? I'm getting permission denied ls'ing
those files even as root.
Bill Marcum
The filesystem appears to be corrupted. Run fsck before copying the
backup files.
Amaranth
fsck doesn't work. It reports the file system as read only.
If I try to touch those corrupted files (with fsck, mv, rm, etc.), the
file system seems to change to read only without an explicit command
to do so. Trying to write to the entire *drive* after that doesn't
work (e.g. touching a temp file)
I have to unmount and remount to regain write privileges and just
leave those files alone. I'm copying out what I can and will then
format the drive, unless I get a better suggestion.
Andrew Halliwell
> fsck doesn't work. It reports the file system as read only.
>
> If I try to touch those corrupted files (with fsck, mv, rm, etc.), the
> file system seems to change to read only without an explicit command
> to do so. Trying to write to the entire *drive* after that doesn't
> work (e.g. touching a temp file)
You should never run fsck on a filesystem that's mounted. Nasty things can
happen if some process is accessing files when fsck is checking or repairing
something.
It's best to run fsck from init 1 or init S after unmounting all possible
filesystems... Or from a rescue CD like knoppix where nothing on the hard
disk is mounted.
--
| spi...@freenet.co.uk | Windows95 (noun): 32 bit extensions and a |
| | graphical shell for a 16 bit patch to an 8 bit |
| Andrew Halliwell BSc | operating system originally coded for a 4 bit |
| in |microprocessor, written by a 2 bit company, that|
| Computer Science | can't stand 1 bit of competition. |
Tim Greer
Drop into runlevel 1 or run fsck on bootup, before the file
system/partition is mounted. While it is mounted, you can also run
badblocks in a safe way, too. Do your messages or dmesg logs show
anything interesting (any errors)?
--
Tim Greer, CEO/Founder/CTO, BurlyHost.com, Inc.
Shared Hosting, Reseller Hosting, Dedicated & Semi-Dedicated servers
and Custom Hosting. 24/7 support, 30 day guarantee, secure servers.
Industry's most experienced staff! -- Web Hosting With Muscle!
Amaranth
localhost:/var/log # grep REISER messages > temp
localhost:/var/log # wc temp
1039 21287 151889 temp
localhost:/var/log # tail -10 temp
Mar 9 21:29:01 localhost kernel: REISERFS error (device sdb1):
vs-13070 reiserfs_read_locked_inode: i/o failure occurred trying to
find stat data of [1795642 3054312 0x0 SD]
Mar 9 21:29:01 localhost kernel: REISERFS warning: reiserfs-5090
is_tree_node: node level 39463 does not match to the expected one 1
Mar 9 21:29:01 localhost kernel: REISERFS error (device sdb1):
vs-5150 search_by_key: invalid format found in block 145753976. Fsck?
Mar 9 21:29:01 localhost kernel: REISERFS error (device sdb1):
vs-13070 reiserfs_read_locked_inode: i/o failure occurred trying to
find stat data of [1795642 3054313 0x0 SD]
Mar 9 21:29:01 localhost kernel: REISERFS warning: reiserfs-5090
is_tree_node: node level 39463 does not match to the expected one 1
Mar 9 21:29:01 localhost kernel: REISERFS error (device sdb1):
vs-5150 search_by_key: invalid format found in block 145753976. Fsck?
Mar 9 21:29:01 localhost kernel: REISERFS error (device sdb1):
vs-13070 reiserfs_read_locked_inode: i/o failure occurred trying to
find stat data of [1795642 3054314 0x0 SD]
Mar 9 21:29:01 localhost kernel: REISERFS warning: reiserfs-5090
is_tree_node: node level 39463 does not match to the expected one 1
Mar 9 21:29:01 localhost kernel: REISERFS error (device sdb1):
vs-5150 search_by_key: invalid format found in block 145753976. Fsck?
Mar 9 21:29:01 localhost kernel: REISERFS error (device sdb1):
vs-13070 reiserfs_read_locked_inode: i/o failure occurred trying to
find stat data of [1795642 3054315 0x0 SD]
Amaranth
Alright thanks. I unmounted it and did a fsck -y. It fixed some
problems, but it suggested I go to --rebuild-tree, which I am doing
now.
Any ideas if it is a duff hard drive (Samsung Spinpoint 1TB) or me
trying to copy stuff onto a full hard drive?
Tim Greer
<please don't quote signatures>
I hope your repair can allow you access to the data, so you can copy it
somewhere safe, unless you already have a current backup (if not, copy
over the most valuable data first and then try and grab the rest,
prioritizing), because the drive could be going. I'd run some drive
tests as well as badblocks if things appear okay, but depending on how
wide spread the corruption is, it's probably not just an
application/process that went haywire.
Be sure to check dmesg for current errors as well. Hope for the best,
plan for the worst (I've had brand new drives fail as I was just
formatting them after installing them minutes before, so you never know
how much time you have before things start going badly, and they can go
very badly very fast.)
The Natural Philosopher
well there is your problem.
Reiser file systems have a notorious history of doing exactly what yours
has done.
Especially if e.g. you get a power failure during a write.
I don't know why - google it - but when investigating what system to use
on a new machine, I came up with enough negative comment to make me
never ever contemplate using it.
Amaranth
dmesg looks fine - nothing untoward I have spotted, but I'll keep my
eye on it.
localhost:/media/SAM_1TB # dmesg | grep sdb
sd 2:0:0:0: [sdb] 1953525168 512-byte hardware sectors: (1000GB/
931GiB)
sd 2:0:0:0: [sdb] Write Protect is off
sd 2:0:0:0: [sdb] Mode Sense: 00 3a 00 00
sd 2:0:0:0: [sdb] Write cache: enabled, read cache: enabled, doesn't
support DPO or FUA
sd 2:0:0:0: [sdb] 1953525168 512-byte hardware sectors: (1000GB/
931GiB)
sd 2:0:0:0: [sdb] Write Protect is off
sd 2:0:0:0: [sdb] Mode Sense: 00 3a 00 00
sd 2:0:0:0: [sdb] Write cache: enabled, read cache: enabled, doesn't
support DPO or FUA
sdb: sdb1
sd 2:0:0:0: [sdb] Attached SCSI disk
REISERFS (device sdb1): found reiserfs format "3.6" with standard
journal
REISERFS (device sdb1): using ordered data mode
REISERFS (device sdb1): journal params: device sdb1, size 8192,
journal first block 18, max trans len 1024, max batch 900, max commit
age 30, max trans age 30
REISERFS (device sdb1): checking transaction log (sdb1)
REISERFS (device sdb1): Using r5 hash to sort names
localhost:/media/SAM_1TB #
How do I copy files from this hard drive only if they are unique, and
keep the destination files even if they are older?
Thanks for your help.
Amaranth
> dmesg looks fine - nothing untoward I have spotted, but I'll keep my
Oops, sorry for quoting your sig.
Amaranth
> well there is your problem.
>
> Reiser file systems have a notorious history of doing exactly what yours
> has done.
>
> Especially if e.g. you get a power failure during a write.
>
> I don't know why - google it - but when investigating what system to use
> on a new machine, I came up with enough negative comment to make me
> never ever contemplate using it.
Yes, I've just found a few anecdotes and personal opinions that state
ext3 is more robust but Reiser is faster and takes less space for many
small files. I haven't found any rigorous studies that state this is
so (yet) though.
How do I painlessly change file systems from Reiser to ext3? :-(
The Natural Philosopher
strip the data off, to somewhere else, and reformat the drive.
If you really have a lot of tiny pieces of data, consider building a
database app to hold them..
Tim Greer
> How do I copy files from this hard drive only if they are unique, and
> keep the destination files even if they are older?
>
Check out rsync, it does all the stuff you need.
Tim Greer
Oh, no problem at all. Thanks.