Re: stale dk warning
Hello, shouldnt we also remove the warning [nikita-33281] ? Jan 25 14:48:29 bones kernel: 4reiser4[ent:hda8!(5047)]: capture_anonymous_jno des (fs/reiser4/plugin/file/file.c:1348)[nikita-33281]: Jan 25 14:48:29 bones kernel: WARNING: anonymous jnode in writeback: (69954 2216 63) Jan 25 14:48:29 bones kernel: Jan 25 14:48:29 bones kernel: 4reiser4[ent:hda8!(5047)]: capture_anonymous_jno des (fs/reiser4/plugin/file/file.c:1348)[nikita-33281]: Jan 25 14:48:29 bones kernel: WARNING: anonymous jnode in writeback: (69954 2216 64) Thanks, Lena Hans Reiser wrote: Hans Reiser wrote: Vladimir V. Saveliev wrote: Hello On Fri, 2006-01-20 at 14:28 -0600, Jake Maciejewski wrote: In addition to the disable write barrier warning reported by Louis-David Mitterrand on January 10th, with 2.6.15-1 I'm getting: 4reiser4[dd(25448)]: update_stale_dk (fs/reiser4/search.c:1363)[nikita-38210]: WARNING: stale dk The process varies. I've also seen the stale dk warning triggered by rsync and rm. This is harmless. I think we should remove this warning as well as the one about write barrier. Zam said he would change it by it I refer to the write barrier warning, sorry for my imprecision to a notice. Zam, what happened to the patch?
Re: reiser4 warning?
Hello. Louis-David Mitterrand wrote: Hello, When rebooting a server I catched this in the logs: Jan 10 18:13:55 zenon kernel: 4reiser4[apache-perl(6359)]: disable_write_barrier (fs/reiser4/wander.c:233)[zam-1055]: Jan 10 18:13:55 zenon kernel: WARNING: disabling write barrier Is it bad? No. You may ignore this warning. Thanks, Lena. (using 2.6.14 patch)
Re: Collect data?
Sander wrote: E.Gryaznova wrote (ao): Sander wrote: # echo foo /boot/test # time vim +s/foo/bar/ +wq /boot/test real0m0.016s user0m0.000s sys 0m0.000s # echo foo /root/test # time vim +s/foo/bar/ +wq /root/test real0m9.667s user0m0.000s sys 0m0.020s /dev/hda2 on / type reiser4 (rw) /dev/hda1 on /boot type ext2 (rw) Yes, thank you. Which iosched do you use? 'deadline': $ cat /sys/block/hda/queue/scheduler noop anticipatory [deadline] cfq Would you please repeat the vim/reiser4 test for each iosched and send us the time values? As others already reacted with data regarding this test I assume you don't need my data anymore. not right. We _need_ your data for bad system. Thanks, Lena I understand this problem must be quite annoying for the Reiserfs team as you can't reproduce it. In my case it also only happens on one system, and not on another. Maybe we can collect data? I'm happy to set up a page with 'good' and 'bad' configurations. Any suggestions as to what you need? My 'good' system: kernel: 2.6.15-rc1-mm2 OS: Debian Sid disks: 4x sata on Promise raid/lvm/etc: lmv stripe My 'bad' system: kernel: 2.6.15-rc1-mm1 OS: Debian Sid disks: ata on nForce2 raid/lvm/etc: none, single disk
Re: More Slowdown or reiser4 update for 2.6.14-mm2
Sander wrote: E.Gryaznova wrote (ao): Unfortunately we are not able to reproduce this slowdown. Would you please provide more info?: FWIW, I notice the same (I'm not the OP). My main workstation (Athlon) runs 2.6.15-rc1-mm1. Vim needs 4 to 12 seconds to close any file, mutt is very slow on sending email, backups take several hours and in general anything done on the filesystem seems slow. This system has one IDE disk. Scrips are locked when vim closes and bash/perl complain when they try to read/execute the script. The strange thing is that another system running 2.6.15-rc1-mm2 does not have this slowdown. There are no Reiser4 updates in -mm2 AFAICS. This system is a Via Epia with Reiser4 on lvm2 on 4xSATA. Is this 2.6.14-mm2 bad sync/fsync performance reproducible on fresh created reiser4 too? I'll try. Are these values stable reproducible? If you run this test several time -- do you have the same results? Vim is always very slow on close (:wq) for me. Would you please send df -T output # df -T / FilesystemType 1K-blocks Used Available Use% Mounted on /dev/hda2 reiser4 232423180 166976448 65446732 72% / and 2.6.14-mm2 config file? 2.5.16-rc1-mm1 below. Did you try this test on ext2? If no -- would you please try it on ext2 for the same kernels and send us the results? If I open and edit a file on /boot, which is ext2 on hda1, vim reacts as expected. Quick and without a single delay. # echo foo /boot/test # time vim +s/foo/bar/ +wq /boot/test real0m0.016s user0m0.000s sys 0m0.000s # echo foo /root/test # time vim +s/foo/bar/ +wq /root/test real0m9.667s user0m0.000s sys 0m0.020s /dev/hda2 on / type reiser4 (rw) /dev/hda1 on /boot type ext2 (rw) Anything I can do to help? Yes, thank you. Which iosched do you use? Would you please repeat the vim/reiser4 test for each iosched and send us the time values? Something like for i in cfq noop anticipatory deadline do echo $i /sys/block/hda/queue/scheduler cat /sys/block/hda/queue/scheduler echo foo /root/test time vim +s/ foo/bar/ +wq /root/test done Thanks, Lena # # IO Schedulers # CONFIG_IOSCHED_NOOP=y CONFIG_IOSCHED_AS=y CONFIG_IOSCHED_DEADLINE=y CONFIG_IOSCHED_CFQ=y # CONFIG_DEFAULT_AS is not set CONFIG_DEFAULT_DEADLINE=y # CONFIG_DEFAULT_CFQ is not set # CONFIG_DEFAULT_NOOP is not set CONFIG_DEFAULT_IOSCHED=deadline
Re: More Slowdown or reiser4 update for 2.6.14-mm2
Hello. Hesse, Christian wrote: On Thursday 17 November 2005 18:22, Vladimir V. Saveliev wrote: Hello Hesse, Christian wrote: Vladimir V. Saveliev wrote: Please try whether the attached patch improves anything. It simplifies fsync by avoid commiting of transactions which do not modify file being fsync-ed. The patch applied to 2.6.14-mm2 with warnings, but that can be ignored. Hi everybody, I'm suffering the same problem, sync and fsync are horribly slow. I've written a small test program: http://www.earthworm.de/tmp/reiser4-fsync.c with 2.6.13: sync() = 0 0.000198 fsync(3)= 0 0.003353 with 2.6.14 (with and without patch): sync() = 0 2.092873 fsync(3)= 0 0.132579 I tried your test on a box with reiser4 root fs: 2.6.13: strace -T -e sync,fsync ./eworm xx fsync(3)= 0 0.158808 2.6.14-mm2 + ftp://ftp.namesys.com/pub/reiser4-for-2.6/2.6.14-mm2/reiser4-for-2.6.14-mm2 -1.patch.gz strace -T -e sync,fsync ./eworm xx fsync(3)= 0 0.005373 Would you please try whether 2.6.14-mm2 with fresh reiser4 update fsyncs better? No change, still bad performance: up to 2 seconds in sync(), up to 0.2 seconds in fsync(). Unfortunately we are not able to reproduce this slowdown. Would you please provide more info?: Is this 2.6.14-mm2 bad sync/fsync performance reproducible on fresh created reiser4 too? Are these values stable reproducible? If you run this test several time -- do you have the same results? Would you please send df -T output and 2.6.14-mm2 config file? Did you try this test on ext2? If no -- would you please try it on ext2 for the same kernels and send us the results? Thanks, Lena
reiser4progs do not handle the reiser4 format changes
Notification: The reiser4 format was changed in reiser4-for-2.6.11-5.patch and new reiser4 kernel code is able to handle the old format. The reiser4progs-1.0.4 are not able to handle the format changes. The fix for reiser4progs will be ready next week. Thanks, Lena
Re: reiser4 patches for 2.6.12
Hello. reiser4 patch for 2.6.12 is not ready yet. All available reiser4 patches are in ftp://ftp.namesys.com/pub/reiser4-for-2.6 Thanks, Lena. David Arendt wrote: Hi, I just wanted to know if there are currently patches for 2.6.12 available and if not when they will be approximately be available as I am forced to upgrade to 2.6.12 due to an usb problem. Thanks in advance Bye, David Arendt
Re: hard hang with reiser4-for-2.6.11-5 and VMware Workstation 5.0
Hello. Thank you for the report. VMWare/reiser4 is known problem, we can reproduce it. But unfortunately I can't estimate when this will be fixed. Reiser4 format was changed in reiser4-5 patch for 2.6.11, reiser4progs for this format are not ready yet. Thanks, Lena scott wrote: Greetings, I have been using Reiser4 as my primary filesystem for some time now, and for the first time have encountered a problem that keeps me from doing what I want to do. I run VMware Workstation 5.0 with the virtual disk files on my Reiser4 / partition, which happens to be a Linux md RAID1 device. The other day I built a new kernel, upgrading to the -5 release of the reiser4 patches. Either during boot or shortly after boot of any guest OS, my workstation becomes totally unresponsive. Magic SysRq keys don't even work. To narrow down the source of the problem, I applied the Reiser4 patch to a vanilla 2.6.11 kernel tree. I saw the exact same issue. I tried reverting to a previous version of the Reiser4 patch, but I get VFS errors about being unable to find a Reiser4 filesystem on my rootdisk using any other Reiser4 patchset. Did the filesystem format change? I tried recompiling the -5 release with debug enabled, but since the machine is unresponsive, I don't see any output. My question... is this a known issue? Or should I just keep pounding away at this until I can get some sort of debugging information? Thanks to you all for the always-interesting discussion threads on this list. And thanks, Hans, for reiserfs and reiser4. be seeing you. scott Yahoo! Sports Rekindle the Rivalries. Sign up for Fantasy Football http://football.fantasysports.yahoo.com
Re: reiser4 panicked cowardly: assertion failed: hint-blk reiser4_block_count(super)
Hello. Do you have more than one mounted reiser4 partition? Thanks, Lena Adrian Ulrich wrote: Hi, Well, i managed to crash reiser4 ;-) I created an iso-image on my reiser4 filesystem (it's my rootfs) using mkisofs. mkisofs aborted because the filesystem was full. After freeing up some space, i ran mkisofs again and: *bam* fsck.reiser4 told me to run '--rebuild-sb' but looks like it didn't help: The System still crashes while creating the ISO (Should be 4.1 GiB, but crashes at ~ 3.7 GiB..) # fsck.reiser4 --version fsck.reiser4 1.0.4 Copyright (C) 2001, 2002, 2003, 2004 by Hans Reiser, licensing governed by reiser4progs/COPYING. # uname -a Linux fuzzy 2.6.11.10 #1 SMP Sat May 21 13:17:21 CEST 2005 i686 unknown unknown GNU/Linux * I attached the Syslog output * I rand 'debugfs.reiserf -P $device' and can provide the output to namesys if they need it (9.3 MiB) Jun 5 15:59:23 fuzzy kernel: Linux version 2.6.11.10 ([EMAIL PROTECTED]) (gcc version 3.3.4) #1 SMP Sat May 21 13:17:21 CEST 2005 Jun 5 15:59:23 fuzzy kernel: BIOS-e820: - 0009fc00 (usable) Jun 5 15:59:23 fuzzy kernel: BIOS-e820: 0009fc00 - 000a (reserved) Jun 5 15:59:23 fuzzy kernel: BIOS-e820: 000e6000 - 0010 (reserved) Jun 5 15:59:23 fuzzy kernel: BIOS-e820: 0010 - 3fe3 (usable) Jun 5 15:59:23 fuzzy kernel: BIOS-e820: 3fe3 - 3fe414a0 (ACPI NVS) Jun 5 15:59:23 fuzzy kernel: BIOS-e820: 3fe414a0 - 3ff3 (usable) Jun 5 15:59:23 fuzzy kernel: BIOS-e820: 3ff3 - 3ff4 (ACPI data) Jun 5 15:59:23 fuzzy kernel: BIOS-e820: 3ff4 - 3fff (ACPI NVS) Jun 5 15:59:23 fuzzy kernel: BIOS-e820: 3fff - 4000 (reserved) Jun 5 15:59:23 fuzzy kernel: BIOS-e820: fecf - fecf1000 (reserved) Jun 5 15:59:23 fuzzy kernel: BIOS-e820: fed2 - feda (reserved) Jun 5 15:59:23 fuzzy kernel: Processor #0 15:2 APIC version 20 Jun 5 15:59:23 fuzzy kernel: Processor #1 15:2 APIC version 20 Jun 5 15:59:23 fuzzy kernel: IOAPIC[0]: apic_id 2, version 32, address 0xfec0, GSI 0-23 Jun 5 15:59:23 fuzzy kernel: Enabling APIC mode: Flat. Using 1 I/O APICs Jun 5 15:59:23 fuzzy kernel: Allocating PCI resources starting at 4000 (gap: 4000:becf) Jun 5 15:59:23 fuzzy kernel: Built 1 zonelists Jun 5 15:59:23 fuzzy kernel: Kernel command line: root=/dev/md1 sbp2_serialize_io=1 sbp2_max_speed=2 Jun 5 15:59:23 fuzzy kernel: PID hash table entries: 4096 (order: 12, 65536 bytes) Jun 5 15:59:23 fuzzy kernel: Detected 2992.449 MHz processor. Jun 5 15:59:23 fuzzy kernel: Console: colour VGA+ 80x25 Jun 5 15:59:23 fuzzy kernel: Dentry cache hash table entries: 131072 (order: 7, 524288 bytes) Jun 5 15:59:23 fuzzy kernel: Inode-cache hash table entries: 65536 (order: 6, 262144 bytes) Jun 5 15:59:23 fuzzy kernel: Checking if this processor honours the WP bit even in supervisor mode... Ok. Jun 5 15:59:23 fuzzy kernel: Mount-cache hash table entries: 512 (order: 0, 4096 bytes) Jun 5 15:59:23 fuzzy kernel: CPU0: Intel(R) Pentium(R) 4 CPU 3.00GHz stepping 09 Jun 5 15:59:23 fuzzy kernel: per-CPU timeslice cutoff: 1462.91 usecs. Jun 5 15:59:23 fuzzy kernel: task migration cache decay timeout: 2 msecs. Jun 5 15:59:23 fuzzy kernel: Booting processor 1/1 eip 3000 Jun 5 15:59:23 fuzzy kernel: CPU1: Intel(R) Pentium(R) 4 CPU 3.00GHz stepping 09 Jun 5 15:59:23 fuzzy kernel: ENABLING IO-APIC IRQs Jun 5 15:59:23 fuzzy kernel: Brought up 2 CPUs Jun 5 15:59:23 fuzzy kernel: ACPI-1138: *** Error: Method execution failed [\MCTH] (Node c191ee60), AE_AML_BUFFER_LIMIT Jun 5 15:59:23 fuzzy kernel: ACPI-1138: *** Error: Method execution failed [\OSFL] (Node c191e540), AE_AML_BUFFER_LIMIT Jun 5 15:59:23 fuzzy kernel: ACPI-1138: *** Error: Method execution failed [\_SB_.PCI0.SBRG.PS2M._STA] (Node c193c2a0), AE_AML_BUFFER_LIMIT Jun 5 15:59:23 fuzzy kernel: ACPI-0158: *** Error: Method execution failed [\_SB_.PCI0.SBRG.PS2M._STA] (Node c193c2a0), AE_AML_BUFFER_LIMIT Jun 5 15:59:23 fuzzy kernel: PCI: Probing PCI hardware (bus 00) Jun 5 15:59:23 fuzzy kernel: ACPI-1138: *** Error: Method execution failed [\MCTH] (Node c191ee60), AE_AML_BUFFER_LIMIT Jun 5 15:59:23 fuzzy kernel: ACPI-1138: *** Error: Method execution failed [\OSFL] (Node c191e540), AE_AML_BUFFER_LIMIT Jun 5 15:59:23 fuzzy kernel: ACPI-1138: *** Error: Method execution failed [\_SB_.PCI0.SBRG.PS2M._STA] (Node c193c2a0), AE_AML_BUFFER_LIMIT Jun 5 15:59:23 fuzzy kernel: ACPI: PCI Interrupt Link [LNKA] (IRQs 3 4 5 6 7 9 10 *11 12 14 15) Jun 5 15:59:23 fuzzy kernel: ACPI: PCI Interrupt Link [LNKB] (IRQs 3 4 5 6 7 9 *10 11 12 14 15) Jun 5 15:59:23 fuzzy kernel: ACPI: PCI Interrupt Link [LNKC] (IRQs 3 4 5 6 7 *9 10 11 12
Re: reiser4 panicked cowardly: assertion failed: hint-blk reiser4_block_count(super)
Adrian Ulrich wrote: Hi, Well, i managed to crash reiser4 ;-) I created an iso-image on my reiser4 filesystem (it's my rootfs) using mkisofs. mkisofs aborted because the filesystem was full. After freeing up some space, i ran mkisofs again and: *bam* fsck.reiser4 told me to run '--rebuild-sb' but looks like it didn't help: The System still crashes while creating the ISO (Should be 4.1 GiB, but crashes at ~ 3.7 GiB..) # fsck.reiser4 --version fsck.reiser4 1.0.4 Copyright (C) 2001, 2002, 2003, 2004 by Hans Reiser, licensing governed by reiser4progs/COPYING. # uname -a Linux fuzzy 2.6.11.10 #1 SMP Sat May 21 13:17:21 CEST 2005 i686 unknown unknown GNU/Linux what reiser4 patch do you use for this kernel? Thanks, Lena * I attached the Syslog output * I rand 'debugfs.reiserf -P $device' and can provide the output to namesys if they need it (9.3 MiB)
Re: Do a bad block check on a lvm with reiserfs
Hello. Would you please send me the output of # lvdisplay --maps # pvdisplay --maps Thanks, Lena Matthias Barremaecker wrote: Hi, If I check my lvm partition, then I have bad blocks. To know what hd there's bad, I have to check the hd's seperatly. but what do i check and do I use the reiserfs block size (4096bytes) ? do I use /dev/hda or /dev/hda1 ? thanx. kind regardes, Matthias.
Re: extract files without mounting a partition?
Hello. Would you please send us the following : 1. # cat /proc/mdstat 2. the raid configuration file wich you used for creating this md0? Thanks, Lena Deepak Ram wrote: On Monday 06 June 2005 14:04, you wrote: Hello On Mon, 2005-06-06 at 10:00, R Deepak wrote: Greets! Can I ask support questions here? If not, sorry.. :( I have a RAID0 config with 2 80GB SATA disks. I screwed up during an install and the super block got overwritten. When I ran reiserfsck on /dev/md0, it asked me to use --rebuild-sb Which I did. It reported quite a few errors and moved lots of files to lost+found. Now the problem is that I am not able to mount this partition. I've tried with different kernels, gentoo 2005.0 live CD (amd64), knoppix (32bit), and an old gentoo 2004.1 (x86) live CD. As soon as I try to mount it, I get something like the following ReiserFS: md0: found reiserfs format 3.6 with standard journal kernel panic There should be more than that. Can you please show all kernel logs related to the problem. There is.. I'll have to write it down since everything freezes. Will send the whole thing as soon as I get back home. You should use either serial console or netconsole to catch kernel logs in case when they do not manage to not get written to log files. You can read linux/Documentation/serial-console.txt and linux/Documentation/networking/netconsole.txt about those things. 've attached the dmesg output and the output of debugreiserfs /dev/md0. Should I send you something else? One correction though.. the system didn't freeze. There was just an oops. Please help.. Regards Deepak gt64 root # debugreiserfs /dev/md0 debugreiserfs 3.6.19 (2003 www.namesys.com) Filesystem state: consistent Reiserfs super block in block 2 on 0x900 of format 3.6 with standard journal Count of blocks on the device: 39074048 Number of bitmaps: 1193 Blocksize: 4096 Free blocks (count of blocks - used [journal, bitmaps, data, reserved] blocks): 8088863 Root block: 30086 Filesystem is clean Tree height: 5 Hash function used to sort names: r5 Objectid map size 972, max 972 Journal parameters: Device [0x0] Magic [0x7e8f0ae8] Size 8193 blocks (including 1 for journal header) (first block 1196) Max transaction length 1024 blocks Max batch size 900 blocks Max commit age 30 Blocks reserved by journal: 0 Fs state field: 0x0: sb_version: 2 inode generation number: 25219262 UUID: 2234f94c-a9be-46ec-9bb7-018a53f424b4 LABEL: Set flags in SB: ATTRIBUTES CLEAN Bootdata ok (command line is root=/dev/hda2 vga=9) Linux version 2.6.11-gentoo-r9 ([EMAIL PROTECTED]) (gcc version 3.4.3 20041125 (Gentoo Linux 3.4.3-r1, ssp-3.4.3-0, pie-8.7.7)) #1 Sun Jun 5 11:03:09 IST 2005 BIOS-provided physical RAM map: BIOS-e820: - 0009fc00 (usable) BIOS-e820: 0009fc00 - 000a (reserved) BIOS-e820: 000e4000 - 0010 (reserved) BIOS-e820: 0010 - 3ff3 (usable) BIOS-e820: 3ff3 - 3ff4 (ACPI data) BIOS-e820: 3ff4 - 3fff (ACPI NVS) BIOS-e820: 3fff - 4000 (reserved) BIOS-e820: fff8 - 0001 (reserved) ACPI: RSDP (v002 ACPIAM) @ 0x000faac0 ACPI: XSDT (v001 A M I OEMXSDT 0x08000403 MSFT 0x0097) @ 0x3ff30100 ACPI: FADT (v003 A M I OEMFACP 0x08000403 MSFT 0x0097) @ 0x3ff30290 ACPI: MADT (v001 A M I OEMAPIC 0x08000403 MSFT 0x0097) @ 0x3ff30390 ACPI: OEMB (v001 A M I OEMBIOS 0x08000403 MSFT 0x0097) @ 0x3ff40040 ACPI: DSDT (v001 A0091 A0091006 0x0006 MSFT 0x010d) @ 0x On node 0 totalpages: 261936 DMA zone: 4096 pages, LIFO batch:1 Normal zone: 257840 pages, LIFO batch:16 HighMem zone: 0 pages, LIFO batch:1 ACPI: Local APIC address 0xfee0 ACPI: LAPIC (acpi_id[0x01] lapic_id[0x00] enabled) Processor #0 15:12 APIC version 16 ACPI: IOAPIC (id[0x01] address[0xfec0] gsi_base[0]) IOAPIC[0]: apic_id 1, version 3, address 0xfec0, GSI 0-23 ACPI: INT_SRC_OVR (bus 0 bus_irq 0 global_irq 2 dfl dfl) ACPI: IRQ0 used by override. ACPI: IRQ2 used by override. ACPI: IRQ9 used by override. Setting APIC routing to flat Using ACPI (MADT) for SMP configuration information Checking aperture... CPU 0: aperture @ e000 size 256 MB Built 1 zonelists Kernel command line: root=/dev/hda2 vga=9 console=tty0 Initializing CPU#0 PID hash table entries: 4096 (order: 12, 131072 bytes) time.c: Using 1.193182 MHz PIT timer. time.c: Detected 1802.347 MHz processor. Console: colour VGA+ 132x44 Dentry cache hash table entries: 262144 (order: 9, 2097152 bytes) Inode-cache hash table entries: 131072 (order: 8, 1048576 bytes) Memory:
Re: online fsck
Hello. reiserfsck can check reiserfs filesystem mounted read-only. Thanks, Lena btinsley wrote: Is there or was there a plan to support running reiserfsck on a mounted v3 filesystem (just a check, not a fix or rebuild)? I seem to remember this being mentioned here at some point in time, but I was unable to find it in the mailing list archive. Thanks!
Re: Yet another reiserfsdmmd corruption
Hello. David Masover wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 E.Gryaznova wrote: Hello. Joachim Zobel wrote: Am Montag, den 11.04.2005, 22:04 +0400 schrieb E.Gryaznova: [skipped] This just suddenly became an issue for me -- I'm about to do dm-raid. What's a good filesystem stress-testing tool? (I want to do Reiser4.) The list of the main filesystem tests you can find here: http://ltp.sourceforge.net/tooltable.php Thanks, Lena -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.1 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org iQIVAwUBQlx6V3gHNmZLgCUhAQJxjw/+PDsstdWS2VDX+bLSaBwBDxZvIMaYN8V0 IdgmjSsOcqSLNb70J3es6HJMTrAxWFJ7YjQtQ+J7xqvtYJlMDr/EafFB7nLxk9eP 6SnrXk5LAp00YLBS66s6Rxz+5YZaRNVHl5MRNu5Hz3dYe5+Jk08FgnlDMMA0wKD2 6y/qvNAYP3DdxNlSKx/bo6b+nTQZaLTh8FV2Ew5g5xdXtyb0R1xrBx06njJZwnlb w8MMnR/Uz1b8rJwCP4fEzoZulrtgbNE+oe9GRF+uujiTD4Jb7RAXyokBTGutiO1d ROmC8OvmjmNo9LU0c+9waUP0NMd+nOwqpM7vToTX3Vbi3B1F9v+7B4FAQRDIlvle opVV7GhzsoRoRMHc/Dc/PENVk6FylHaWqFWCGfqRtDFnUeGyON5E221B8ppQOsFa lKjSSszJhhG/2ZuZIfkXf2k2Z9vyi+Z0AhHjEJ1/lI8dGKGSEJskoukhQg04SGsl 0NjQAP8ezF/MnFcZiNLBilxquw5vq8xpJ5t+YlcjPnnA7YjWeYmssOajuUV2HPHg +D/y7yv0P5ZjBMuIYRKT8XPu3otmR8krTH4cFI0KzCGH13hJm8h+O25N+9Bn1MUU 6NYGM4v8DFrM+3YGNdhAMakf9ZxjmiRnHaj9aukfFZo2hZfCQiN+0Y02p0SEge52 l0Poq8b7Sho= =O+hc -END PGP SIGNATURE-
Re: Yet another reiserfsdmmd corruption
Hello. Joachim Zobel wrote: Am Montag, den 11.04.2005, 22:04 +0400 schrieb E.Gryaznova: Would you please send the following commands outputs?: # dmsetup deps # dmsetup status # dmsetup info # pvdisplay --map # lvdisplay --map -vv # ls -l /dev/vg (and /dev/mapper) See the attached file reiserfs.log The devices volg2-logv4: 1 dependencies : (22, 3) volg2-logv3: 1 dependencies : (22, 3) volg2-logv2: 1 dependencies : (22, 3) where created after the incident. One of them had a successful (some files lost) reiserfsck --rebuild-tree after dd-ing the bad /dev/volg-raid1/logv1 on it. lvdisplay --map -v did some stderr output, which is attached as lvdisplay.err #cat /proc/mdstat Personalities : [raid1] md0 : active raid1 hda2[0] hdc2[1] 3903680 blocks [2/2] [UU] Sincerely, Joachim I have checked lvm, it looks ok. Probably this is hardware problem. If you need our assistance in further investigation, please visit our support page http://www.namesys.com/support.html . Thanks, Lena
Re: Reiser4/2.6.11 dbench hang
Hello. We use dbench-2.0 in our testing. Well, dbench-3.02 is added to stressing suit too. Thanks, Lena. Hans Reiser wrote: Christian Mayrhuber wrote: I guess dbench-3.x stress testing is missing from your grand archive ;-) Yes, actually, I suspect it is. Elena, please comment.
Re: umount bug?
Hello. Hans Reiser wrote: E.Gryaznova wrote: Hello. Szabolcs Illes wrote: Hi, When I tried to umount my reiserfs4 partition I got this error message in the kernel log: [skip] [EMAIL PROTECTED]:~# I am using the latest kernel 2.6.11 with the patch available from ftp://ftp.namesys.com/pub/reiser4-for-2.6/2.6.11/reiser4-for-2.6.11-1.gz reiser4-for-2.6.11-1.gz is bugged. It is known. Wait please the next reiser4 release for 2.6.11. Thanks, Lena What is strange I rarely use this partition. The bug happend after I had updated my kernel from 2.6.10 to 2.6.11. I did not copy anything from/to that partition, just tried to umount it. Cheers, Szabolcs Why have we left on our website a release known to be buggy? Fix please. fix is available : ftp://ftp.namesys.com/pub/reiser4-for-2.6/2.6.11/reiser4-2.6.11-fix.patch Thanks, Lena Hans
Re: umount bug?
Hello. Szabolcs Illes wrote: Hi, When I tried to umount my reiserfs4 partition I got this error message in the kernel log: [skip] [EMAIL PROTECTED]:~# I am using the latest kernel 2.6.11 with the patch available from ftp://ftp.namesys.com/pub/reiser4-for-2.6/2.6.11/reiser4-for-2.6.11-1.gz reiser4-for-2.6.11-1.gz is bugged. It is known. Wait please the next reiser4 release for 2.6.11. Thanks, Lena What is strange I rarely use this partition. The bug happend after I had updated my kernel from 2.6.10 to 2.6.11. I did not copy anything from/to that partition, just tried to umount it. Cheers, Szabolcs
Re: [CHECKER] Do ext2, jfs and reiserfs respect mount -o sync/dirsync option? (fwd)
Hello, Junfeng. Thank you for the report and sorry for delay. Yes, the problem exists somewhere, but this is not reiserfsck --fix-fixable problem. I just modified the set of commands by the following way: mkreiserfs dev mount dev /mnt -o sync touch /mnt/file mkdir /mnt/d echo Hello /mnt/hello reboot -fn After boot it is reasonable to pack the reiserfs metada and compare mount and reiserfsck --fix-fixable results on _one_ crashed filesystem. # debugreiserfs -p dev | gzip -c metadata.gz 1. mount the crashed disk and see data 2. umount dd if=/dev/zero of=dev gunzip -c metadata.gz | debugreiserfs -u dev reiserfsck --fix-fixable dev mount the recovered filesystem and see data I this case the results of mount and fsck --fix-fixable mount are equal. Nevetheless, the sync problem exists somewhere. Because (yes, you are right), sometimes there are no correct data on filesystem after such crash. I run this test several times and see that sometimes data is lost after reboot -fn. We are working on this problem now. Thanks, Lena Junfeng Yang wrote: Hi, our mail server had some problems the last few days. I'm not sure if you guys have received my message or not. Can you please send me an ACK, even if you haven't gotten time to diagnose the error yet? Thanks a lot, -Junfeng On Wed, 9 Mar 2005, Junfeng Yang wrote: Let me know if you need any more information to reproduce the warning. I would really appreciate it if you can cc me once you figure out if it is a bug. -Junfeng On Sun, 6 Mar 2005, Junfeng Yang wrote: Hi Vladimir, are you able to reproduce the problem? Thanks, -Junfeng On Sat, 5 Mar 2005, Junfeng Yang wrote: I just made the follong test on reiserfs (2.6.11-rc4-mm1): mkreiserfs /dev/hda6 mount /dev/hda6 /mnt -o sync touch /mnt/file mkdir /mnt/d echo Hello /mnt/hello reboot -f -n Here is what I do to reproduce the same problem: 1. mkreiserfs on a partition 2. issue several file system operations 3. crash and resart the machine 4. run reiserfsck --fix-fixable --yes to recover 5. mount the recovered partition. It appears that step 4 is _important_ in reproducing the problem. If I just mount the crashed disk, everything appears to be fine. However, attempt to recover the crashed image using reiserfsck result in metadata/data loss. Details are attached below. Let me know if you need any more information. The script I use (run as root) #!/bin/sh umount /dev/hda9 /sbin/mkreiserfs -f /dev/hda9 mount -t reiserfs /dev/hda9 /mnt/sbd1 -o sync,dirsync ln -s /mnt/sbd1 /mnt/sbd1/0001 touch /mnt/sbd1/0002 mkdir /mnt/sbd1/0003 reboot -f -n uname -a shows: Linux notus 2.6.11 #1 Sat Mar 5 04:39:12 PST 2005 i686 GNU/Linux reiserfsck output is: reiserfsck 3.6.19 (2003 www.namesys.com) * ** If you are using the latest reiserfsprogs and it fails ** ** please email bug reports to reiserfs-list@namesys.com, ** ** providing as much information as possible -- your ** ** hardware, kernel, patches, settings, all reiserfsck ** ** messages (including version), the reiserfsck logfile, ** ** check the syslog file for any related information. ** ** If you would like advice on using this program, support ** ** is available for $25 at www.namesys.com/support.html. ** * Will check consistency of the filesystem on /dev/hda9 and will fix what can be fixed without --rebuild-tree Will put log info to 'stdout' ### reiserfsck --fix-fixable started at Sat Mar 5 12:16:12 2005 ### Replaying journal.. No transactions found Checking internal tree..finished Comparing bitmaps..finished Checking Semantic tree: finished No corruptions found There are on the filesystem: Leaves 1 Internal nodes 0 Directories 1 Other files 0 Data block pointers 0 (0 of them are zero) Safe links 0 ### reiserfsck finished at Sat Mar 5 12:16:15 2005 ### second mount of the crashed disk shows: ReiserFS: hda9: found reiserfs format 3.6 with standard journal ReiserFS: hda9: using ordered data mode ReiserFS: hda9: journal params: device hda9, size 8192, journal first block 18, max trans len 1024, max batch 900, max commit age 30, max trans age 30 ReiserFS: hda9: checking transaction log (hda9) ReiserFS: hda9: Using r5 hash to sort names
Re: Erased start of voulme...
Alex Zarochentsev wrote: Hello, On Thu, Jan 13, 2005 at 05:03:30PM -0800, Louis Erickson wrote: I don't know how it happened, but the start of the /var partition of one of the machines I run has gotten itself zeroed out. Only the first little bit - 4k or so - is nulls, then a large amount of very plausible data appears. I can't get reiserfsck to even think this is a reiserfs volume - the program doesn't think this is a reiserfs volume any more. Is there any chance of getting the data back off of this disk? Can reiserfsck be told to look harder and recover more deeply or something? Or is this a lesson in why backups are important? Any suggestions you can give are welcome. reiserfsck --rebuild-sb can re-create the super block. I would prefer to do the following : dd if=/dev/problem_partition of=/dev/sparedevice sparedevice can be usual disk partition then reiserfsck --rebuild-sb /dev/sparedevice reiserfsck --check /dev/sparedevice Thanks, Lena. I'm currently running dd from the mangled partition to a file to be able to try some things without losing my only copy of the data. If there's anything special I have to do to make that work, please let me know. Thank you! -- Louis Erickson - [EMAIL PROTECTED] - http://www.rdwarf.com/~wwonko/ Oh Dad! We're ALL Devo!
Re: Erased start of voulme...
Louis Erickson wrote: Wow, thanks for the fast responses, everyone. I'll try and consolidate them all in to one reply, in the order I got them here. Silly me forgot to start ssh on the afflicted box, so I can't get to it until I get home. I do have another near-identical machine that I've checked versions and such on, and can use to build tools if need be. On Fri, 14 Jan 2005, Sander [EMAIL PROTECTED] wrote: What arguments did you use? reiserfsck --check /dev/md2 What version of reiserfsck? How do I find that out? It isn't in the help or visible as an option. If I ask mkfs.reiserfs it tells me it's 3.x.1b (2002). I suspect it's quite old. please try the latest reiserfsprogs-3.6.19.tar.gz from ftp://namesys.com/pub/reiserfsprogs Should I build new tools (on another similar machine) and use those instead? And what filesystem? It's /dev/md2, mounting on /var. Linux is unhappy without it, although it does come up to single user mode. Much of the important data is on /home, and I can therefore get off if I have to completely rebuild, but there's a couple of things (/var/mail, for instance) that would be good to rescue. I'd like to try and get a gander at /var/log too, to see if I can suss out what happened. All of this is running on software raid, but the volumes are all up and good, and the raid component isn't complaining at all. Or is that not the question you're asking? _And_ it is a lesson why backups are important :-) Yes it is. It is past time to fix this astonishing lack in our infrastructure. On Fri, 14 Jan 2005, Alex Zarochentsev [EMAIL PROTECTED] wrote: reiserfsck --rebuild-sb can re-create the super block. I saw that, but it looked dangerous, and I didn't want to try it until my copy had finished. On Fri, 14 Jan 2005, E.Gryaznova [EMAIL PROTECTED] wrote: I would prefer to do the following : dd if=/dev/problem_partition of=/dev/sparedevice sparedevice can be usual disk partition I don't have a spare partition large enough in this system. I have done: dd if=/dev/problem_partition of=/home/scratch/rescue.dat I'll then use the loopback file system to create a device entry for that file, and work on that. It was a suggestion made earlier on this very mailing list, and it sounded like a wise one to me. If the loopback doesn't work, I'll fiddle around with hardware to make a spare partition large enough available. then reiserfsck --rebuild-sb /dev/sparedevice reiserfsck --check /dev/sparedevice The help screen for --rebuild-sb says that a --rebuild-sb will require a --rebuild-tree afterwards. Should I try that, or the --check? new reiserfsck (3.6.19) asks to run --check after --rebuild-sb Or will --check do the --rebuild-sb as needed? Also, there's a -S/--scan-whole-partition option... should I use that to make sure no files are missed, or would it best not to add that? if you have a copy of corrupted fs -- you may try both ways (w/ and w/o -S) and see what way is more successful Good luck! Lena Again, thank you all for your quick replies. It's been very helpful, and very positive to hear there are things I can at least try, rather than that I am simply hosed.
Re: reiser4 for 2.6.10 and reiser4 update for 2.6.10-rc3-mm1
Hello. Vladimir Saveliev wrote: Hello you can get latest reiser4 for 2.6.10 (ftp://ftp.namesys.com/pub/reiser4-for-2.6/2.6.10/reiser4-for-2.6.10-1.gz) and update for 2.6.10-rc3-mm1 (ftp://ftp.namesys.com/pub/reiser4-for-2.6/2.6.10-rc3-mm1/reiser4-update-for-2.6.10-rc3-mm1-1.gz). sorry, this is vs's typo, the newest update for 2.6.10-rc3-mm1 is ftp://ftp.namesys.com/pub/reiser4-for-2.6/2.6.10-rc3-mm1/reiser4-update-for-2.6.10-rc3-mm1-2.gz Thanks, Lena. Elena, please try to hammer it. Happy new year!
Re: Compile error 2.6.9
E.Gryaznova wrote:
Jim Miller wrote:
I got the follow errors while compiling 2.6.9 linux kernel. I followed
these dirs:
1. get 2.6.9 (ftp.kernel.org:/pub/linux/kernel/v2.6/linux-2.6.9.tar.gz)
tar zxf linux-2.6.9.tar.gz -C /usr/src
2. get reiser4 core patches:
ftp.namesys.com:/pub/reiser4-for-2.6.9/2.6.9.diff
cd /usr/src/linux-2.6.9
cat 2.6.9.diff | patch -p1
3. add reiser4 to linux-2.6.9
ftp.namesys.com:/pub/reiser4-for-2.6.9/reiser4.tar.bz2
cd /usr/src/linux-2.6.9/fs
tar jxf reiser4.tar.bz2
4. patch reiser4 to match 2.6.9
ftp.namesys.com:/pub/reiser4-for-2.6.9/reiser4-for-2.6.9.diff
cd /usr/src/linux-2.6.9
cat reiser4-for-2.6.9.diff | patch -p1
All of the patches applied successfully. Any suggestions would be
appreciated.
CC fs/reiser4/plugin/cryptcompress.o
fs/reiser4/plugin/cryptcompress.c: In function `inflate_cluster':
fs/reiser4/plugin/cryptcompress.c:1018: parse error before `*'
fs/reiser4/plugin/cryptcompress.c:1019: `cplug' undeclared (first use in
this function)
fs/reiser4/plugin/cryptcompress.c:1019: (Each undeclared identifier is
reported only once
fs/reiser4/plugin/cryptcompress.c:1019: for each function it appears
in.)
make[3]: *** [fs/reiser4/plugin/cryptcompress.o] Error 1
make[2]: *** [fs/reiser4] Error 2
make[1]: *** [fs] Error 2
make[1]: Leaving directory `/usr/src/linux-2.6.9'
make: *** [stamp-build] Error 2
Thanks,
Jim
Hello,
would you please send me your config file?
Thanks,
Lena
Would you please try this patch?
Thanks,
Lena.
= plugin/cryptcompress.c 1.133 vs edited =
--- 1.133/plugin/cryptcompress.c2004-10-27 19:55:54 +04:00
+++ edited/plugin/cryptcompress.c 2004-11-02 12:12:18 +03:00
@@ -1013,9 +1013,10 @@
assert(edward-907, !tfm_cluster_is_uptodate(tc));
if (inode_get_crypto(inode) != NULL) {
+ crypto_plugin * cplug;
+
/* FIXME-EDWARD: isn't support yet */
assert(edward-908, 0);
- crypto_plugin * cplug;
cplug = inode_crypto_plugin(inode);
assert(edward-617, cplug != NULL);
Re: Compile error 2.6.9
Jim Miller wrote: I got the follow errors while compiling 2.6.9 linux kernel. I followed these dirs: 1. get 2.6.9 (ftp.kernel.org:/pub/linux/kernel/v2.6/linux-2.6.9.tar.gz) tar zxf linux-2.6.9.tar.gz -C /usr/src 2. get reiser4 core patches: ftp.namesys.com:/pub/reiser4-for-2.6.9/2.6.9.diff cd /usr/src/linux-2.6.9 cat 2.6.9.diff | patch -p1 3. add reiser4 to linux-2.6.9 ftp.namesys.com:/pub/reiser4-for-2.6.9/reiser4.tar.bz2 cd /usr/src/linux-2.6.9/fs tar jxf reiser4.tar.bz2 4. patch reiser4 to match 2.6.9 ftp.namesys.com:/pub/reiser4-for-2.6.9/reiser4-for-2.6.9.diff cd /usr/src/linux-2.6.9 cat reiser4-for-2.6.9.diff | patch -p1 All of the patches applied successfully. Any suggestions would be appreciated. CC fs/reiser4/plugin/cryptcompress.o fs/reiser4/plugin/cryptcompress.c: In function `inflate_cluster': fs/reiser4/plugin/cryptcompress.c:1018: parse error before `*' fs/reiser4/plugin/cryptcompress.c:1019: `cplug' undeclared (first use in this function) fs/reiser4/plugin/cryptcompress.c:1019: (Each undeclared identifier is reported only once fs/reiser4/plugin/cryptcompress.c:1019: for each function it appears in.) make[3]: *** [fs/reiser4/plugin/cryptcompress.o] Error 1 make[2]: *** [fs/reiser4] Error 2 make[1]: *** [fs] Error 2 make[1]: Leaving directory `/usr/src/linux-2.6.9' make: *** [stamp-build] Error 2 Thanks, Jim Hello, would you please send me your config file? Thanks, Lena
Re: Unsupported mkreiserfs and mount options
Martin MOKREJ wrote: Hi, I'm doing some benchmarking of reiserfs on 2.4.28-pre3 system. I have crafted some non-standard options to mkreiserfs and mount, but they sometimes fail. I've attached only those which have failed. ;) Am I right they don't work but should according to manpages? Thanks for help Martin P.S.: Yes, some messages about unsupported bla bla got logged by syslog. Why cannot user see the on STDERR? I simply don't know what has generated what in syslog. :( mkreiserfs -f -s 8192 -b 2048 /dev/sdb2 Guessing about desired format.. Kernel 2.4.28-pre3 is running. Format 3.6 with non-standard journal Count of blocks on the device: 638137920 Number of blocks consumed by mkreiserfs formatting process: 47175 Blocksize: 2048 Hash function used to sort names: r5 Journal Size 8192 blocks (first block 34) Journal Max transaction length 512 inode generation number: 0 UUID: f9c76801-44d4-4020-a5cf-b9e5aa76a707 Initializing journal - 0%20%40%60%80%100% Syncing..ok mount -t reiserfs /dev/sdb2 /scratch mount: wrong fs type, bad option, bad superblock on /dev/sdb2, or too many mounted file systems (aren't you trying to mount an extended partition, instead of some logical partition inside?) block size = 2048 is supported in 2.6.x kernel. mkreiserfs -f -s 8192 -b 8192 /dev/sdb2 Guessing about desired format.. Kernel 2.4.28-pre3 is running. Format 3.6 with non-standard journal Count of blocks on the device: 159534480 Number of blocks consumed by mkreiserfs formatting process: 10637 Blocksize: 8192 Hash function used to sort names: r5 Journal Size 8192 blocks (first block 10) Journal Max transaction length 1024 inode generation number: 0 UUID: fcfa840c-4170-421a-9383-cebaf2d78b58 Initializing journal - 0%20%40%60%80%100% Syncing..ok mount -t reiserfs /dev/sdb2 /scratch mount: wrong fs type, bad option, bad superblock on /dev/sdb2, or too many mounted file systems (aren't you trying to mount an extended partition, instead of some logical partition inside?) mkreiserfs -f -h r5 /dev/sdb2 Guessing about desired format.. Kernel 2.4.28-pre3 is running. Format 3.6 with standard journal Count of blocks on the device: 319068960 Number of blocks consumed by mkreiserfs formatting process: 17949 Blocksize: 4096 Hash function used to sort names: r5 Journal Size 8193 blocks (first block 18) Journal Max transaction length 1024 inode generation number: 0 UUID: 2fa671ed-eb3e-4e4f-b59c-040502c6d7b4 Initializing journal - 0%20%40%60%80%100% Syncing..ok mount -t reiserfs -o r5 /dev/sdb2 /scratch mount: wrong fs type, bad option, bad superblock on /dev/sdb2, or too many mounted file systems (aren't you trying to mount an extended partition, instead of some logical partition inside?) You use incorrect mount option. In according to www.namesys.com/mount-options.html the correct option is : -o hash=r5 mkreiserfs -f -h yura /dev/sdb2 mkreiserfs: wrong hash type specified. Using default mkreiserfs 3.6.17 (2003 www.namesys.com) I am confused, why do you use yura hash? # mkeriserfs --help mkreiserfs 3.6.17 (2003 www.namesys.com) Options: -h | --hash rupasov|tea|r5 hash function to use by default mkreiserfs -f -t 16384 /dev/sdb2 mkreiserfs 3.6.17 (2003 www.namesys.com) WARNING: wrong transaction max size (16384). Changed to 1024 mkreiserfs -f -t 65535 /dev/sdb2 mkreiserfs 3.6.17 (2003 www.namesys.com) WARNING: wrong transaction max size (65535). Changed to 1024 mkreiserfs -f -t 131072 /dev/sdb2 mkreiserfs 3.6.17 (2003 www.namesys.com) WARNING: wrong transaction max size (131072). Changed to 1024 mkreiserfs man page says that : -t | --transaction-max-size N N is the maximum transaction size parameter for the journal. The default, and max possible, value is 1024 blocks. It should be less than half the size of the journal. If specified incorrectly, it will automatically be adjusted. mkreiserfs -f -h r5 /dev/sdb2 Guessing about desired format.. Kernel 2.4.28-pre3 is running. Format 3.6 with standard journal Count of blocks on the device: 319068960 Number of blocks consumed by mkreiserfs formatting process: 17949 Blocksize: 4096 Hash function used to sort names: r5 Journal Size 8193 blocks (first block 18) Journal Max transaction length 1024 inode generation number: 0 UUID: 2b54ffa7-068a-428b-bc7b-a8b3ba80400b Initializing journal - 0%20%40%60%80%100% Syncing..ok mount -t reiserfs -o hashed_relocation /dev/sdb2 /scratch mount: wrong fs type, bad option, bad superblock on /dev/sdb2, or too many mounted file systems (aren't you trying to mount an extended partition, instead of some logical partition inside?) In according to www.namesys.com/mount-options.html the correct option is -o block-allocator=hashed_relocation
We can't reproduce benchmarks by Corbet of lwn, can others help us?
Hello. We can't reproduce benchmarks by J.Corbet of lwn (http://lwn.net/Articles/99232/ ). Our results : http://namesys.com/intbenchmarks/untar-build-find/2004.10.11/Corbet.benchmark.results Can others help us? Thanks, Lena.
Re: reiser4 - Non-removable files in lost+found
Adrian Ulrich wrote: Also, can this be done when the partition is mounted read-only? I did this some months ago and my kernel gave me a nice Oops ;-) Nikita told me on #reiser4 that it isn't possible to fsck a (ro)-mounted Filesystem.. Maybe this changed and it's possible now.. no, this does not work properly still. Thanks, Lena bye
Re: I/O Errors
Hello. Would you please send us the #pvscan, #pvdisplay, #vgdislpay, #lvdisplay and #lvs --version outputs. Thanks, Lena. f00bar wrote: Hi Alex, Thanks for your assistance. When I mount the partition, (actually a logical volume) the following is written to syslog. Sep 27 19:17:32 yin-yang ef_hash_table: 8192 buckets Sep 27 19:17:32 yin-yang z_hash_table: 8192 buckets Sep 27 19:17:32 yin-yang z_hash_table: 8192 buckets Sep 27 19:17:32 yin-yang j_hash_table: 16384 buckets Sep 27 19:17:32 yin-yang loading reiser4 bitmap..done (148 jiffies) Sep 27 19:17:32 yin-yang d_cursor_hash_table: 256 buckets I perform an ls the following is written to the console (I assume stderr) but nothing is written to syslog. ls: reading directory /var/tmp/portage: Input/output error total 0 The following is the output from fsck: yin-yang log # fsck.reiser4 /dev/vgsdc1/reiser4 *** This is an EXPERIMENTAL version of fsck.reiser4. Read README first. *** Fscking the /dev/vgsdc1/reiser4 block device. Will check the consistency of the Reiser4 SuperBlock. Will check the consistency of the Reiser4 FileSystem. Continue? (Yes/No): yes * fsck.reiser4 started at Mon Sep 27 19:23:14 2004 Reiser4 journal (journal40) on /dev/vgsdc1/reiser4: 0 transactions replayed of the total 0 blocks. Reiser4 fs was detected on /dev/vgsdc1/reiser4. Master super block (16): magic: ReIsEr4 blksize:4096 format: 0x0 (format40) uuid: 3581757c-9576-4ed6-ba21-59863d2950b1 label: none Format super block (17): plugin: format40 description:Disk-format for reiser4, ver. 1.0.2-pre1 magic: ReIsEr40FoRmAt flushes:0 mkfs id:0x4e9bfc27 blocks: 553984 free blocks:553937 root block: 23 tail policy:0x2 (smart) next oid: 0x1 file count: 0 tree height:2 key policy: LARGE CHECKING STORAGE TREE Read nodes 2 Nodes left in the tree 2 Leaves of them 1, Twigs of them 1 Time interval: Mon Sep 27 19:23:14 2004 - Mon Sep 27 19:23:14 2004 CHECKING EXTENT REGIONS. Read twigs 1 Time interval: Mon Sep 27 19:23:14 2004 - Mon Sep 27 19:23:14 2004 CHECKING SEMANTIC TREE Found 1 objects. Time interval: Mon Sep 27 19:23:14 2004 - Mon Sep 27 19:23:14 2004 * fsck.reiser4 finished at Mon Sep 27 19:23:14 2004 Closing fs...done FS is consistent. Regards, John Baxter
