Re: Filesystem corruption
[resending, because lncsa.com bounced my mail] On Mon, 28 May 2007, Christian Kujau wrote: On Sun, 27 May 2007, Laurent CARON wrote: The entry that scares me is ?- ? ? ??? new Seems to me it is a filesystem corruption. Any other solution than rebuild-tree ? Please try to check the fs with a current version of reiserfsprogs first. As the manpage advises, try --check first and use --rebuild-tree only if you know what you're doing, IOW: have a current backup. Also, which kernel/machine is this running on? Do you know *why* this corruption may have occured? Any recent hardware issues? Is ther anything in the logs regarding fs/device errors? C. -- BOFH excuse #448: vi needs to be upgraded to vii
Re: Filesystem corruption
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On Mon, 28 May 2007, Laurent CARON wrote: Always ran check which told me to run fix-fixable or rebuild-tree, which I did after ensuring of backup reliability, and the error was corrected (after eventually losing a few files i fortunately had in the backups). Well, lucky you :) The machine does not seem to have any HW issue, nothing strange in the logs. :$ This is just a plain Dell 2650 server with a bunch of SCSI HDD, software raid5 array, reiserfs on top of it. ...and no power-failures, bad memory whatsoever? Hm, too bad, since now it's unclear what *caused* the corruptions in the first place. You'll probably (hopefully) be able to correct this corruption with --rebuild-tree but I'd have a close look on this filesystem for further curruptions. Christian. - -- BOFH excuse #118: the router thinks its a printer. -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.6 (GNU/Linux) iD8DBQFGW2N/+A7rjkF8z0wRAg9yAJ9PgWYfv1KC1Z3o/cVXScqxTYDPfwCdHKDD Wy3p1M9ODJFfuqn0JaCEu8U= =uCAH -END PGP SIGNATURE-
Re: Stacktrace when reading the build-fs partition....
On Mon, 18 Dec 2006, Clemens Eisserer wrote:
When reading some of the file on the partition that was rescued with
--build-fs, I got a stacktrace two times.
So, it does only happen on the partition that was rescued with
--build-fs, not on a fresh mkfs'ed partition?
Dec 18 14:29:32 localhost kernel:
Dec 18 14:29:32 localhost kernel: reiser4[kio_file(3006)]:
dc_check_checksum
(fs/reiser4/plugin/file/cryptcompress.c:996)[edward-156]:
Dec 18 14:29:32 localhost kernel: WARNING: Bad disk cluster checksum
-41760589, (should be 1098063193) Fsck?
might be tricky to set this up, but: would it be posssible to recreate
the scenario withouth the cryptcompress plugin? i.e. 'mkfs.reiser4' a
partition, 'reiser4fsck --build-fs' and see if it happens again?
If so, we could rule out that the plugin is responsible for this mess.
Tainted: PF VLI
...oh, and perhaps with an untained kernel too? And while we're at it:
maybe CONFIG_REISER4_DEBUG {w|c}ould reveal even more details. But then
again: I'm not a reiser-hacker, so I can't comment on these traces
anyway :(
Dec 18 14:29:32 localhost kernel: EFLAGS: 00010246 (2.6.19-rc4-mm1-default
#2)
Have you tried 2.6.20-rc1-mm1 yet?
my 0.02p...
Christian
--
BOFH excuse #102:
Power company testing new voltage spike (creation) equipment
Re: Possible interference between reiser4 and usb-storage?
On Sun, 19 Nov 2006, Clemens Eisserer wrote: am using cryptocompress with the 2.6.19rc4 kernel and after some time df reports something like: ...after some time, so right after mkfs df(1) is telling the truth? Does it drop to 52MB all of a sudden or does it decrease slowly? does it happen with other/former kernels too? /dev/sda1 55068032 32996604 22071428 60% /mnt (1GB flash storage) however sda1 is a 1gb usb storage device!! What does fdisk say? Could that be because I compiled the kernel with -O3? Does it happen without the tweak? Why are you using -O3 anyway, does it really make a difference? Christian. -- BOFH excuse #400: We are Microsoft. What you are experiencing is not a problem; it is an undocumented feature.
Re: Segfault mounting a reiserfs 3.6 partition
On Thu, 19 Oct 2006, Edward Shishkin wrote: would you please upgrade your kernel to the latest stable version (2.6.18) and try to mount again. While I'm happy that Christophe can access his data with the latest kernel, did you have any special in mind when you suggested to upgrade from 2.4.20 or 2.6.13 (apart from the fact that both kernels are quite old)? Thanks, Christian. -- BOFH excuse #257: That would be because the software doesn't work.
Re: Read only rootfs after reiserfsck
Paolo Azzaroli wrote: Delete all lines in /etc/mtab which reference filesystems other than your root partition. That should fix it. Dear Sir:, I apreciated Your suggestion, I tried it, but it doesn't fix my problem. please try to post your issued commands here, say $ mount /proc $ rm /etc/mtab $ cat /proc/mounts $ $MOUNT-COMMANDS ...and error messages, partition tables. Christian. -- BOFH excuse #185: system consumed all the paper for paging
vpf-10680 patch not in 2.5.74?
hi, the patch from Oleg that fixes this odd vpf-10680 issue on 64bit archs is not in 2.5.74 it seems, at least there is no entry in the Changelog. will it get in in 2.5.75 probably? Thanks, Christian. -- BOFH excuse #210: We didn't pay the Internet bill and it's been cut off.
Re: vpf-10680, minor corruptions
Oleg Drokin schrieb: I have traced the new problem to a cross compiler that compiles code in a different way than native compiler for whatever reason (demo is attached as test.c program, it should print result is 1 yes, that what it prints, no warnings were shown. You might try that patch as well to see if it helps you before I try it ;) yes, compiling with _this_ patch but _not_ with the last patch you sent (file.c) is under way again... Thank you, Christian.
Re: vpf-10680, minor corruptions
Oleg Drokin schrieb: I have traced the new problem to a cross compiler that compiles code in a different way than native compiler for whatever reason (demo is attached as test.c program, it should print result is 1 yes, that what it prints, no warnings were shown. You might try that patch as well to see if it helps you before I try it ;) yes, compiling with _this_ patch but _not_ with the last patch you sent (file.c) is under way again... Thank you, Christian.
Re: vpf-10680, minor corruptions
Oleg Drokin schrieb: Try to compile with CONFIG_REISERFS_CHECK=y the kernel that known-bad for you. (e.g. 2.5.72/2.5.73) yes, 2.5.72 with CONFIG_REISERFS_CHECK=y is compiling now. over night the alpha finished compiling 2.5.65 and 2.5.69. i had to compile reiserfs statically, inserting modules gave these Invalid module format errors. under both (2.5.65+2.5.69) i was able to mkreiserfs sde2. mounting the fs went ok, but copying data (cp -a /lib /mnt/reiserfs) brought several kernel-errors (see https://ephigenie.kicks-ass.net/browse/reiserfs/). but: diff -r showed _no_ differences betweeen the directories, a following reiserfsck brought no vpf-10680 anymore! so i'd say the problem occurs somewhere between 2.5.69 and 2.5.70. thanks, Christian.
Re: vpf-10680, minor corruptions
Christian Kujau schrieb: of course, the best thing i can do is the el-cheapo-hacking approach: compiling 2.5.60...up to 2.5.72 and see *when* it breaks. hm, compiling a 2.5 kernel takes 180min on this machine. but anyway, i'll start with 2.5.60 now, see what it gives. no, i started with 2.5.66 but the kernel did not compile. 2.5.65 did compile (don't ask how long) and has already booted. but trying to mount the newly created reiserfs gives: module reiserfs: Relocation overflow vs section 9 in the log. the reiserfs module was not loaded. modprobe reiserfs gives: lila:~# modprobe reiserfs FATAL: Error inserting reiserfs (/lib/modules/2.5.65/kernel/fs/reiserfs/reiserfs.ko): Invalid module format lila:~# uname -a Linux lila 2.5.65 #4 Wed Jun 25 00:48:46 CEST 2003 alpha GNU/Linux i compiled the module with CONFIG_REISERFS_CHECK=y. shall i go on with 2.5.64 or better 2.5.67 ? good night, Christian.
Re: vpf-10680, minor corruptions
Oleg Drokin schrieb: Hm, interesting. Do you had crashes/unexpected shutdowns before corruptions appears or are they appear without any reason at all? i had this issue once before -- did a check and noticed vpf-10680/some corruptions. but these must have been from an crash. but now, i think as i rebooted the machine yesterday (because i upgraded to kernel 2.5.72) the journal was checked (replayed?) anyway at boot: found reiserfs format 3.6 with standard journal Reiserfs journal params: device sde2, size 8192, journal first block 18, max trans len 1024, max batch 900, max commit age 30, max trans age 30 reiserfs: checking transaction log (sde2) for (sde2) Using r5 hash to sort names (from dmesg, booting process) and i thought the fs is O.K. at least after boot, because ReiserFS cares about consistency for itsself. if not, the corruptions are likely from the unclean shutdowns. but that would mean, that i still have to manually reiserfsck from time to time. btw, is there a switch like Maximum mount counft before doing the next fsck while booting? Well, I guess it's time to clear the dust off our alpha and do some testing. hehe, should it be architecture related? Thank you, Christian.
