[PATCH]Make fsck.reiser4 really quiet
Hi,
Attached is a patch to make the -q switch to fsck.reiser4 *really* quiet.
It also removes the shouting style of all-caps text for the major fsck actions.
Diff'ed against reiser4progs 1.0.6.
Cheers,
-Joe
Signed-off-by: J. Joe Feise <[EMAIL PROTECTED]>
diff -urN reiser4progs-1.0.6.orig/include/repair/repair.h
reiser4progs-1.0.6/include/repair/repair.h
--- reiser4progs-1.0.6.orig/include/repair/repair.h 2006-11-01
06:50:34.0 -0800
+++ reiser4progs-1.0.6/include/repair/repair.h 2006-11-08 19:18:52.0
-0800
@@ -29,6 +29,7 @@
char *bitmap_file;
uint32_t flags;
+ uint8_t quiet;
} repair_data_t;
extern errno_t repair_check(repair_data_t *repair);
diff -urN reiser4progs-1.0.6.orig/librepair/add_missing.c
reiser4progs-1.0.6/librepair/add_missing.c
--- reiser4progs-1.0.6.orig/librepair/add_missing.c 2006-11-01
06:50:34.0 -0800
+++ reiser4progs-1.0.6/librepair/add_missing.c 2006-11-08 19:18:52.0
-0800
@@ -297,7 +297,7 @@
aal_assert("vpf-848", am->bm_twig != NULL);
aal_assert("vpf-849", am->bm_leaf != NULL);
- aal_mess("INSERTING UNCONNECTED NODES");
+ aal_mess("Inserting unconnected nodes");
am->gauge = aal_gauge_create(aux_gauge_handlers[GT_PROGRESS],
NULL, NULL, 500, NULL);
time(&am->stat.time);
@@ -358,7 +358,8 @@
}
aal_gauge_free(am->gauge);
- repair_add_missing_update(am);
+ if (!am->repair->quiet)
+ repair_add_missing_update(am);
reiser4_fs_sync(am->repair->fs);
return 0;
diff -urN reiser4progs-1.0.6.orig/librepair/cleanup.c
reiser4progs-1.0.6/librepair/cleanup.c
--- reiser4progs-1.0.6.orig/librepair/cleanup.c 2006-11-01 06:50:34.0
-0800
+++ reiser4progs-1.0.6/librepair/cleanup.c 2006-11-08 19:19:37.0
-0800
@@ -143,7 +143,7 @@
return 0;
}
- aal_mess("CLEANING UP THE STORAGE TREE");
+ aal_mess("Cleaning up the storage tree");
cleanup->gauge = aal_gauge_create(aux_gauge_handlers[GT_PROGRESS],
cb_gauge_tree_percent, NULL, 500,
NULL);
aal_gauge_set_value(cleanup->gauge, 0);
@@ -158,7 +158,8 @@
aal_gauge_done(cleanup->gauge);
aal_gauge_free(cleanup->gauge);
- repair_cleanup_update(cleanup);
+ if (!cleanup->repair->quiet)
+ repair_cleanup_update(cleanup);
reiser4_fs_sync(cleanup->repair->fs);
return 0;
diff -urN reiser4progs-1.0.6.orig/librepair/disk_scan.c
reiser4progs-1.0.6/librepair/disk_scan.c
--- reiser4progs-1.0.6.orig/librepair/disk_scan.c 2006-11-01
06:50:34.0 -0800
+++ reiser4progs-1.0.6/librepair/disk_scan.c2006-11-08 19:18:53.0
-0800
@@ -79,7 +79,7 @@
aal_assert("vpf-820", ds->bm_scan != NULL);
aal_assert("vpf-820", ds->bm_met != NULL);
- aal_mess("LOOKING FOR UNCONNECTED NODES");
+ aal_mess("Looking for unconnected nodes");
gauge = aal_gauge_create(aux_gauge_handlers[GT_PROGRESS],
NULL, NULL, 500, NULL);
aal_gauge_touch(gauge);
@@ -161,6 +161,7 @@
error:
aal_gauge_done(gauge);
aal_gauge_free(gauge);
- repair_disk_scan_update(ds);
+ if (!ds->repair->quiet)
+ repair_disk_scan_update(ds);
return res;
}
diff -urN reiser4progs-1.0.6.orig/librepair/filter.c
reiser4progs-1.0.6/librepair/filter.c
--- reiser4progs-1.0.6.orig/librepair/filter.c 2006-11-01 06:50:34.0
-0800
+++ reiser4progs-1.0.6/librepair/filter.c 2006-11-08 19:20:14.0
-0800
@@ -659,7 +659,7 @@
aal_assert("vpf-816", fd->repair->fs->tree != NULL);
aal_assert("vpf-815", fd->bm_used != NULL);
- aal_mess("CHECKING THE STORAGE TREE");
+ aal_mess("Checking the storage tree");
fd->gauge = aal_gauge_create(aux_gauge_handlers[GT_PROGRESS],
cb_gauge_tree_percent, NULL, 500, NULL);
time(&fd->stat.time);
@@ -667,7 +667,8 @@
res = repair_filter_traverse(fd);
aal_gauge_free(fd->gauge);
- repair_filter_update(fd);
+ if (!fd->repair->quiet)
+ repair_filter_update(fd);
if (!res && fd->repair->mode != RM_CHECK)
reiser4_fs_sync(fd->repair->fs);
diff -urN reiser4progs-1.0.6.orig/librepair/repair.c
reiser4progs-1.0.6/librepair/repair.c
--- reiser4progs-1.0.6.orig/librepair/repair.c 2006-11-01 06:50:34.0
-0800
+++ reiser4progs-1.0.6/librepair/repair.c 2006-11-08 19:18:53.00
Re: Better fsck.reiser4 needed
Vladimir V. Saveliev wrote on 09/06/06 02:04: >> I had a /var corruption (reiser4 on /var) over the weekend, and since I was >> out of town, the machine was hanging trying to go into multi-user mode > > I guess here you got reiser4 bug where it hanged trying to access corrupted > partition instead of returning -EIO. Was there anything interesting in logs > and have you managed to catch them? Unfortunately, I didn't get any logs, since they are on the corrupted /var. -Joe
Better fsck.reiser4 needed
Hi, It seems that fsck.reiser4 -a doesn't do anything. It doesn't even detect corruption. I had a /var corruption (reiser4 on /var) over the weekend, and since I was out of town, the machine was hanging trying to go into multi-user mode for a day before I could fix the corruption manually. An fsck that actually would do some automatic repairs (e.g., like ext3 which I use as the root partition) would be really helpful. For now, I have resorted to --fix -y at bootup time for all my reiser4 partitions, but that's just a quick hack, and rather unsatisfactory. Cheers, -Joe
Re: reiser4 can now bear with filled fs, looks stable to me...
Christian Trefzer wrote on 07/30/06 15:38: > Hi, > > I booted 2.6.18-rc2-mm1 today and later filled up my /opt partition by > accident, and guess what, reiser4 did not screw up : D Lucky you. I tried -rc2-mm1 today, and out of habit, the first thing I do is an fsck on my reiser4 partitions. And that resulted in a crash :-( I am now back to -rc1-mm1, which was the last one that's stable for me. -Joe
Re: Reiser4 cowardly panic 2.6.17-mm5
This seems to be fixed with 2.6.17-mm6. -Joe Joe Feise writes: I consistently get cowardly panic errors during bootup with 2.6.17-mm5 (I also had that with -mm3, and had hoped -mm5 would have fixed it.) It corrupts the partition this is happening on (/var) I don't have dmesg or syslog output, though, since this happens during bootup, and /var gets corrupted... -Joe
Reiser4 cowardly panic 2.6.17-mm5
I consistently get cowardly panic errors during bootup with 2.6.17-mm5 (I also had that with -mm3, and had hoped -mm5 would have fixed it.) It corrupts the partition this is happening on (/var) I don't have dmesg or syslog output, though, since this happens during bootup, and /var gets corrupted... -Joe
[BUG] reiser4 crash 2.6.17-rc3-mm1
2.6.17-rc3-mm1 plus the latest reiser4-radix-tree-direct-data-fix.patch patch.
-Joe
=
dmesg output:
=
BUG: unable to handle kernel NULL pointer dereference at virtual address
003c
printing eip:
c01c8dca
*pde =
Oops: [#1]
PREEMPT
last sysfs file: /class/net/ppp0/type
Modules linked in: ppp_async crc_ccitt pl2303 usbserial softdog cisco_ipsec
snd_pcm_oss snd_mixer_oss snd_cs46xx gameport snd_rawmidi snd_seq_device
snd_ac97_codec snd_ac97_bus snd_pcm snd_timer snd soundcore snd_page_alloc
zoran i2c_algo_bit videodev saa7111 i2c_core pegasus arc4 ppp_mppe
ppp_deflate ppp_generic slhc usblp
CPU:0
EIP:0060:[]Tainted: P VLI
EFLAGS: 00010202 (2.6.17-rc3-mm1 #5)
EIP is at fuse_not_fused_lock_owners+0x79/0x1e7
eax: fffc ebx: d4824590 ecx: 0008 edx: d48245a4
esi: fffc edi: d9d97680 ebp: f782a000 esp: f782bb50
ds: 007b es: 007b ss: 0068
Process patch (pid: 10605, threadinfo=f782a000 task=e85e2570)
Stack: <0>ca9a2df0 c55bc880 ca9a2d80 c55bc8c4 d9d97680 ca9a2d80
f782a000
c01c8b0b c01c047a f782bba0 0008 c55bc8c4 ca9a2d80 c55bc8c4
c01c8c97 f782bba0 0002 fe09 c55bc884 f782a000
Call Trace:
try_capture_block+0x179/0x27b
free_space_shortage+0x2b/0x52
try_capture+0x72/0xe1longterm_lock_znode+0x21a/0x2ab
cbk_cache_scan_slots+0x123/0x2d6
cbk_cache_search+0x2d/0x4e
coord_by_handle+0x8/0x19object_lookup+0xab/0xd6
done_carry_level+0x5b/0x6ecut_tree_object+0x77/0x1b9
reiser4_grab+0xaf/0xf2reiser4_grab_space+0x57/0x7f
reiser4_grab_reserved+0x4d/0x15d
longterm_unlock_znode+0xb6/0x187
reserve_cut_iteration+0x59/0x69
cut_file_items+0xd8/0x177
shorten_file+0x4a/0x20aupdate_file_size+0x0/0x83
truncate_file_body+0x8c/0x90preempt_point+0x5/0x1d
delete_object_unix_file+0x4a/0xe2
_init_context+0x54/0x78
reiser4_delete_inode+0x6b/0xcad_delete+0xe0/0xe6
reiser4_delete_inode+0x0/0xca
generic_delete_inode+0xaa/0x150
iput+0x53/0x65do_unlinkat+0xb9/0xfa
sys_renameat+0x61/0x73sys_rename+0x27/0x2b
syscall_call+0x7/0xbsvc_recv+0x3bc/0x504
Code: 44 24 08 8b 50 70 8d 5a ec 8b 43 14 0f 18 00 90 3b 14 24 0f 84 19 01
00 00 89 f5 8b 43 04 e8 f8 c1 ff ff 3b 44 24 04 89 c6 74 0c <8b> 40 40 3b 78
08 0f 85 33 01 00 00 8b 53 14 8d 42 ec 89 c3 8b
EIP: [] fuse_not_fused_lock_owners+0x79/0x1e7 SS:ESP 0068:f782bb50
<6>note: patch[10605] exited with preempt_count 2
Re: reiser4 bug [was Re: 2.6.17-rc3-mm1]
Try the patch from here: http://marc.theaimsgroup.com/?l=reiserfs&m=114709188305181&w=2 That helped me get past the bootup phase (currently 8 hours uptime). -Joe Alexander Gran writes: Hi all, 2.6.17-rc3-mm1 doesn't get up running here, it bugs around while init runs: I cannot login afterwards, and syslog did not get the bug too. So here are some poor screenshots from my Treo650 (digicam is broken, sorry..;) EIP is in clear_inode. Trace: reiser4_delete_inode+0x6c/0xd0 d_delete+0xf0/0x10f reiser4_delete_inode+0x0/0xd0 generic_delete_inode+0x6b/0xfb input+0x5c/0x68 do_unlikat+0xd7/0x12c sysenter_past_esp+0x54/0x75 __hidp_send_ctrl_message+0xb4/0xfa details: http://zodiac.dnsalias.org/images/1.jpg http://zodiac.dnsalias.org/images/2.jpg http://zodiac.dnsalias.org/images/3.jpg http://zodiac.dnsalias.org/images/4.jpg Kernel config: http://zodiac.dnsalias.org/images/config System is my T40p, as usual. running an up2date debian unstable. regards Alex
Reiserfs bug in 2.6.17-rc3-mm1
rc3-mm1 plus the reiser4-radix-tree-direct-data-fix.patch
-Joe
dmesg output:
kernel BUG at fs/reiser4/flush.c:1038!
invalid opcode: [#1]
PREEMPT
last sysfs file: /class/net/eth2/ifindex
Modules linked in: pl2303 usbserial softdog cisco_ipsec snd_pcm_oss
snd_mixer_oss snd_cs46xx gameport snd_rawmidi snd_seq_device snd_ac97_codec
snd_ac97_bus snd_pcm snd_timer snd soundcore snd_page_alloc zoran i2c_algo_bit
videodev saa7111 i2c_corepegasus arc4 ppp_mppe ppp_deflate ppp_generic slhc
usblp
CPU:0
EIP:0060:[]Tainted: P VLI
EFLAGS: 00010287 (2.6.17-rc3-mm1 #4)
EIP is at flush_current_atom+0x1cf/0x247
eax: e0efc080 ebx: f4b45e00 ecx: f4b45e00 edx: f5c2e000
esi: f5dabe4c edi: f5daa000 ebp: 0001 esp: f5dabe0c
ds: 007b es: 007b ss: 0068
Process ent:sdb2! (pid: 1832, threadinfo=f5daa000 task=f5d89ab0)
Stack: <0>f5dabe18 0001 f5dabe90 c5db8a40 e0efc080 f5daa000
f5c21cd8
c01c84b8 f5dabe4c f5dabeec f5dabea8 f7e57dcc f5dabe90
e0efc080 f7e57d80 f7e57dcc f58d7c00 c01d6b60 0001 d75ba3ac
Call Trace:
flush_some_atom+0x245/0x367writeout+0xc8/0x1e7
generic_sync_sb_inodes+0x211/0x2a8entd_flush+0x9f/0xbc
entd+0xd5/0x2a3autoremove_wake_function+0x0/0x43
autoremove_wake_function+0x0/0x43entd+0x0/0x2a3
kthread+0x9c/0xa1kthread+0x0/0xa1
kernel_thread_helper+0x5/0xb
Code: 87 c7 04 24 20 72 47 c0 e8 b8 b4 f4 ff e8 ae 84 f3 ff e9 5c ff ff ff e8 59
c2 27 00 e9 28 ff ff ff e8 4f c2 27 00 e9 0f ff ff ff <0f> 0b 0e 04 e5 bd 47 c0
e9 f3 fe ff ff 8b 54 24 0c 85 d2 74 09
EIP: [] flush_current_atom+0x1cf/0x247 SS:ESP 0068:f5dabe0c
<6>note: ent:sdb2![1832] exited with preempt_count 2
Re: BUG on reiser4_delete_inode
Laurent Riffard wrote on 05/05/06 22:51: > Le 05.05.2006 20:32, Joe Feise a écrit : >> The patch doesn't seem to have made it to the list. I have run into the >> same problem... >> -Joe > > Vladimir's mail never reached the list despite the fact it was CC'ed to. > > Here is the patch that Vladimir sent. Thanks. The fix works on 2.6.17-rc3-mm1... -Joe
Re: BUG on reiser4_delete_inode
The patch doesn't seem to have made it to the list. I have run into the same problem... -Joe Laurent Riffard writes: Le 05.05.2006 15:38, Vladimir V. Saveliev a écrit : Hello On Thu, 2006-05-04 at 22:21 +0200, Laurent Riffard wrote: Hello, I have a small Reiser4 FS (1 GB) which became really unstable since 2.6.17-rc2-mm1. I managed to get a fully reproductible scenario: sh-3.00# mount /dev/vglinux1/lvkernel2 /mnt/disk ~$ mv /mnt/disk/linux-2.6-stable/arch/i386/kernel/acpi/boot.c /home/laurent/tmp/ Erreur de segmentation [ cut here ] kernel BUG at fs/inode.c:251! Thanks for the report. The problem is introduced by ftp://ftp.ru.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.17-rc2/2.6.17-rc2-mm1/broken-out/radix-tree-direct-data.patch The attached patch should fix the problem, though. Ok, this bug seems to be fixed. Thanks for your quick answer. -- laurent
Re: Reiser4 crash 2.6.16-mm1
Sergey Ivanov wrote on 03/28/06 13:52: > Joe Feise wrote: >> The machine is using ECC memory. Geez, I know what I need for a server... >> From the Dell invoice: >> 512MB DDR2, 400MHz,2X256MB ECC 1R DIMMs for PowerEdge SC420 >> Recreating the partition solved the problem. So to me it sure looks like >> fs corruption. >> I have sent the dmesg output earlier. > Joe, I saw machines with ECC hardware (both motherboards and memory > chips) with ECC disabled in BIOS. Check please, if it's enabled for your > machine. It is enabled. The Dell BIOS actually doesn't even allow to change that. -Joe
Re: Reiser4 crash 2.6.16-mm1
Gregory Maxwell wrote on 03/28/06 13:22: > On 3/28/06, Jonathan Briggs <[EMAIL PROTECTED]> wrote: > >> But for a production machine that is "producing" something of value, the >> extra cost should not be an issue. RAM errors are so subtle and so hard >> to find that ECC is of far more value than RAID. It is obvious when >> your disk fails. >> >> An extra high bit in a credit transaction could cost you $16,384 and you >> might not ever realize what happened. :) >> >> Anyway, off topic, but ECC is highly recommended. > > And with the amount of memory that people are putting in modern system > 1 bit events should be happening on a approx weekly basis. > > ECC may be more expensive but it doesn't make memory more expensive > than it was just a few years ago you really should have it. I agree, and the system in question has ECC RAM. The additional cost is not such a big issue anyway... I have SCSI disks (no RAID, though) in there, and I could get at least 3 times the capacity for the same price if I was using IDE... -Joe
Re: Reiser4 crash 2.6.16-mm1
Hans Reiser writes: Jonathan Briggs wrote: On Tue, 2006-03-28 at 07:34 -0800, Joachim Feise wrote: [...] This is a production machine that I can't take offline for too long. But yes, I have compiled the kernel on another reiser4 partition over night, without problems. If this was a memory problem, it would indeed manifest itself in other areas with more or less random errors. The fact that it does not indicates to me that this is a fs problem. So, at this point I am ruling out a memory issue. And if it's a production machine, it is using ECC RAM, I would hope. If it is, memory problems (unreported ones, anyway) are very, very unlikely. Jonathan, be merciful, ECC ram last I checked is twice the cost of regular and the mobs cost more too. (I am sure the cost to produce is < 15% more, which makes it a great pity Intel does not standardize on requiring it and force it to be cheap) Some folks need to save money. Yeah, I know, this time it may have cost him more in cost of his time but we are all just assuming it is memory. Unfortunately, unless he checks it or we see an identical error message from another user with checked memory, or vs tells me he sees a flaw in the code, we need to assume it is memory. The machine is using ECC memory. Geez, I know what I need for a server... From the Dell invoice: 512MB DDR2, 400MHz,2X256MB ECC 1R DIMMs for PowerEdge SC420 Recreating the partition solved the problem. So to me it sure looks like fs corruption. I have sent the dmesg output earlier. -Joe
Re: Reiser4 crash 2.6.16-mm1
Jonathan Briggs writes: On Tue, 2006-03-28 at 07:34 -0800, Joachim Feise wrote: [...] This is a production machine that I can't take offline for too long. But yes, I have compiled the kernel on another reiser4 partition over night, without problems. If this was a memory problem, it would indeed manifest itself in other areas with more or less random errors. The fact that it does not indicates to me that this is a fs problem. So, at this point I am ruling out a memory issue. And if it's a production machine, it is using ECC RAM, I would hope. If Indeed, it does. Dell gets that right on server machines, at least... I have now recreated the fs on that partition, and played the data back from backup, and it works fine. I have made a copy of the old partition with dd, to be able to run some more tests when I have time. -Joe
Re: Reiser4 crash 2.6.16-mm1
Joe Feise wrote on 03/27/06 13:41: > Hi, > > I had an interesting crash on my 2.6.16-mm1 machine earlier today. > I usually mount /usr/local readonly: > /dev/sda6 on /usr/local type reiser4 (ro) > However, since I wanted to update a sw package, I remounted it r/w. > The installation of the sw package failed with reiser4 errors. Sorry, I > don't have a dmesg output at this point, I'll send that tonight when I'm > back at the machine. > But anyway, it reported index errors, and suggested running fsck. > I then ran an fsck.reiser4 --build-fs, which finished without reporting > errors. > In further tests, I mounted /usr/local rw from the start, and saw the > installation fail again. After that, /usr/local/lib was no longer > accessible. > To me, this looks like corruption of some in-memory data structures. > Sorry to not be of more help wrt dmesg output. But I was hoping this is > already known somewhere... The dmesg output is attached. If it matters, the command is make install in SpamAssassin 3.1.1. Oh, and memtest didn't report any errors. -Joe 4>reiser4[perl5.8.6(10861)]: cbk_level_lookup (fs/reiser4/search.c:971)[vs-3533]: WARNING: Keys are inconsistent. Fsck? <4>reiser4[perl5.8.6(10861)]: cut_tree_object (fs/reiser4/tree.c:1793)[nikita-2861]: WARNING: failure: -5 <4>reiser4[perl5.8.6(10861)]: cbk_level_lookup (fs/reiser4/search.c:971)[vs-3533]: WARNING: Keys are inconsistent. Fsck? <4>reiser4[perl5.8.6(10861)]: cbk_level_lookup (fs/reiser4/search.c:971)[vs-3533]: WARNING: Keys are inconsistent. Fsck? <4>reiser4[perl5.8.6(10861)]: cbk_level_lookup (fs/reiser4/search.c:971)[vs-3533]: WARNING: Keys are inconsistent. Fsck? <4>reiser4[perl5.8.6(10861)]: cbk_level_lookup (fs/reiser4/search.c:971)[vs-3533]: WARNING: Keys are inconsistent. Fsck? <4>reiser4[perl5.8.6(10861)]: cut_tree_object (fs/reiser4/tree.c:1793)[nikita-2861]: WARNING: failure: -5 <4>reiser4[perl5.8.6(10861)]: delete_object_unix_file (fs/reiser4/plugin/file/file.c:2987)[]: WARNING: failed to truncate file (125991) on removal: -5 <4>reiser4[perl5.8.6(10861)]: cbk_level_lookup (fs/reiser4/search.c:971)[vs-3533]: WARNING: Keys are inconsistent. Fsck? <4>reiser4[perl5.8.6(10861)]: cut_tree_object (fs/reiser4/tree.c:1793)[nikita-2861]: WARNING: failure: -5 <4>reiser4[perl5.8.6(10861)]: cbk_level_lookup (fs/reiser4/search.c:971)[vs-3533]: WARNING: Keys are inconsistent. Fsck? <4>reiser4[perl5.8.6(10861)]: cbk_level_lookup (fs/reiser4/search.c:971)[vs-3533]: WARNING: Keys are inconsistent. Fsck? <4>reiser4[perl5.8.6(10861)]: cbk_level_lookup (fs/reiser4/search.c:971)[vs-3533]: WARNING: Keys are inconsistent. Fsck? <4>reiser4[perl5.8.6(10861)]: cbk_level_lookup (fs/reiser4/search.c:971)[vs-3533]: WARNING: Keys are inconsistent. Fsck? <4>reiser4[perl5.8.6(10861)]: cut_tree_object (fs/reiser4/tree.c:1793)[nikita-2861]: WARNING: failure: -5 <4>reiser4[perl5.8.6(10861)]: delete_object_unix_file (fs/reiser4/plugin/file/file.c:2987)[]: WARNING: failed to truncate file (125992) on removal: -5 <4>reiser4[perl5.8.6(10861)]: cbk_level_lookup (fs/reiser4/search.c:971)[vs-3533]: WARNING: Keys are inconsistent. Fsck? <4>reiser4[perl5.8.6(10861)]: cut_tree_object (fs/reiser4/tree.c:1793)[nikita-2861]: WARNING: failure: -5 <4>reiser4[perl5.8.6(10861)]: cbk_level_lookup (fs/reiser4/search.c:971)[vs-3533]: WARNING: Keys are inconsistent. Fsck? <4>reiser4[perl5.8.6(10861)]: cbk_level_lookup (fs/reiser4/search.c:971)[vs-3533]: WARNING: Keys are inconsistent. Fsck? <4>reiser4[perl5.8.6(10861)]: cbk_level_lookup (fs/reiser4/search.c:971)[vs-3533]: WARNING: Keys are inconsistent. Fsck? <4>reiser4[perl5.8.6(10861)]: cut_tree_object (fs/reiser4/tree.c:1793)[nikita-2861]: WARNING: failure: -5 <4>reiser4[perl5.8.6(10861)]: delete_object_unix_file (fs/reiser4/plugin/file/file.c:2987)[]: WARNING: failed to truncate file (125993) on removal: -5 <4>reiser4[perl5.8.6(10861)]: cbk_level_lookup (fs/reiser4/search.c:971)[vs-3533]: WARNING: Keys are inconsistent. Fsck? <4>reiser4[perl5.8.6(10861)]: cut_tree_object (fs/reiser4/tree.c:1793)[nikita-2861]: WARNING: failure: -5 <4>reiser4[perl5.8.6(10861)]: cbk_level_lookup (fs/reiser4/search.c:971)[vs-3533]: WARNING: Keys are inconsistent. Fsck? <4>reiser4[perl5.8.6(10861)]: cbk_level_lookup (fs/reiser4/search.c:971)[vs-3533]: WARNING: Keys are inconsistent. Fsck? <4>reiser4[perl5.8.6(10861)]: cbk_level_lookup (fs/reiser4/search.c:971)[vs-3533]: WARNING: Keys are inconsistent. Fsck? <4>reiser4[perl5.8.6(10861)]: cut_tree_object (fs/reiser4/tree.c:1793)[nikita-2861]: WARNING: failure: -5 <4>reiser4[perl5.8.6(10861)]: delete_object_unix_file (fs/reiser4/plugin/file/file.c:2987)[]: WARNING: failed to truncate file (125994) on removal: -5 <
Re: Reiser4 crash 2.6.16-mm1
Toby Thain writes: On 27-Mar-06, at 4:41 PM, Joe Feise wrote: Hi, I had an interesting crash on my 2.6.16-mm1 machine earlier today. I usually mount /usr/local readonly: /dev/sda6 on /usr/local type reiser4 (ro) However, since I wanted to update a sw package, I remounted it r/w. The installation of the sw package failed with reiser4 errors. Sorry, I don't have a dmesg output at this point, I'll send that tonight when I'm back at the machine. But anyway, it reported index errors, and suggested running fsck. I then ran an fsck.reiser4 --build-fs, which finished without reporting errors. In further tests, I mounted /usr/local rw from the start, and saw the installation fail again. After that, /usr/local/lib was no longer accessible. To me, this looks like corruption of some in-memory data structures. Have you run a memtest lately? Thanks for the suggestion. I haven't run a memtest, but I don't really think that the memory is bad. The machine most likely would have had other issues if that was the case. In any case, I will run a memtest tonight, just to make sure. -Joe
Reiser4 crash 2.6.16-mm1
Hi, I had an interesting crash on my 2.6.16-mm1 machine earlier today. I usually mount /usr/local readonly: /dev/sda6 on /usr/local type reiser4 (ro) However, since I wanted to update a sw package, I remounted it r/w. The installation of the sw package failed with reiser4 errors. Sorry, I don't have a dmesg output at this point, I'll send that tonight when I'm back at the machine. But anyway, it reported index errors, and suggested running fsck. I then ran an fsck.reiser4 --build-fs, which finished without reporting errors. In further tests, I mounted /usr/local rw from the start, and saw the installation fail again. After that, /usr/local/lib was no longer accessible. To me, this looks like corruption of some in-memory data structures. Sorry to not be of more help wrt dmesg output. But I was hoping this is already known somewhere... -Joe
Re: Announcements?
Raymond A. Meijer wrote on 03/17/06 02:35: > On Fri 17 Mar 2006 12:25, Brian Uhrain wrote: > >> I just noticed that a Reiser4 patch for kernel 2.6.14.6 was posted on >> ftp.namesys.com yesterday, and I was wondering what changes (if any) >> there are to Reiser4 itself between that patch and the 2.6.15 patch that >> was released two months ago? > > Why aren't these (major) events posted to this list by the ReiserFS crew? > I'm sure that most people here would appreciate that. > > Or maybe create a read-only reiserfs-announce list for this purpose? +1 -Joe
Re: Reiser4 slowdown gone
Sander wrote on 01/29/06 23:25: > Andrew Morton wrote (ao): >> ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.16-rc1/2.6.16-rc1-mm4/ > >> +reiser4-big-update-bug-fix-for-readpage-fix.patch >> +reiser4-warnings-cleanup.patch >> +reiser4-do-not-use-get_user_pages-and-do-not-check.patch >> >> reiser4 fixes and cleanups > > Jumping from 2.6.15-rc1-mm1 to 2.6.16-rc1-mm4. > > For me the Reiser4 slowdown[1] reported on the Reiserfs mailinglist are > gone with this kernel. > > [1] http://humilis.net/reiser4slowdown.html > FWIW, I just ran these tests on 2.6.16-rc1-mm3: kernel: 2.6.16-rc1-mm3 OS: Slackware 10.2 x86 Compiler: gcc (GCC) 3.3.6 Disk: SCSI on Adaptec 29160 single disk, no raid/lvm/etc. # for i in `seq 4`; do echo "foo" > test && time vim +"s/foo/bar/" +"wq" test &> /dev/null ; done real0m2.637s user0m0.032s sys 0m0.040s real0m2.139s user0m0.016s sys 0m0.008s real0m2.137s user0m0.020s sys 0m0.016s real0m2.137s user0m0.020s sys 0m0.008s # strace -T -e sync,fsync ./reiser4-fsync sync() = 0 <2.308290> fsync(3)= 0 <0.071363> -Joe
Re: Read errors from r/o-mounted reiser4
Vladimir V. Saveliev wrote on 01/18/06 17:00: > Hello > > On Tue, 2006-01-17 at 08:56 -0800, Joe Feise wrote: >> unfortunately, the patch did not help. I still get the same errors: >> > sorry, please try new version of patch. (you have to patch -R the old > one). Vladimir, thanks. This patch works. $: mount -o ro,remount /usr $: make xconfig CHECK qt HOSTCC scripts/kconfig/kconfig_load.o /usr/lib/qt/bin/moc -i scripts/kconfig/qconf.h -o scripts/kconfig/qconf.moc HOSTCXX scripts/kconfig/qconf.o HOSTLD scripts/kconfig/qconf ... -Joe
Re: Read errors from r/o-mounted reiser4
Hello, unfortunately, the patch did not help. I still get the same errors: $: mount -o ro,remount /usr $: make xconfig CHECK qt HOSTCC scripts/kconfig/kconfig_load.o In file included from /usr/include/sys/types.h:133, from /usr/include/stdlib.h:433, from scripts/kconfig/kconfig_load.c:3: /usr/include/time.h:418: error: stray '\22' in program /usr/include/time.h:418: error: stray '\377' in program /usr/include/time.h:418: error: stray '\34' in program /usr/include/time.h:418: error: stray '\17' in program /usr/include/time.h:418: error: stray '\21' in program /usr/include/time.h:418: error: stray '\377' in program /usr/include/time.h:418: error: stray '\36' in program /usr/include/time.h:418: error: stray '\21' in program /usr/include/time.h:418: error: stray '\22' in program /usr/include/time.h:418: error: stray '\377' in program ... /usr/include/time.h only has 417 lines. -Joe Vladimir V. Saveliev wrote on 01/17/06 16:08: > Hello > > Sorry for delayed answer. we had long holidays here. > Please try whether attached patch fixes the problem. > > On Mon, 2006-01-02 at 01:04 -0800, Joe Feise wrote: >> Vladimir V. Saveliev wrote on 12/28/05 18:31: >> >>> Hello >>> >>> On Tue, 2005-12-27 at 21:25 -0800, Joe Feise wrote: >>>> Hi, >>>> >>>> in one of my systems, I have /usr on a Reiser4 partition. >>>> When I have that partition mounted read-only, I get errors whenever >>>> I try to compile anything. Other programs that read from that partition >>>> also >>>> seem to fail, but I don't get such nice output like the stuff from gcc. >>>> I am currently using Slackware 10.2 with kernel 2.6.15-rc5-mm3, but I have >>>> experienced the same problem with earlier kernels as well. >>>> The output from a make menuconfig in the kernel source dir: >>> Thanks for the report. We will take a look >>> >>>> $: make menuconfig >>>> >>>> HOSTCC scripts/kconfig/conf.o >>>> In file included from /usr/include/bits/types.h:31, >>>> >>>> from /usr/include/ctype.h:28, >>>> from scripts/kconfig/conf.c:6: >>>> /usr/lib/gcc-lib/i486-slackware-linux/3.3.6/include/stddef.h:420: error: >>>> syntax >>>> error before '}' token >> >> I thought about this a bit more, and decided to take a look at the stddef.h >> file. >> As it turns out, the file has only 419 lines, so line 420 is past the end of >> the >> file. >> That indicates to me that there is possibly a buffer that doesn't get >> cleared if >> the fs is mounted r/o (an optimization gone wrong, maybe?) >> >> -Joe
Re: Bug (?) with 2.6.15-mm4
Heiko Przybyl wrote on 01/16/06 12:29: > just a quick dirty and possible bad thought: > > > -mm4: > > +i386-enable-4k-stacks-by-default.patch > > Test 4k stacks some more > > > reiser4: > > Note: please make sure that you have checked in > > Code maturity level options > ---> Prompt for development and/or incomplete code/drivers > > and NOT checked in > > Kernel hacking ---> Use 4Kb for kernel stacks instead of 8Kb > > > > maybe the default config option of 4k stacks kills reiser4? so i won't test > it for now :-) Well, for my configuration, the "use 4kb+4kb for kernel stacks instead of 8kb" option is turned off. I followed some of the 4kb stack posts on LKML, so I made sure to stick to 8kb for the time being. Thanks for the suggestion, though. -Joe
Re: Bug (?) with 2.6.15-mm4
Andrea Gelmini wrote on 01/16/06 10:22: > Hi all, > a few line, without logs and in depth info, to describe a problem > (if it's not already known, I will do a real bug report). > > Well, I've got a Satellite P20, with /dev/md1 crypto-loopbacked > with /dev/loop0 (losetup -e aes), and /dev/loop0 mount on / with > reiser4. > With > Linux cogno 2.6.15-mm2 #1 PREEMPT Sun Jan 8 14:27:42 CET 2006 i686 GNU/Linux > everything works fine since the day I compiled it. > Same config, but -mm4, I've got freeze. Sometimes after minutes, > sometimes after hours. > After last crash I booted from a rescue partition. Mounting > partition where system was writing gives no warning, but checking > it with fsck.reiser4 (Debian testing, package reiser4progs version > 1.0.5-1) > two inconsistency were founded (and fixed). > > Thanks a lot for your time and your work, > gelma > I also see freezes, since 2.6.15-mm2. I did not attribute that to reiser4, though, since there is more in the -mm patches. I have noticed, though, that at least the last -mm4 freeze resulted in serious reiser4 corruption. I had to use the --build-fs option to fsck.reiser4. -Joe
Re: Read errors from r/o-mounted reiser4
Vladimir V. Saveliev wrote on 12/28/05 18:31: > Hello > > On Tue, 2005-12-27 at 21:25 -0800, Joe Feise wrote: >> Hi, >> >> in one of my systems, I have /usr on a Reiser4 partition. >> When I have that partition mounted read-only, I get errors whenever >> I try to compile anything. Other programs that read from that partition also >> seem to fail, but I don't get such nice output like the stuff from gcc. >> I am currently using Slackware 10.2 with kernel 2.6.15-rc5-mm3, but I have >> experienced the same problem with earlier kernels as well. >> The output from a make menuconfig in the kernel source dir: > > Thanks for the report. We will take a look > >> $: make menuconfig >> >> HOSTCC scripts/kconfig/conf.o >> In file included from /usr/include/bits/types.h:31, >> >> from /usr/include/ctype.h:28, >> from scripts/kconfig/conf.c:6: >> /usr/lib/gcc-lib/i486-slackware-linux/3.3.6/include/stddef.h:420: error: >> syntax >> error before '}' token I thought about this a bit more, and decided to take a look at the stddef.h file. As it turns out, the file has only 419 lines, so line 420 is past the end of the file. That indicates to me that there is possibly a buffer that doesn't get cleared if the fs is mounted r/o (an optimization gone wrong, maybe?) -Joe
Read errors from r/o-mounted reiser4
Hi, in one of my systems, I have /usr on a Reiser4 partition. When I have that partition mounted read-only, I get errors whenever I try to compile anything. Other programs that read from that partition also seem to fail, but I don't get such nice output like the stuff from gcc. I am currently using Slackware 10.2 with kernel 2.6.15-rc5-mm3, but I have experienced the same problem with earlier kernels as well. The output from a make menuconfig in the kernel source dir: $: make menuconfig HOSTCC scripts/kconfig/conf.o In file included from /usr/include/bits/types.h:31, from /usr/include/ctype.h:28, from scripts/kconfig/conf.c:6: /usr/lib/gcc-lib/i486-slackware-linux/3.3.6/include/stddef.h:420: error: syntax error before '}' token /usr/lib/gcc-lib/i486-slackware-linux/3.3.6/include/stddef.h:420: error: stray '\24' in program /usr/lib/gcc-lib/i486-slackware-linux/3.3.6/include/stddef.h:420: error: syntax error at '@' token /usr/lib/gcc-lib/i486-slackware-linux/3.3.6/include/stddef.h:420: error: stray '\17' in program /usr/lib/gcc-lib/i486-slackware-linux/3.3.6/include/stddef.h:420: error: stray '\205' in program /usr/lib/gcc-lib/i486-slackware-linux/3.3.6/include/stddef.h:420: error: stray '\275' in program /usr/lib/gcc-lib/i486-slackware-linux/3.3.6/include/stddef.h:420: error: stray '\374' in program /usr/lib/gcc-lib/i486-slackware-linux/3.3.6/include/stddef.h:420: error: stray '\377' in program /usr/lib/gcc-lib/i486-slackware-linux/3.3.6/include/stddef.h:420: error: stray '\377' in program /usr/lib/gcc-lib/i486-slackware-linux/3.3.6/include/stddef.h:420: error: stray '\213' in program /usr/lib/gcc-lib/i486-slackware-linux/3.3.6/include/stddef.h:420: error: stray '\10' in program /usr/lib/gcc-lib/i486-slackware-linux/3.3.6/include/stddef.h:420: error: stray '\205' in program /usr/lib/gcc-lib/i486-slackware-linux/3.3.6/include/stddef.h:420: error: stray '\300' in program /usr/lib/gcc-lib/i486-slackware-linux/3.3.6/include/stddef.h:420: error: stray '\265' in program /usr/lib/gcc-lib/i486-slackware-linux/3.3.6/include/stddef.h:420: error: stray '\211' in program /usr/lib/gcc-lib/i486-slackware-linux/3.3.6/include/stddef.h:420: error: stray '\24' in program /usr/lib/gcc-lib/i486-slackware-linux/3.3.6/include/stddef.h:420: error: stray '\211' in program /usr/lib/gcc-lib/i486-slackware-linux/3.3.6/include/stddef.h:420: error: stray '\4' in program /usr/lib/gcc-lib/i486-slackware-linux/3.3.6/include/stddef.h:420: error: stray '\350' in program make[1]: *** [scripts/kconfig/conf.o] Interrupt make: *** [menuconfig] Interrupt I interrupted it here. Everything works fine if the partition is mounted r/w. -Joe
