Re: new reiser4 patch for linux-2.6.16 is available, upgrade from reiser4-for-2.6.16-4 recommended.
I stress tested this patch for 18hrs on my machine, and it seems stable. Thanks for the update and warning. On Wed, 2006-08-02 at 23:55 +0400, Alexander Zarochentsev wrote: > Hello, > > reiser4-for-2.6.16-4.patch contains a bug which can cause fs corruption > (it is the same bug as is in the first reiser4 patches for > linux-2.6.17, now fixed). > > If you use that buggy patch, please upgrade you kernel and reiser4 code > to 2.6.17/reiser4-for-2.6.17-3 or use new reiser4-for-2.6.16-5.patch.gz > from ftp://ftp.namesys.com/pub/reiser4-for-2.6/2.6.16/. > > The bug fix is available as a separate patch > reiser4-for-2.6.16-4--missing-unlock-fix.diff at > ftp://ftp.namesys.com/pub/reiser4-for-2.6/2.6.16/hotfixes/ > > -- > Alex. > -- Jake Maciejewski <[EMAIL PROTECTED]>
Re: reiser4 OOPSes and panics when out of memory
I haven't hit nikita-2967 again, but I got several other interesting results. The first panic didn't cause corruption: reiser4 panicked cowardly: reiser4[pdflush(16048)]: scan_by_coord (fs/reiser4/flush.c:3431)[nikita-3435]: Kernel panic - not syncing: reiser4[pdflush(16048)]: scan_by_coord (fs/reiser4/flush.c:3431)[nikita-3435]: The second affected my root partition, not the one I was stress testing: reiser4 panicked cowardly: reiser4[ent:hda3!(841)]: capture_anonymous_pages (fs/reiser4/plugin/file/file.c:1007)[vs-49]: Kernel panic - not syncing: reiser4[end:hda3!(841)]: capture_anonymous_pages (fs/reiser4/plugin/file/file.c:1007)[vs-49]: I booted from a live CD to document the corruption (which seemed to have been completely fixed). http://people.msoe.edu/~maciejej/patches/AMD64_reiser4_debug/20060720/fsck2_--check_hda3.txt.gz http://people.msoe.edu/~maciejej/patches/AMD64_reiser4_debug/20060720/fsck2_--fix_hda3.txt.gz http://people.msoe.edu/~maciejej/patches/AMD64_reiser4_debug/20060720/fsck2_--check_after_--fix_hda3.txt.gz When I rebooted, I got another panic when my system tried to mount / read-write: reiser4 pnicked cowardly: reiser4[mount(3614)]: check_blocks_bitmap (fs/reiser4/plugin/space/bitmap.c:1268)[zam-623]: Kernel panic - not syncing: reiser4[mount(3614)]: check_blocks_bitmap (fs/reiser4/plugin/space/bitmap.c:1268)[zam-623]: On the second reboot, it worked again. The third panic was one I've seen before (http://marc.theaimsgroup.com/?l=reiserfs&m=115259665831650&w=2): reiser4 panicked cowardly: reiser4[rm(25870)]: sibling_list_remove (fs/reiser4/tree_walk.c:813)[zam-32245]: Kernel panic - not syncing: reiser4[rm(25870)]: sibling_list_remove (fs/reiser4/tree_walk.c:813)[zam-32245]: http://people.msoe.edu/~maciejej/patches/AMD64_reiser4_debug/20060720/fsck3_--check.txt.gz http://people.msoe.edu/~maciejej/patches/AMD64_reiser4_debug/20060720/fsck3_--fix.txt.gz http://people.msoe.edu/~maciejej/patches/AMD64_reiser4_debug/20060720/fsck3_--check_after_--fix.txt.gz The fourth was another repeat: reiser4 panicked cowardly: reiser4[pdflush(198)]: capture_anonymous_pages (fs/reiser4/plugin/file/file.c:1007)[vs-49]: Kernel panic - not syncing: reiser4[pdflush(198)]: capture_anonymous_pages (fs/reiser4/plugin/file/file.c:1007)[vs-49]: http://people.msoe.edu/~maciejej/patches/AMD64_reiser4_debug/20060720/fsck4_--check.txt.gz http://people.msoe.edu/~maciejej/patches/AMD64_reiser4_debug/20060720/fsck4_--fix.txt.gz http://people.msoe.edu/~maciejej/patches/AMD64_reiser4_debug/20060720/fsck4_--check_after_fix.txt.gz Where the fsck logs from tests 3 and 4 say entries were removed, they mean it. Those files were GONE. I would expect this to happen to temporary files being written during the panic, but header files should only have been open for reading if at all. I have metadata dumps from before and after one of the fsck --fix runs. Should I make them available? On Wed, 2006-07-19 at 18:07 +0400, Vladimir V. Saveliev wrote: > Hello > > On Wed, 2006-07-19 at 07:28 -0600, Jake Maciejewski wrote: > > Thanks. Now with debug enabled I've gotten: > > > > http://people.msoe.edu/~maciejej/patches/AMD64_reiser4_debug/20060719/panic1.txt.gz > > the attached patch fixes a problem nikita-2967 reports about. Would you > please check whther it helps. > > > http://people.msoe.edu/~maciejej/patches/AMD64_reiser4_debug/20060719/fsck1_--check.txt.gz > > http://people.msoe.edu/~maciejej/patches/AMD64_reiser4_debug/20060719/fsck1_--fix.txt.gz > > http://people.msoe.edu/~maciejej/patches/AMD64_reiser4_debug/20060719/fsck1_--check_after_--fix.txt.gz > > > > and > > > > http://people.msoe.edu/~maciejej/patches/AMD64_reiser4_debug/20060719/messages2.txt.gz > > followed by > > http://people.msoe.edu/~maciejej/patches/AMD64_reiser4_debug/20060719/messages2b.txt.gz > > > > and without debug: > > > > http://people.msoe.edu/~maciejej/patches/AMD64_reiser4_debug/20060719/messages3.txt.gz > > http://people.msoe.edu/~maciejej/patches/AMD64_reiser4_debug/20060719/fsck3_--check.txt.gz > > http://people.msoe.edu/~maciejej/patches/AMD64_reiser4_debug/20060719/fsck3_--fix.txt.gz > > http://people.msoe.edu/~maciejej/patches/AMD64_reiser4_debug/20060719/fsck3_--check_after_--fix.txt.gz > > > > On Tue, 2006-07-18 at 18:18 +0400, Vladimir V. Saveliev wrote: > > > Hello > > > > > > On Tue, 2006-07-18 at 00:52 -0600, Jake Maciejewski wrote: > > > > Thanks for the patch, but I can still reproduce the problem. I've been > > > > running the attached program to try
Re: reiser4 OOPSes and panics when out of memory
Thanks. Now with debug enabled I've gotten: http://people.msoe.edu/~maciejej/patches/AMD64_reiser4_debug/20060719/panic1.txt.gz http://people.msoe.edu/~maciejej/patches/AMD64_reiser4_debug/20060719/fsck1_--check.txt.gz http://people.msoe.edu/~maciejej/patches/AMD64_reiser4_debug/20060719/fsck1_--fix.txt.gz http://people.msoe.edu/~maciejej/patches/AMD64_reiser4_debug/20060719/fsck1_--check_after_--fix.txt.gz and http://people.msoe.edu/~maciejej/patches/AMD64_reiser4_debug/20060719/messages2.txt.gz followed by http://people.msoe.edu/~maciejej/patches/AMD64_reiser4_debug/20060719/messages2b.txt.gz and without debug: http://people.msoe.edu/~maciejej/patches/AMD64_reiser4_debug/20060719/messages3.txt.gz http://people.msoe.edu/~maciejej/patches/AMD64_reiser4_debug/20060719/fsck3_--check.txt.gz http://people.msoe.edu/~maciejej/patches/AMD64_reiser4_debug/20060719/fsck3_--fix.txt.gz http://people.msoe.edu/~maciejej/patches/AMD64_reiser4_debug/20060719/fsck3_--check_after_--fix.txt.gz On Tue, 2006-07-18 at 18:18 +0400, Vladimir V. Saveliev wrote: > Hello > > On Tue, 2006-07-18 at 00:52 -0600, Jake Maciejewski wrote: > > Thanks for the patch, but I can still reproduce the problem. I've been > > running the attached program to try to speed up the testing process a > > bit. Interrupting and restarting the compilation loop also seems to > > help. > > > > ok > > > If I had hours to wait, it would probably crash eventually without > > additional encouragement, but I'm doing everything as an unprivileged > > user, so I don't think my tests are unreasonable. > > > > Anyway, I'm still getting a panic with debug enabled: > > > > reiser4 panicked cowardly: reiser4[find(16411)]: reiser4_dirty_inode > > (fs/reiser4/super_ops.c:173)[]: > > Kernel panic - not syncing: reiser4[find(16411)]: reiser4_dirty_inode > > (fs/reiser4/super_ops.c:173)[]: > > > > The attached patch should fix the above. > > > Without debug enabled I've seen: > > > > http://people.msoe.edu/~maciejej/patches/AMD64_reiser4_debug/20060718/messages1.txt.gz > > http://people.msoe.edu/~maciejej/patches/AMD64_reiser4_debug/20060718/fsck1_--check.txt.gz > > http://people.msoe.edu/~maciejej/patches/AMD64_reiser4_debug/20060718/fsck1_--fix.txt.gz > > http://people.msoe.edu/~maciejej/patches/AMD64_reiser4_debug/20060718/fsck1_--check_after_--fix.txt.gz > > > > but usually I get: > > > > http://people.msoe.edu/~maciejej/patches/AMD64_reiser4_debug/20060718/messages3.txt.gz > > > > with no corruption (although I've been rebooting before complete > > failure). > > > > On Mon, 2006-07-17 at 21:38 +0400, Vladimir V. Saveliev wrote: > > > Hello > > > > > > On Mon, 2006-07-17 at 18:10 +0400, Vladimir V. Saveliev wrote: > > > > Hello > > > > > > > > On Sun, 2006-07-16 at 12:44 -0500, [EMAIL PROTECTED] wrote: > > > > > Has my previous post > > > > > (http://marc.theaimsgroup.com/?l=reiserfs&m=115259665831650&w=2) been > > > > > overlooked, or have I not provided enough information? Do I need to > > > > > reproduce these issues on 2.6.18-rc1-mm2? Should I be trying any > > > > > patches? > > > > > > > > > > > > > > > please try the attached patch. > > > > > > > your test crashes reiser4 on my test box. I hope to get a patch ready > > > > later today. Not sure that I got the same problem as you, though. We > > > > will see. > > > > > > > > > The bottom line is with 2.6.17-mm6, I've always been able to OOPs or > > > > > panic > > > > > reiser4 on my amd64 machine (haven't tried x86 yet) by using all > > > > > available > > > > > physical memory. > > > > > > > > > > > > > > > > > > -- Jake Maciejewski <[EMAIL PROTECTED]>
Re: reiser4 OOPSes and panics when out of memory
Thanks for the patch, but I can still reproduce the problem. I've been
running the attached program to try to speed up the testing process a
bit. Interrupting and restarting the compilation loop also seems to
help.
If I had hours to wait, it would probably crash eventually without
additional encouragement, but I'm doing everything as an unprivileged
user, so I don't think my tests are unreasonable.
Anyway, I'm still getting a panic with debug enabled:
reiser4 panicked cowardly: reiser4[find(16411)]: reiser4_dirty_inode
(fs/reiser4/super_ops.c:173)[]:
Kernel panic - not syncing: reiser4[find(16411)]: reiser4_dirty_inode
(fs/reiser4/super_ops.c:173)[]:
Without debug enabled I've seen:
http://people.msoe.edu/~maciejej/patches/AMD64_reiser4_debug/20060718/messages1.txt.gz
http://people.msoe.edu/~maciejej/patches/AMD64_reiser4_debug/20060718/fsck1_--check.txt.gz
http://people.msoe.edu/~maciejej/patches/AMD64_reiser4_debug/20060718/fsck1_--fix.txt.gz
http://people.msoe.edu/~maciejej/patches/AMD64_reiser4_debug/20060718/fsck1_--check_after_--fix.txt.gz
but usually I get:
http://people.msoe.edu/~maciejej/patches/AMD64_reiser4_debug/20060718/messages3.txt.gz
with no corruption (although I've been rebooting before complete
failure).
On Mon, 2006-07-17 at 21:38 +0400, Vladimir V. Saveliev wrote:
> Hello
>
> On Mon, 2006-07-17 at 18:10 +0400, Vladimir V. Saveliev wrote:
> > Hello
> >
> > On Sun, 2006-07-16 at 12:44 -0500, [EMAIL PROTECTED] wrote:
> > > Has my previous post
> > > (http://marc.theaimsgroup.com/?l=reiserfs&m=115259665831650&w=2) been
> > > overlooked, or have I not provided enough information? Do I need to
> > > reproduce these issues on 2.6.18-rc1-mm2? Should I be trying any patches?
> > >
> >
>
> please try the attached patch.
>
> > your test crashes reiser4 on my test box. I hope to get a patch ready
> > later today. Not sure that I got the same problem as you, though. We
> > will see.
> >
> > > The bottom line is with 2.6.17-mm6, I've always been able to OOPs or panic
> > > reiser4 on my amd64 machine (haven't tried x86 yet) by using all available
> > > physical memory.
> > >
> > >
> >
> >
--
Jake Maciejewski <[EMAIL PROTECTED]>
#include
#include
#include
#include
#include
#include
#define MB 1048576
#define DEFAULT_SAVE 0
#define DELAY 10
int main(int argc, char *argv[]) {
struct sysinfo info;
size_t waste, save;
void *ptr;
sysinfo(&info);
if(argc>1)
save = atoi(argv[1])*MB;
else
save = DEFAULT_SAVE*MB;
if( save >= info.freeram ) {
fprintf(stderr, "error: only %iMB free\n", (int)info.freeram/MB);
return ENOMEM;
}
while(1) {
sysinfo(&info);
waste = (info.freeram-save)>0 ? info.freeram-save : 0;
ptr = malloc(waste);
if( ptr == 0 ) {
perror("malloc() failed\n");
return ENOMEM;
}
printf("reserving %iMB, wasting %iMB\n", (int)save/MB, (int)waste/MB);
memset(ptr, 0, waste);
sleep(DELAY);
free(ptr);
}
return 0;
}
Re: reiser4 oops
I tried 2.6.17-mm6 (was the latest at the time) and reiser4 still always fails when it runs out of memory. My test has been building a kernel with enough jobs to exhaust memory. Expecting problems, I began by testing reiser4 with debugging enabled. The first time, I got the panic below after running "while true ; do make mrproper && zcat /proc/config.gz > .config && make -j64 ; done" in linux-2.6.17-mm6 (on a fresh test filesystem) for an unknown duration of time. reiser4 panicked cowardly: reiser4[cc1(12238)]: page_bio (fs/reiser4/page_cache.c:434)[nikita-2276]: Kernel panic - not syncing: reiser4[cc1(12238)]: page_bio (fs/reiser4/page_cache.c:434)[nikita-2276]: The next two times, after about half an hour of the above command I got the panic below (except the second time was with cc1 instead of fixdep). reiser4 panicked cowardly: reiser4[fixdep(19463)]: sibling_list_remove (fs/reiser4/tree_walk.c:813)[zam-32245]: Kernel panic - not syncing: reiser4[fixdep(19463)]: sibling_list_remove (fs/reiser4/tree_walk.c:813)[zam-32245]: The third time the filesystem wasn't clean after a reboot. fsck.reiser4 --check logged: http://people.msoe.edu/~maciejej/patches/AMD64_reiser4_debug/20060711/fsck3_--check.txt.gz fsck.reiser4 --fix logged: http://people.msoe.edu/~maciejej/patches/AMD64_reiser4_debug/20060711/fsck3_--fix.txt.gz Another --check turned up clean: http://people.msoe.edu/~maciejej/patches/AMD64_reiser4_debug/20060711/fsck3_--check_after_--fix.txt.gz Things got slightly more interesting with debugging disabled. The first time I got the following OOPS after some "flushing like mad" messages. A bunch of cc1 process were stuck in the D state. http://people.msoe.edu/~maciejej/patches/AMD64_reiser4_debug/20060711/messages4.txt.gz http://people.msoe.edu/~maciejej/patches/AMD64_reiser4_debug/20060711/fsck4_--check.txt.gz http://people.msoe.edu/~maciejej/patches/AMD64_reiser4_debug/20060711/fsck4_--fix.txt.gz http://people.msoe.edu/~maciejej/patches/AMD64_reiser4_debug/20060711/fsck4_--check_after_--fix.txt.gz The second time I got: http://people.msoe.edu/~maciejej/patches/AMD64_reiser4_debug/20060711/messages5.txt.gz http://people.msoe.edu/~maciejej/patches/AMD64_reiser4_debug/20060711/fsck5_--check.txt.gz http://people.msoe.edu/~maciejej/patches/AMD64_reiser4_debug/20060711/fsck5_--fix.txt.gz http://people.msoe.edu/~maciejej/patches/AMD64_reiser4_debug/20060711/fsck5_--check_after_--fix.txt.gz On Fri, 2006-07-07 at 17:16 +0400, Vladimir V. Saveliev wrote: > Hello > > On Fri, 2006-07-07 at 01:18 -0600, Jake Maciejewski wrote: > > It doesn't look like this issue has been fixed: > > > > http://people.msoe.edu/~maciejej/patches/AMD64_reiser4_debug/20060702/reiser4_kio_http.txt.gz > > > > Again fsck showed a clean filesystem. Should I try -mm? > > > > Yes, please try to check whether latest mm has this problem. > > > This is somewhat difficult to reproduce because the critical factor > > seems to be using all available memory, however in doing so the system > > quickly becomes unresponsive. > > > > On Mon, 2006-07-03 at 17:23 -0600, Jake Maciejewski wrote: > > > Thanks for the patch. I don't think I'll be able to test it before > > > Wednesday, though. > > > > > > On Mon, 2006-07-03 at 14:10 +0400, Vladimir V. Saveliev wrote: > > > > Hello > > > > > > > > On Sun, 2006-07-02 at 22:24 -0600, Jake Maciejewski wrote: > > > > > I'm seeing this on 2.6.16.20 with the -4 patch, amd64 with preempt. > > > > > The > > > > > OOM killer was called even though I have 1GB RAM and 4GB swap. My logs > > > > > are available at: > > > > > > > > > > http://people.msoe.edu/~maciejej/patches/AMD64_reiser4_debug/20060702/oom.txt.gz > > > > > > > > > > Both affected filesystems (rsync was using one filesystem, cc1 the > > > > > other) came up clean with fsck. > > > > > > > > > > On Sat, 2006-07-01 at 22:08 +0200, Łukasz Mierzwa wrote: > > > > > > I'm running x86 gentoo system with / on reiser4, I'm using > > > > > > suspend-sources-2.6.16-r8 kernel with 2.6.16-4 patch. Today I run > > > > > > emerge > > > > > > --sync, after that I started to compile new xine-lib while browsing > > > > > > net, > > > > > > when xine-lib was finishing I got this errors: > > > > > > > > > > > > kernel BUG at fs/inode.c:253! > > > > > > > > would you please check whether this patch helps? > > > > ftp://ftp.ru.kernel.org/pu
Re: reiser4 oops
It doesn't look like this issue has been fixed: http://people.msoe.edu/~maciejej/patches/AMD64_reiser4_debug/20060702/reiser4_kio_http.txt.gz Again fsck showed a clean filesystem. Should I try -mm? This is somewhat difficult to reproduce because the critical factor seems to be using all available memory, however in doing so the system quickly becomes unresponsive. On Mon, 2006-07-03 at 17:23 -0600, Jake Maciejewski wrote: > Thanks for the patch. I don't think I'll be able to test it before > Wednesday, though. > > On Mon, 2006-07-03 at 14:10 +0400, Vladimir V. Saveliev wrote: > > Hello > > > > On Sun, 2006-07-02 at 22:24 -0600, Jake Maciejewski wrote: > > > I'm seeing this on 2.6.16.20 with the -4 patch, amd64 with preempt. The > > > OOM killer was called even though I have 1GB RAM and 4GB swap. My logs > > > are available at: > > > > > > http://people.msoe.edu/~maciejej/patches/AMD64_reiser4_debug/20060702/oom.txt.gz > > > > > > Both affected filesystems (rsync was using one filesystem, cc1 the > > > other) came up clean with fsck. > > > > > > On Sat, 2006-07-01 at 22:08 +0200, Łukasz Mierzwa wrote: > > > > I'm running x86 gentoo system with / on reiser4, I'm using > > > > suspend-sources-2.6.16-r8 kernel with 2.6.16-4 patch. Today I run emerge > > > > --sync, after that I started to compile new xine-lib while browsing net, > > > > when xine-lib was finishing I got this errors: > > > > > > > > kernel BUG at fs/inode.c:253! > > > > would you please check whether this patch helps? > > ftp://ftp.ru.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.17/2.6.17-mm5/broken-out/reiser4-run-truncate_inode_pages-in-reiser4_delete_inode.patch > > > > > > > > invalid opcode: [#1] > > > > PREEMPT > > > > Modules linked in: ndiswrapper fglrx acer_acpi nsc_ircc irda crc_ccitt > > > > snd_atiixp snd_ac97_codec snd_ac97_bus yenta_socket rsrc_nonstatic > > > > pcmcia_core tifm_7xx1 tifm_core > > > > CPU:0 > > > > EIP:0060:[]Tainted: P VLI > > > > EFLAGS: 00010206 (2.6.16-suspend2-r8 #2) > > > > EIP is at clear_inode+0x16/0xb0 > > > > eax: 0003 ebx: d5245d20 ecx: edx: d5245df8 > > > > esi: df2099c0 edi: c2a3a000 ebp: c2a3a000 esp: c2a3be94 > > > > ds: 007b es: 007b ss: 0068 > > > > Process emerge (pid: 9123, threadinfo=c2a3a000 task=c2a0ba70) > > > > Stack: <0>df2099c0 d5245d20 df2099c0 c01db519 c017a385 0400 > > > > d5245e28 > > > > d5245d20 c2a3a000 d415c114 d5245d20 c01db4e0 c017bd59 d5245d20 > > > > dfe9b000 > > > > c017b81c d415c114 c017a431 dfe9b000 df533000 > > > > c2a3bf50 c0172d74 > > > > Call Trace: > > > > [] reiser4_delete_inode+0x39/0xc0 > > > > [] dput+0x25/0x170 > > > >[] reiser4_delete_inode+0x0/0xc0 > > > > [] generic_delete_inode+0x69/0x100 > > > > [] iput+0x5c/0x70 > > > > [] dput+0xd1/0x170 > > > >[] sys_renameat+0x1c4/0x1f0 > > > > [] sys_rename+0x27/0x30 > > > > [] sysenter_past_esp+0x54/0x75 > > > > Code: 80 98 00 00 00 8b 40 38 eb c4 8d 74 26 > > > > 00 8d > > > > bc 27 00 00 00 00 56 53 89 c3 83 ec 04 e8 14 b0 fe ff 8b 83 c4 00 00 00 > > > > 85 > > > > c0 74 08 <0f> 0b fd 00 ab d4 37 c0 8b 83 20 01 00 00 a8 10 75 08 0f 0b > > > > ff > > > > <4>reiser4[emerge(9123)]: release_unix_file > > > > (fs/reiser4/plugin/file/file.c:2294)[vs-44]: > > > > WARNING: out of memory? > > > > reiser4[emerge(9123)]: release_unix_file > > > > (fs/reiser4/plugin/file/file.c:2294)[vs-44]: > > > > WARNING: out of memory? > > > > reiser4[emerge(9123)]: release_unix_file > > > > (fs/reiser4/plugin/file/file.c:2294)[vs-44]: > > > > WARNING: out of memory? > > > > reiser4[emerge(9123)]: release_unix_file > > > > (fs/reiser4/plugin/file/file.c:2294)[vs-44]: > > > >
Re: reiser4 oops
Thanks for the patch. I don't think I'll be able to test it before Wednesday, though. On Mon, 2006-07-03 at 14:10 +0400, Vladimir V. Saveliev wrote: > Hello > > On Sun, 2006-07-02 at 22:24 -0600, Jake Maciejewski wrote: > > I'm seeing this on 2.6.16.20 with the -4 patch, amd64 with preempt. The > > OOM killer was called even though I have 1GB RAM and 4GB swap. My logs > > are available at: > > > > http://people.msoe.edu/~maciejej/patches/AMD64_reiser4_debug/20060702/oom.txt.gz > > > > Both affected filesystems (rsync was using one filesystem, cc1 the > > other) came up clean with fsck. > > > > On Sat, 2006-07-01 at 22:08 +0200, Łukasz Mierzwa wrote: > > > I'm running x86 gentoo system with / on reiser4, I'm using > > > suspend-sources-2.6.16-r8 kernel with 2.6.16-4 patch. Today I run emerge > > > --sync, after that I started to compile new xine-lib while browsing net, > > > when xine-lib was finishing I got this errors: > > > > > > kernel BUG at fs/inode.c:253! > > would you please check whether this patch helps? > ftp://ftp.ru.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.17/2.6.17-mm5/broken-out/reiser4-run-truncate_inode_pages-in-reiser4_delete_inode.patch > > > > > invalid opcode: [#1] > > > PREEMPT > > > Modules linked in: ndiswrapper fglrx acer_acpi nsc_ircc irda crc_ccitt > > > snd_atiixp snd_ac97_codec snd_ac97_bus yenta_socket rsrc_nonstatic > > > pcmcia_core tifm_7xx1 tifm_core > > > CPU:0 > > > EIP:0060:[]Tainted: P VLI > > > EFLAGS: 00010206 (2.6.16-suspend2-r8 #2) > > > EIP is at clear_inode+0x16/0xb0 > > > eax: 0003 ebx: d5245d20 ecx: edx: d5245df8 > > > esi: df2099c0 edi: c2a3a000 ebp: c2a3a000 esp: c2a3be94 > > > ds: 007b es: 007b ss: 0068 > > > Process emerge (pid: 9123, threadinfo=c2a3a000 task=c2a0ba70) > > > Stack: <0>df2099c0 d5245d20 df2099c0 c01db519 c017a385 0400 > > > d5245e28 > > > d5245d20 c2a3a000 d415c114 d5245d20 c01db4e0 c017bd59 d5245d20 > > > dfe9b000 > > > c017b81c d415c114 c017a431 dfe9b000 df533000 > > > c2a3bf50 c0172d74 > > > Call Trace: > > > [] reiser4_delete_inode+0x39/0xc0 > > > [] dput+0x25/0x170 > > >[] reiser4_delete_inode+0x0/0xc0 > > > [] generic_delete_inode+0x69/0x100 > > > [] iput+0x5c/0x70 > > > [] dput+0xd1/0x170 > > >[] sys_renameat+0x1c4/0x1f0 > > > [] sys_rename+0x27/0x30 > > > [] sysenter_past_esp+0x54/0x75 > > > Code: 80 98 00 00 00 8b 40 38 eb c4 8d 74 26 00 > > > 8d > > > bc 27 00 00 00 00 56 53 89 c3 83 ec 04 e8 14 b0 fe ff 8b 83 c4 00 00 00 85 > > > c0 74 08 <0f> 0b fd 00 ab d4 37 c0 8b 83 20 01 00 00 a8 10 75 08 0f 0b ff > > > <4>reiser4[emerge(9123)]: release_unix_file > > > (fs/reiser4/plugin/file/file.c:2294)[vs-44]: > > > WARNING: out of memory? > > > reiser4[emerge(9123)]: release_unix_file > > > (fs/reiser4/plugin/file/file.c:2294)[vs-44]: > > > WARNING: out of memory? > > > reiser4[emerge(9123)]: release_unix_file > > > (fs/reiser4/plugin/file/file.c:2294)[vs-44]: > > > WARNING: out of memory? > > > reiser4[emerge(9123)]: release_unix_file > > > (fs/reiser4/plugin/file/file.c:2294)[vs-44]: > > > WARNING: out of memory? > > > reiser4[emerge(9123)]: release_unix_file > > > (fs/reiser4/plugin/file/file.c:2294)[vs-44]: > > > WARNING: out of memory? > > > reiser4[emerge(9123)]: release_unix_file > > > (fs/reiser4/plugin/file/file.c:2294)[vs-44]: > > > WARNING: out of memory? > > > reiser4[emerge(9123)]: release_unix_file > > > (fs/reiser4/plugin/file/file.c:2294)[vs-44]: > > > WARNING: out of memory? > > > reiser4[emerge(9123)]: release_unix_file > > > (fs/reiser4/plugin/file/file.c:2294)[vs-44]: > > >
Re: reiser4 oops
WARNING: out of memory? > reiser4[emerge(9123)]: release_unix_file > (fs/reiser4/plugin/file/file.c:2294)[vs-44]: > WARNING: out of memory? > reiser4[emerge(9123)]: release_unix_file > (fs/reiser4/plugin/file/file.c:2294)[vs-44]: > WARNING: out of memory? > reiser4[emerge(9123)]: release_unix_file > (fs/reiser4/plugin/file/file.c:2294)[vs-44]: > WARNING: out of memory? > reiser4[emerge(9123)]: release_unix_file > (fs/reiser4/plugin/file/file.c:2294)[vs-44]: > WARNING: out of memory? > reiser4[emerge(9123)]: release_unix_file > (fs/reiser4/plugin/file/file.c:2294)[vs-44]: > WARNING: out of memory? > reiser4[emerge(9123)]: release_unix_file > (fs/reiser4/plugin/file/file.c:2294)[vs-44]: > WARNING: out of memory? > reiser4[emerge(9123)]: release_unix_file > (fs/reiser4/plugin/file/file.c:2294)[vs-44]: > WARNING: out of memory? > reiser4[emerge(9123)]: release_unix_file > (fs/reiser4/plugin/file/file.c:2294)[vs-44]: > WARNING: out of memory? > reiser4[emerge(9123)]: release_unix_file > (fs/reiser4/plugin/file/file.c:2294)[vs-44]: > WARNING: out of memory? > reiser4[emerge(9123)]: release_unix_file > (fs/reiser4/plugin/file/file.c:2294)[vs-44]: > WARNING: out of memory? > reiser4[emerge(9123)]: release_unix_file > (fs/reiser4/plugin/file/file.c:2294)[vs-44]: > WARNING: out of memory? > reiser4[emerge(9123)]: release_unix_file > (fs/reiser4/plugin/file/file.c:2294)[vs-44]: > WARNING: out of memory? > reiser4[emerge(9123)]: release_unix_file > (fs/reiser4/plugin/file/file.c:2294)[vs-44]: > WARNING: out of memory? > reiser4[emerge(9123)]: release_unix_file > (fs/reiser4/plugin/file/file.c:2294)[vs-44]: > WARNING: out of memory? > reiser4[emerge(9123)]: release_unix_file > (fs/reiser4/plugin/file/file.c:2294)[vs-44]: > WARNING: out of memory? > reiser4[emerge(9123)]: release_unix_file > (fs/reiser4/plugin/file/file.c:2294)[vs-44]: > WARNING: out of memory? > reiser4[emerge(9123)]: release_unix_file > (fs/reiser4/plugin/file/file.c:2294)[vs-44]: > WARNING: out of memory? > reiser4[emerge(9123)]: release_unix_file > (fs/reiser4/plugin/file/file.c:2294)[vs-44]: > WARNING: out of memory? > reiser4[emerge(9123)]: release_unix_file > (fs/reiser4/plugin/file/file.c:2294)[vs-44]: > WARNING: out of memory? > reiser4[emerge(9123)]: release_unix_file > (fs/reiser4/plugin/file/file.c:2294)[vs-44]: > WARNING: out of memory? > reiser4[emerge(9123)]: release_unix_file > (fs/reiser4/plugin/file/file.c:2294)[vs-44]: > WARNING: out of memory? > reiser4[emerge(9123)]: release_unix_file > (fs/reiser4/plugin/file/file.c:2294)[vs-44]: > WARNING: out of memory? > reiser4[emerge(9123)]: release_unix_file > (fs/reiser4/plugin/file/file.c:2294)[vs-44]: > WARNING: out of memory? > reiser4[emerge(9123)]: release_unix_file > (fs/reiser4/plugin/file/file.c:2294)[vs-44]: > WARNING: out of memory? > reiser4[emerge(9123)]: release_unix_file > (fs/reiser4/plugin/file/file.c:2294)[vs-44]: > WARNING: out of memory? > reiser4[emerge(9123)]: release_unix_file > (fs/reiser4/plugin/file/file.c:2294)[vs-44]: > WARNING: out of memory? > > I rebooted, remounted / read only and run fsck --fix, I had to run fsck > --build-fs becouse of fatal corruptions, I got whole lot of errors > referring to /usr/portage dir but fs is now ok. -- Jake Maciejewski <[EMAIL PROTECTED]>
Re: reiser4 bug
On Mon, 2006-04-10 at 22:28 -0700, Matt Eaton wrote: > I was running OpenOffice and tried saving a file. > > I'm using 2.6.16.1 + reiser4-for-2.6.16-1.patch.gz > > (Please help! I'm having to run openoffice on a different filesystem as > this crash has occurred twice saving the same file - after a reboot) Did you fsck when you rebooted? > kernel BUG at fs/reiser4/plugin/file/tail_conversion.c:29! > invalid opcode: [#1] > PREEMPT SMP > Modules linked in: eeprom lm85 hwmon_vid i2c_i801 lp vmnet parport_pc > parport vmmon nfs lockd sunrpc snd_seq_midi snd_emu10k1_synth > snd_emux_synth snd_seq_virmidi snd_seq_midi_emul snd_pcm_oss > snd_mixer_oss snd_seq_oss snd_seq_midi_event snd_seq snd_hda_intel > snd_hda_codec snd_emu10k1 snd_rawmidi snd_ac97_codec snd_ac97_bus > snd_pcm snd_seq_device snd_timer snd_page_alloc snd_util_mem snd_hwdep > snd soundcore binfmt_misc ntfs usblp ide_cd cdrom nvidia e100 mii > uhci_hcd ehci_hcdCPU:0 > EIP:0060:[]Tainted: P VLI > EFLAGS: 00210282 (2.6.16.1 #1) > EIP is at get_exclusive_access+0x1c/0x3d > eax: df21b5dc ebx: 0001 ecx: df21b654 edx: c50e17d4 > esi: acb2e000 edi: c50e1780 ebp: esp: e4481f30 > ds: 007b es: 007b ss: 0068 > Process soffice.bin (pid: 21440, threadinfo=e448 task=dc5bfa90) > Stack: <0>c01c56f4 df21b5dc c013ff95 c253a7ac dda673c0 0001 37c2 > >df21b5dc df21b654 5058c680 e32c4680 acb2e000 e4481fa4 37c2 > c014c900 >e32c4680 acb2e000 37c2 e4481fa4 e32c4680 fff7 bf823d43 > e448 > Call Trace: > [] write_unix_file+0x2a6/0x45c > [] vma_link+0xbe/0xc5 > [] vfs_write+0x87/0x11b > [] sys_write+0x3b/0x63 > [] sysenter_past_esp+0x54/0x75 > Code: 8d 43 14 e8 0b 38 13 00 e9 d1 fc ff ff 90 90 ba 00 e0 ff ff 21 e2 > 8b 12 8b 92 c4 04 00 00 8b 44 24 04 8b 52 50 83 7a 10 00 74 08 <0f> 0b > 1d 00 60 b8 31 c0 ba 01 00 ff ff f0 0f c1 10 85 d2 0f 85 > > > -- Jake Maciejewski <[EMAIL PROTECTED]>
Re: fsck.reiser4 segfaults
On Sat, 2006-04-01 at 08:13 +, Sarath Menon wrote: > Me too, ;) I also found http://www.lxnaydesign.net/, useful if you > need a browser to be around too. > > Here's the dmesg output when i try to mount it. > > reiser4[mount(11756)]: renew_sibling_link > (fs/reiser4/tree_walk.c:441)[nikita-3532]: > WARNING: Sibling nodes on the different levels: 4 != 4 > > reiser4[mount(11756)]: key_warning > (fs/reiser4/plugin/object.c:97)[nikita-717]: > WARNING: Error for inode 42 (-5) > > The kernel version seems to be a bit old at 2.6.10-lxnay3. Should I > try with a newer kernel, with debug args maybe? lxnay may have backported a more recent patch, but there was a plugin set change (see http://www.mail-archive.com/reiserfs-list@namesys.com/ msg18602.html) in 2.6.11-5 such that older kernels would be unable to mount filesystems that had been mounted with newer kernels. > Thanks, > Sarath > > On 4/1/06, Joachim Feise <[EMAIL PROTECTED]> wrote: > > Michael Weissenbacher wrote on 03/31/06 12:21: > > > > > Hi, > > >> reiserfsprogs and libaal are both 1.0.5. I'll give you the dmesg > > >> output tommorow - I need to get a livecd with reiser4 patches - its > > >> more difficult than I initially thought ;) > > > I'm using RIPLinux, which has reiser4 support. > > > http://www.tux.org/pub/people/kent-robotti/looplinux/rip/ > > > > > > Thanks for that info. I was looking for a boot disk with reiser4 for some > > time. > > > > -Joe > > > > > -- > -- > I presume, when you pronounce iptables, you say that you are peeing tables -- Jake Maciejewski <[EMAIL PROTECTED]>
Re: 2.6.16 patch
Thanks, so far it's survived a few hours of stress testing on amd64, compiled with gcc 4.1.0. On Tue, 2006-03-28 at 15:42 +0400, Vladimir V. Saveliev wrote: > Hello > > On Mon, 2006-03-27 at 19:27 +0200, jp wrote: > > Hi, > > > > I would really like to get an answer to my question below ;) > > > sorry for delay: > ftp://ftp.namesys.com/pub/reiser4-for-2.6/2.6.16/reiser4-for-2.6.16-1.patch.gz > -- Jake Maciejewski <[EMAIL PROTECTED]>
Re: reiser4 problems
5.1 with the 2.6.15-1 patch. After a lot of compiling (emerge -eD world in Gentoo), I ended up with a directory that I couldn't delete. fsck.reiser4 --check log: FSCK: Node (21121314), item (10), [10467f6:6c6f63616c6500:10467f7] (stat40): wrong size (3), Should be (2). FSCK: Node (21121314), item (10), [10467f6:6c6f63616c6500:10467f7] (stat40): wrong bytes (182), Should be (100). fsck.reiser4 --fix log: FSCK: Node (19374202), item (0): 1 mergable units were found in the extent40 unit. Merged. FSCK: Node (21121314), item (10), [10467f6:6c6f63616c6500:10467f7] (stat40): wrong size (3), Fixed to (2). FSCK: Node (21121314), item (10), [10467f6:6c6f63616c6500:10467f7] (stat40): wrong bytes (182), Fixed to (100). After fixing, --check came up clean. It's good to know the bug is relatively harmless and has been fixed, but is there any way to take advantage of improvements and bugfixes made in the last two months without running 2.6.14 or the -mm patchset? > the only serious problem > here is at the beginning of the 'CHECKING STORAGE TREE' pass -- there must > not be a key [0:0(NAME):0:0:0]. > > > After second fsck, I have unmounted and mounted it read only to save > > data on ext3 partition and to wait answers and suggestions before using > > reiser4 once more. > > which reiser4progs version do you use? > > it is already difficult to say why this strange key appeared -- you have > already run several build-fs runs -- although it may be related to remount > (I remember we used to have some problems before) or to fsck --build-fs. > > unmount you fs please and run 'fsck --check' on the unmounted fs -- check > that all is right there now. > > which kernel version do you use? > -- Jake Maciejewski <[EMAIL PROTECTED]>
Re: Reiser4 on powerpc; unresolved symbol, panic
As I believe I've recommended before, PearPC on a high-end i386 machine (I don't think JIT support is available for amd64) should be an adequate PowerPC test platform. On Fri, 2006-02-03 at 11:05 -0800, Hans Reiser wrote: > Next week vs will look at changing new_page for page. Thanks for > finding a bug. We don't have an iBook, so we can't really do more than > fix the bugs you identify for us. > > Hans -- Jake Maciejewski <[EMAIL PROTECTED]>
Re: Reiser4 on powerpc; unresolved symbol, panic
I tried the same change with the 2.6.15-1 patch on my beige g3 and got a hard lock attempting to mount a reiser4 filesystem and no messages logged. The previous behavior has been for reiser4 filesystems, even created on a working architecture, to gracefully fail to mount. I don't think Namesys is prioritizing PPC support yet, which is understandable. On Fri, 2006-02-03 at 09:17 -0500, Jonathan Bastien-Filiatrault wrote: > Hi, > Seing that reiser4 was pretty much stable on my i386 workstation, I > decided to give it a try on my iBook 2001 dual-usb. > > While compiling the new kernel for my laptop (2.6.15 + debian, reiser4 > patched, built-in), it gave new_page as an unresolved symbol in > fs/reiser4/plugin/item/tail.c . By looking at the context of the file, I > changed new_page for page. > > With that, I was able to start rsyncing my system back on the laptop > (using a rescue partition, with the same kernel). Unfortunately, about > halfway through, it gave a pretty ugly panic; the dmesg output is > attached. Running 'sync' or 'umount' on the filesystem resulted in that > userspace program to stop responding completely. After a reboot, a fsck on > the reiser4 filesystem resulted in total anhilation (thousands of files in > lost+found, none in the rest of the filesystem). > > Hopefully, I have good backup habits (my workstation is backed up twice a > week in case of reiser4 snafu), no data was lost, so I wont be suing > namesys ;P. > > Thanks for the great filesystem, > Keep up the great work, > Jonathan -- Jake Maciejewski <[EMAIL PROTECTED]>
Re: Small ZFS / Reiser4 / Ext 'benchmark'
I'm curious if disabling ZFS checksumming would make a significant difference. On Thu, 2006-02-02 at 22:59 +0100, Adrian Ulrich wrote: > Hi, > > If anyone is interested: > I ran a small filesystem benchmark on my x86 PC. > > It includes: > > On Linux: > * Reiser4 > * ReiserFS > * Ext3 > > On Solaris (Using 'gnusolaris'[.org] -> Alpha 2) > * UFS > * ZFS > > > NetApp's 'Postmark' was used to perform the tests. > (Postmark simulates something like Mail/NNTP-Server load) > > Results: > http://spam.workaround.ch/dull/postmark.txt > > > (I used the *default* mkfs/mount options for all filesystems. > If you like, i can re-run the test with non-default parameters) > > > -- Adrian > -- Jake Maciejewski <[EMAIL PROTECTED]>
Re: Reiser4 corruption (fsck.reiser4 broken?)
Someone correct me if I'm wrong, but kernels since 2.6.11-5 have the new plugin set which isn't supported by reiser4progs 1.0.4, so fscking with 1.0.4 was probably a big mistake. On Tue, 2006-01-24 at 22:57 +0300, Roman I Khimov wrote: > Well, quite an interesting feeling when you lost 80G of music and 100G of > other great stuff... Refreshing, I should say. > > OK, let me explain in detail what's happening here. I have a 250Gb HDD in > external IEEE1394 aka Firewire enclosure. It's encrypted via dm-crypt (no > partitions, from block #0 to the end) and, you can guess it, I've placed a > Reiser4 partition on it. > > I'm using -mm tree kernels and right now I have two of them for my system - > 2.6.15-rc5-mm3 and 2.6.15-mm4. The first one worked just fine for me, but > with second I've been experiencing some strange "Badness" from kernel block > level, which at that moment I had no time to save/report/analyse. That was > several times when using that external HDD. I have no logs for it, sorry > (I'm a bad user, I know...) > > So, despite of that "Badness" everything worked fine, I was using one or > another kernel depending on my mood. Until today, when I thought "man, are > you sure that everything is OK? Maybe it's time to make fsck on that drive, > you know, there is something you don't want to lose there..." > > So, I've ran fsck.reiser4 on dm-mapped drive (with kernel 2.6.15-rc5-mm3) > and it said that there is 1 inconsistency found. Not that bad for kernel > "Badness", it recommended to run itself with "--build-fs" parameter, I did > so and... Lots of output on the screen, some ~38000 files found and ~36000 > files lost&found. Mounting my drive, what's here? > > [EMAIL PROTECTED]:/media/ext-250/lost+found> ls | wc -l > 34799 > > And, of course, lots of files just disappeared. I see some of them in > "lost+found" directory, but some of them are corrupted - I've tried to play > one with "suspicious" size and mplayer just quit seconds later with lots of > "[mpeg4 @ 0x84b4e88]marker does not match f_code" errors. That one was just > fine week or so ago. > > As I've said, I'm a bad user with no logs for any of that actions (didn't > expected that one inconsistency can be source of such badness). I'm not > asking for help with data restoring (although I would try anything to do > that), it's all my fault, but the question is - how can I help debugging > the situation (if there is something to debug at all), what info may I > provide (I'm very useful without logs, I know...)? > > Seems to me fsck.reiser4 is not that good at restoring file systems, because > in those fragments in "lost+found" I clearly see parts of files that were > just fine yesterday. > > Reiser4progs version 1.0.4. > > [ searching a bit... ] > > Cool, newest version is 1.0.5. My fault... again. So, just tell me that it's > fixed in this version - I'll laugh at myself a little... ;-) > -- Jake Maciejewski <[EMAIL PROTECTED]>
stale dk warning
In addition to the disable write barrier warning reported by Louis-David Mitterrand on January 10th, with 2.6.15-1 I'm getting: <4>reiser4[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. -- Jake Maciejewski <[EMAIL PROTECTED]>
Re: BUG umounting to shut down
On Thu, 2006-01-19 at 18:34 -0700, Vladimir V. Saveliev wrote:
> Hello
>
> On Wed, 2006-01-18 at 20:17 -0600, Jake Maciejewski wrote:
> > I was shutting down my amd64 system with reiser4-for-2.6.14-1.patch.gz
> > on 2.6.14.2 when I got the output below. I haven't had the problem
> > before and probably couldn't reproduce it easily. I can provide more
> > details if requested, but I left out the contents of all the registers
> > because I was transcribing from digital photos.
> >
> > Kernel BUG at fs/reiser4/fsdata.c:149
>
> I believe that
> ftp://ftp.namesys.com/pub/reiser4-for-2.6/2.6.15/reiser4-for-2.6.15-1.patch.gz
> has this problem fixed. Would you please try to upgrade?
> Note that changes are substantial, please, be careful.
Excellent, I'd been hoping we'd see a 2.6.15 patch soon. I keep backups
so I'm not worried about my data unless there's a risk of silent
corruption. You might want to make a note in the README to warn those
who don't check the mailing lists.
> > invalid operand: [1] PREEMPT
> > ...
> > Pid: 2691, comm: umount Tainted: P 2.6.14.2-1 #1
> > ...
> > Call Trace:{done_fs_info+9}
> > {reiser4_put_super+221}
> > {generic_shutdown_super+162}
> > {kill_block_super+45}
> > {deactivate_super+111}
> > {sys_umount+664}
> > {do_munmap+669} {error_exit+0}
> > {system_call+126}
> >
> > Code: 0f 0b 68 d7 b9 34 80 c2 95 00 66 66 66 90 48 8b bb d0 03 00
> > RIP {done_super_d_info+18} RSP
> > Badness in do_exit at kernel/exit.c:799
> >
> > Call Trace:{do_exit+76}
> > {do_unblank_screen+21}
> > {die+81} {do_invalid_op+145}
> > {done_super_d_info+18}
> > {thread_return+0}
> > {error_exit+0}
> > {proc_destroy_inode+0}
> > {done_super_d_info+18}
> > {done_fs_info+9}
> > {reiser4_put_super+221}
> > {generic_shutdown_super+162}
> > {kill_block_super+45}
> > {deactivate_super+111}
> > {sys_umount+664} {do_munmap+669}
> > {error_exit+0} {system_call+126}
> >
> > <4>reiser4[umount(26912)]: release_unix_file
> > (fs/reiser4/plugin/file/file.c:2733)[vs-44]:
> > WARNING: out of memory?
> > <4>reiser4[umount(26912)]: release_unix_file
> > (fs/reiser4/plugin/file/file.c:2733)[vs-44]:
> > WARNING: out of memory?
> > <4>reiser4[umount(26912)]: release_unix_file
> > (fs/reiser4/plugin/file/file.c:2733)[vs-44]:
> > WARNING: out of memory?
> > <4>reiser4[umount(26912)]: release_unix_file
> > (fs/reiser4/plugin/file/file.c:2733)[vs-44]:
> > WARNING: out of memory?
> > /etc/init.d/halt.sh: line 86: 26912 Segmentation fault umount -f -r
> > "${x}" >&/dev/null
> >
> >
>
--
Jake Maciejewski <[EMAIL PROTECTED]>
BUG umounting to shut down
I was shutting down my amd64 system with reiser4-for-2.6.14-1.patch.gz
on 2.6.14.2 when I got the output below. I haven't had the problem
before and probably couldn't reproduce it easily. I can provide more
details if requested, but I left out the contents of all the registers
because I was transcribing from digital photos.
Kernel BUG at fs/reiser4/fsdata.c:149
invalid operand: [1] PREEMPT
...
Pid: 2691, comm: umount Tainted: P 2.6.14.2-1 #1
...
Call Trace:{done_fs_info+9}
{reiser4_put_super+221}
{generic_shutdown_super+162}
{kill_block_super+45}
{deactivate_super+111}
{sys_umount+664}
{do_munmap+669} {error_exit+0}
{system_call+126}
Code: 0f 0b 68 d7 b9 34 80 c2 95 00 66 66 66 90 48 8b bb d0 03 00
RIP {done_super_d_info+18} RSP
Badness in do_exit at kernel/exit.c:799
Call Trace:{do_exit+76}
{do_unblank_screen+21}
{die+81} {do_invalid_op+145}
{done_super_d_info+18}
{thread_return+0}
{error_exit+0}
{proc_destroy_inode+0}
{done_super_d_info+18}
{done_fs_info+9}
{reiser4_put_super+221}
{generic_shutdown_super+162}
{kill_block_super+45}
{deactivate_super+111}
{sys_umount+664} {do_munmap+669}
{error_exit+0} {system_call+126}
<4>reiser4[umount(26912)]: release_unix_file
(fs/reiser4/plugin/file/file.c:2733)[vs-44]:
WARNING: out of memory?
<4>reiser4[umount(26912)]: release_unix_file
(fs/reiser4/plugin/file/file.c:2733)[vs-44]:
WARNING: out of memory?
<4>reiser4[umount(26912)]: release_unix_file
(fs/reiser4/plugin/file/file.c:2733)[vs-44]:
WARNING: out of memory?
<4>reiser4[umount(26912)]: release_unix_file
(fs/reiser4/plugin/file/file.c:2733)[vs-44]:
WARNING: out of memory?
/etc/init.d/halt.sh: line 86: 26912 Segmentation fault umount -f -r "${x}"
>&/dev/null
--
Jake Maciejewski <[EMAIL PROTECTED]>
Re: reiser4: writing plugins
On Thu, 2005-12-22 at 19:24 -0500, michael chang wrote: > On 12/19/05, Ryan Nordman <[EMAIL PROTECTED]> wrote: > > I don't know how useful it'd be, I think it'd be great for getting you > > familiar with the code base. It'd add a bit of overhead that's not really > > that necessary, don't you think? Unless somebody really needs to know disk > > usage *really* often. What's the case for doing this in kernel space > > instead of just using the du utility? > > Well, my first instinctive thought is that it might help thwart or > postpone any potential persons thinking of switching to > OpenSolaris+ZFS because of the so-called 'pooled storage' thinking. > (ZFS has the ability to have multiple filesystems, even nested within > each other, all sharing space from the same partition(s), and uses > 'df' as opposed to du to find disk space, apparently df is 'cheaper' > in terms of time used. Apparently, with ZFS, you can do a 'df' and > suddenly know how much space is used and free in any one folder > provided it's a seperate filesystem of it's own. A bit of an ... > unusual abstraction to do things, but...) Being able to use "df" or "zfs list" instead of "du" is a side effect. The real reason for the "unusual abstraction" is to have finer grained control over quotas, reservations, snapshots, checksums, compression, NFS sharing, etc. > If done *correctly* in the kernel, I imagine it should be faster - du > does what would be the equivilant of listing all the files in the > directory and summing all the file sizes it gets (du -s) -- and it is > affected by the user's permissions (if I have a directory in the > directory i'm du-ing that I can't read, du will fail to account for > the files within that directory). > > Last thing would be (hopefully) an ability to turn this thing on and > off, and maybe to display the size of a folder's contents rather than > the size of the directory's metadata in various utilities (if I 'ls > -d' a directory, I usually get something like 2048B or 4096B depending > on the number of files in there, although IIRC some big folders 'grow' > to 16 KB, containing who knows what inside). > > > > On December 16, 2005 11:58 am, dannym wrote: > > > > Hi, > > > > > > > > So I want to start writing a small plugin to get a feel for the > > > > architecture... > > > > As for what I thought would be a nice intro thing for me to write is: > > > > > > > > Adds a pseudo file "tree-contents-size" for directories. > > > > Pseudo file contains the "du" starting from this directory. > > > > > > > > What it should do is cache some kind of "du"-like value per directory. > > > > When you change a file size (or delete a file, add a file, ...) in the > > > > dir or one of it's subdirs, it shall set a dirty flag on the value. > > > > When the pseudo file is accessed, it shall calculate it anew, also > > > > updating the subdirs' pseudo files if so needed, and store it actually > > > > on disk... > > > > (could also be updated periodically without anyone requesting it, but > > > > that's just a detail) > > -- > ~Mike > - Just the crazy copy cat. -- Jake Maciejewski <[EMAIL PROTECTED]>
Re: Reiser4 Install Guide for Ubuntu 5.10
On Mon, 2005-11-21 at 16:52 -0800, Ryan Nordman wrote: > Hi Hans, > > Allow me to introduce myself, I'm one of Peter (aka pvh)'s colleagues > here at the University of Victoria. A while back we mentioned we'd > write a practical install guide for Reiser4 with Ubuntu 5.10. Well, > here it is. Let us know if you want us to make any changes to the > format or add/remove any steps. > > All version references in this document are up to date for Ubuntu 5.10 > (Breezy Badger). > > Prerequisites: Add the universe repository to your sources > > 1. Install all the software needed to compile the kernel > # apt-get build-dep linux-source-2.6.12 > # apt-get install linux-source-2.6.12 checkinstall libncurses-dev > > 2. Use the following commands to download the latest Reiser4 kernel > patch, the Reiser4 utility programs, and required libraries. > # wget > ftp://ftp.namesys.com/pub/reiser4-for-2.6/2.6.12/reiser4-for-2.6.12-3.patch.gz > # wget > ftp://ftp.namesys.com/pub/reiser4progs/reiser4progs-1.0.5.tar.gz > # wget ftp://ftp.namesys.com/pub/reiser4progs/libaal-1.0.5.tar.gz > > 3. Install libaal > # tar zxf libaal-1.0.5.tar.gz > # cd libaal-1.0.5 > # ./configure; make > # checkinstall > At the prompt: "Should I create a default set of package docs? [y]:" > type "y" and press enter. > You will then be prompted to input a description of the package. > Enter something like "locally built libaal" then press enter three > times. > # cd .. > > 4. Install reiser4progs > # tar zxf reiser4progs-1.0.5.tar.gz > # cd reiser4progs-1.0.5 > # ./configure; make > # checkinstall > At the prompt: "Should I create a default set of package docs? [y]:" > type "y" and press enter. > At the prompt: "Do you want me to list them? [n]:" type "n" and press > enter. > At the prompt: "Should I exclude them from the package? (Saying yes is > a good idea) [y]:" type "y" and press enter. > You will then be prompted to input a description of the package. Type > something like "locally built libaal" then press enter three times. > > 5. Unzip and add the reiser4 code to the linux source > # cd /usr/src > # tar xvf linux-source-2.6.12.tar.bz2 > # cd linux-source-2.6.12/ > # gunzip -c ~/reiser4-for-2.6.12-3.patch.gz | patch -p1 > > 6. Compile the kernel > # make menuconfig > Select "File systems --->" from the menu and press enter. > Select "Reiser4 (EXPERIMENTAL) (NEW)" and type "M". > Press the esc key twice. > Select "yes" at the prompt. Must the rest of the kernel options be configured here as well, or does apt-get install the sources with a .config? Most users who know how to configure a kernel will probably know the other steps. If the kernel has to be configured, is the default Ubuntu .config easily available? > # make > ... much time passes ... > > 7. Build a Debian install package for the kernel > # make-kpkg --rootcmd fakeroot --append-to-version --initrd -- > > 8. Reboot with the new kernel, create a Reiser partition and mount it > and you're good to go! > -- Jake Maciejewski <[EMAIL PROTECTED]>
Re: / is no longer Reiser4 :(
On Mon, 2005-11-21 at 22:15 +0300, Alexander Zarochentsev wrote: > Hi > > On Monday 21 November 2005 20:57, Hans Reiser wrote: > > zam, please look into this. > > > > > Hans > > > > John Gilmore wrote: > > >Following Han's comment about the deliterious effects of 6% fragmentation, > > > I attempted a manual defrag of my hard disk. > > > > > >While restoring the .tar file, I had nothing better to do than watch it. > > > And a good thing too! It got a recurring oops. about every other minute > > > or so, it would stop with a long kernel message than mostly scrolled off > > > of the screen... I thought those where supposed to show up in a log files > > > somewhere if possible, but I can't find it. And it should have been > > > possible, as the computer continued to run just fine. > > > > > >These oopses caused some sort of data corruption - root wouldn't boot > > one bug responsible for fs corruption was fixed recently. > the fix is in 2.6.14-mm2 already. Can we get a fix for vanilla? I haven't had problems yet, but I don't want to run mm unless absolutely necessary, and lately I've lost confidence in the "apply mm patches to vanilla and hope it works" approach. > > > properly afterwards. So I reformated as ext3 and untarred my root again. > > > That worked fine, so I know it wasn't corruption of the tar file. > > > > > >I took a photograph, and I'll try to type in some of it. Just looking at > > > the names of the procudures, it looks like memory pressure made reiser4 > > > flush, and then some of the lower level functions tried to allocate > > > memory and failed. But since I don't have the top of the oops message, I > > > can't tell. > > > > > >Wait - I could've stopped the scrolling with ^S, scrolled back with > > > ^pageup, and photoed the whole thing! Aaaargghh > > > > > >Well, I'm not redoing it right now, I need to be getting to bed. > > > > > >I may try it again later - but then maybe I'll update to 2.6.14-mm2 with > > > patch from namesys first... > > > > > >Here's the (tail end of the) oops message, sans addresses and offsets > > > because I'm feeling lazy and I'm in a hurry: > > > > > >mempool_alloc+0x3a/0xe0 > > >__split_bio+0x128/0x190 > > >in_drive_list > > >dm_request > > >generic_make_request > > >submit_bio > > >do_IRQ > > >reiser4_clear_page_dirty > > >write_jnodes_to_disk_extent > > >write_jnode_list > > >write_fq > > >flush_current_atom > > >flush_some_atom > > >writeout > > >reiser4_sync_inodes > > >writeback_inodes > > >background_writeout > > >pdflush > > >__pdflush > > >pdflush > > >background_writeout > > >kthread > > >kthread > > >kernel_thread_helper > -- Jake Maciejewski <[EMAIL PROTECTED]>
Re: A WISH: Reiser4 patch for 2.6.14
It looks good so far on amd64, but I haven't had the chance to stress
test it yet.
I remember Hans mentioning wanting to eliminate warnings, so I attached
a trivial patch for an ISO C90 mixed code/declarations warning.
On Fri, 2005-11-11 at 19:33 +0300, Vladimir V. Saveliev wrote:
> Hello
>
> Yusuf Iskenderoglu wrote:
> > Okay, thanks for the information. I will continue waiting.
> >
>
> Well, here is the first attempt to relelase reiser4 for 2.6.14. Please try to
> use it.
> ftp://ftp.namesys.com/pub/reiser4-for-2.6/2.6.14/reiser4-for-2.6.14-1.patch.gz
>
>
> Consider it as an experimental thing. Note, it will probably not compile as a
> module. Adding a line to mm/page-writeback.c the following line
>
> EXPORT_SYMBOL(clear_page_dirty_for_io);
>
> after clear_page_dirty_for_io()'s definition should fix that, though.
>
>
>
> > On Mon, 2005-11-07 at 19:20 +0300, Vladimir V. Saveliev wrote:
> >>Hello
> >>
> >>Yusuf Iskenderoglu wrote:
> >>>Hello,
> >>>
> >>>I am not having a support issue, just a wish.
> >>>It always takes many weeks until you put a patch for the reiser4
> >>>filesystem for the most actual Linux version into your ftp server.
> >>>In this case, 2.6.14 is already released for one week now, and there is
> >>>still no patch available.
> >>>
> >>>I am not interested in patching the kernel with stuff from other/older
> >>>patches.
> >>>I just wish you be up-to-date
> >>>
> >>>Creating a patch for the actual kernel version simply cannot take you
> >>>more than 1 Minute.
> >>>
> >>Sorry for delay with that. Code got big changes recently, we would like to
> >>test
> >>it a bit.
> >
> >
> >
>
--
Jake Maciejewski <[EMAIL PROTECTED]>
--- cryptcompress.c.orig 2005-11-11 12:38:34.447766000 -0600
+++ cryptcompress.c 2005-11-11 12:39:22.066742000 -0600
@@ -505,6 +505,8 @@
int open_cryptcompress(struct inode * inode, struct file * file)
{
+ struct inode * parent;
+
assert("edward-1394", inode != NULL);
assert("edward-1395", file != NULL);
assert("edward-1396", file != NULL);
@@ -514,7 +516,6 @@
assert("edward-698",
inode_file_plugin(inode) ==
file_plugin_by_id(CRC_FILE_PLUGIN_ID));
- struct inode * parent;
if (!need_cipher(inode))
/* the file is not to be ciphered */
return 0;
Re: zlib support...
On Sun, 2005-10-30 at 16:21 -0600, David Masover wrote: > Compiling a 2.6.12.5 kernel on my Powerbook, I discovered something > odd. Reiser4 (vanilla patch) was insisting on being a module. > > Alright, why does it still depend on CONFIG_ZLIB_INFLATE and > CONFIG_ZLIB_DEFLATE, even when the cryptocompress plugin isn't being > used at all, and is in fact nonfunctional? > > Anyway, I can live with a little RAM bloat, but for some reason, I > couldn't find the options to enable any zlib in the kernel. I could > enable INFLATE support by forcing something I know uses it to be > compiled in -- compressed isofs support. But I couldn't find > something sane to force DEFLATE on. DEFLATE defaults to being a > module, and INFLATE seems to follow whatever I set isofs support to be > -- if I want INFLATE compiled in, to compile Reiser4 in, I have to > compile isofs in. > > Still workable, but very, very stupid, especially considering zlib is > never actually used, only compiled against and depended on. > > Ok, first actual bug: > I could try to compile Reiser4 in at this point, but the final link > fails, because it does need deflate support, even though it doesn't > depend on CONFIG_ZLIB_DEFLATE. > Solution: Either remove cryptocompress until it works, or depend on > CONFIG_ZLIB_DEFLATE. > > Now, second actual bug, not actually your fault: > Neither DEFLATE nor INFLATE can be configured manually, yet you depend > on one (or both) of them, without actually setting them. Thus, if > CONFIG_ZLIB_DEFLATE is compiled as a module, Reiser4 must be a module, > and there's no way to change that from inside menuconfig. Editing > the .config file manually doesn't work. > Solution: Make it possible to select INFLATE and DEFLATE support > manually, just like CRC32 and other library functions, or have Reiser4 > enable them when it needs them, instead of insisting on being a > module. > > The real surprise is, this problem only started happening on my PPC > system. I'm not sure if it's a config script glitch, an > architecture-specific problem, or something else entirely. But then, > my PPC is the only 2.6.12 system I currently run that tries to compile > in Reiser4 support -- the desktop loads it from a ramdisk, because it > needs the ramdisk anyway, and the other amd64 box is running 2.6.13. > Maybe configure is supposed to work this way, but the dependencies are > wrong. Have you actually gotten reiser4 to work on PPC? I can't even mount reiser4 filesystems on PCC. I've tried reporting it twice, but as far as I know no effort has been made to fix the problem. > I realize this is all probably old news, but I'm sending it anyway, > because maybe it's not. I'm sending it from a gmail address because I > don't have networking on said Powerbook yet. -- Jake Maciejewski <[EMAIL PROTECTED]>
Re: reiserfs using too much space on my HD
p will preserve permissions, but I'd add l to avoid traversing the virtual proc and sys filesystems. You'll also need a minimal set of device nodes. I find it easiest to tar up my current /dev (p is all you need here too) rather than making only the devices needed before udev starts. On Fri, 2005-10-28 at 10:19 -0700, Bedros Hanounik wrote: > Vlad, > > fsck.reiserfs version is 3.6.19; when I run it, it reports no > corruption errors found at the end; or something like that. > > I'll tar the whole partition to an external drive, then format it and > untar it again. > > Anyone knows if "tar cvjpf file /" is suffecient to keep all > permisions etc. (including for system directories such as /proc /dev) > and restoring exactly as it was before format? > > Thanks, > > -B > > > > On 10/27/05, Bedros Hanounik <[EMAIL PROTECTED]> wrote: > > "du -shx" reports 9.5GB > > I'm running latest from gentoo, so I assume it's 3.6.19. > > I ran fsck.reiserfs from gentoo liveCD 2005.1 and at the end I > got zero errors. > > The problem could be fixed, I could tar the whole root > directory to an external drive, format the partition and then > tar it back. but I'm not sure what's going on? > > I'll post all logs on this list tomorrow. > > -Bedros > > > > On 10/27/05, Vladimir V. Saveliev <[EMAIL PROTECTED]> wrote: > Hello > > Bedros Hanounik wrote: > > Hi, > > > > I've been using reiserfs for several years now and > it's been choice > > number one for me; I'll probably switch to reiser4 > once it's in the main > > kernel. > > > > on my home file server machine, one hard drive > (120GB) reports 80 GB > > used, but I have no idea how and where it's used. > > > > df -h reports 80GB used > > > > what does du -s / report? > > > but when I run kdirstat, I get about 10GB used for > directory /. > > > > I ran fsck.reiserfs from liveCD and it reported no > errors. > > > > is it reiserfsck 3.6.19? > Please send output of reiserfsck 3.6.19. > > > is there any better way to tell what's eating up my > hard drive? > > > > Regards, > > > > -Bedros > > > > > > > > -- Jake Maciejewski <[EMAIL PROTECTED]>
Re: latest 2.6.13 reiser4 patch
On Sat, 2005-10-01 at 20:40 +0200, Artur Makówka wrote: > >> Will it work also with 2.6.13.2 kernel ? or is it only for 2.6.13 ( or > >> 2.6.13.1 ) > >> > >> i couldnt find any information about this on page, and i want to be > >> sure... > > > >I used it fine with 2.6.13.2... but my wireless card isn't supported > >there. (it's been included in 2.6.14x, so it was never patches against > >2.6.13.. I tried backporting my wireless driver but there were a lot > >of changes in both directions). The patch also applies cleanly > >against 2.6.14-rc1/2 but 2.6.14-rc1/2 panic on initrd uncompress for > >me, and I can't troubleshoot it because the backtrace scrolls my > >screen and I can't do a serial console on my laptop. :( > > > >In any case I tested reiser4 out some on 13.2, and the only bug I hit > >was a panic on unmount. > > but is there some official statment about using 2.6.x reiser4 patches with > 2.6.x.x kernels? i mean, does patch called reiser 4 2.6.13 patch is also > intended to work with 2.6.13.2 for example or only with 2.6.13 ? 2.6.x.y patches are obvious security or bug fixes that aren't supposed to introduce new bugs. I'm in no position to make an official statement, but until the development process changes again, 2.6.x reiser4 patches should always work on 2.6.x.y versions. -- Jake Maciejewski <[EMAIL PROTECTED]>
Re: reiser4 for 2.6.13 is available on our website
It compiles and boots, but I can't stress test because two of my NICs
don't work in 2.6.13.
I don't know which patch(es) fixed my NIC problem, but I recall
2.6.14-rc1 working. When I tried the 2.6.13-1 patch against rc1, I got a
failed hunk in lib/radix-tree.c which I attempted to fix manually. It
compiled, but I got a panic starting init.
On Fri, 2005-09-30 at 12:31 +0400, Alexander Zarochentsev wrote:
> On Friday 30 September 2005 02:09, Jake Maciejewski wrote:
> > I get the same with 2.6.13.2 and gcc 3.4.4 on amd64
> >
> can you try this patch?
> ---
> --- a/fs/reiser4/spin_macros.h
> +++ b/fs/reiser4/spin_macros.h
> @@ -82,8 +82,6 @@ typedef struct reiser4_rw_data {
> static inline void spin_ ## NAME ## _init(TYPE *x)
> \
> {
> \
> __ODCA("nikita-2987", x != NULL);
> \
> - cassert(sizeof(x->FIELD) != 0);
> \
> - memset(& x->FIELD, 0, sizeof x->FIELD);
> \
> spin_lock_init(& x->FIELD.lock);
> \
> }
> \
>
> \
> @@ -236,7 +234,6 @@ typedef struct { int foo; } NAME ## _spi
> static inline void rw_ ## NAME ## _init(TYPE *x)
> \
> {
> \
> __ODCA("nikita-2988", x != NULL);
> \
> - memset(& x->FIELD, 0, sizeof x->FIELD);
> \
> rwlock_init(& x->FIELD.lock);
> \
> }
> \
>
> \
> ---
> > On Thu, 2005-09-29 at 20:24 +0200, Łukasz Mierzwa wrote:
> > > Dnia Thu, 29 Sep 2005 19:25:54 +0200, Hans Reiser <[EMAIL PROTECTED]>
> > >
> > > napisał:
> > > > Reiser4 performance dropped in the -mm series due to the write
> > > > throttling patch and also dropped due to a fixed bug (removing type
> > > > safe lists added a bug). We don't yet know if we got quite all the
> > > > performance back, we are still testing. Conservative users should wait
> > > > a week or two to see if bug reports with reiser4 remain, or if indeed
> > > > we did get all the bugs out of the recent cleanup patch.
> > > >
> > > > Hans
> > >
> > >CC fs/proc/kmsg.o
> > >CC fs/proc/proc_tty.o
> > >CC fs/proc/proc_misc.o
> > >CC fs/proc/kcore.o
> > >LD fs/proc/proc.o
> > >LD fs/proc/built-in.o
> > >CC fs/ramfs/inode.o
> > >LD fs/ramfs/ramfs.o
> > >LD fs/ramfs/built-in.o
> > >CC fs/reiser4/debug.o
> > > In file included from fs/reiser4/lock.h:15,
> > > from fs/reiser4/context.h:14,
> > > from fs/reiser4/debug.c:25:
> > > fs/reiser4/txnmgr.h: In function 'spin_atom_init':
> > > fs/reiser4/txnmgr.h:512: error: duplicate case value
> > > fs/reiser4/txnmgr.h:512: error: previously used here
> > > fs/reiser4/txnmgr.h: In function 'spin_txnh_init':
> > > fs/reiser4/txnmgr.h:513: error: duplicate case value
> > > fs/reiser4/txnmgr.h:513: error: previously used here
> > > fs/reiser4/txnmgr.h: In function 'spin_txnmgr_init':
> > > fs/reiser4/txnmgr.h:514: error: duplicate case value
> > > fs/reiser4/txnmgr.h:514: error: previously used here
> > > In file included from fs/reiser4/context.h:14,
> > > from fs/reiser4/debug.c:25:
> > > fs/reiser4/lock.h: In function 'spin_stack_init':
> > > fs/reiser4/lock.h:198: error: duplicate case value
> > > fs/reiser4/lock.h:198: error: previously used here
> > > In file included from fs/reiser4/znode.h:16,
> > > from fs/reiser4/tree.h:15,
> > > from fs/reiser4/super.h:9,
> > > from fs/reiser4/debug.c:26:
> > > fs/reiser4/jnode.h: In function 'spin_jnode_init':
> > > fs/r
Re: reiser4 for 2.6.13 is available on our website
I get the same with 2.6.13.2 and gcc 3.4.4 on amd64 On Thu, 2005-09-29 at 20:24 +0200, Łukasz Mierzwa wrote: > Dnia Thu, 29 Sep 2005 19:25:54 +0200, Hans Reiser <[EMAIL PROTECTED]> > napisał: > > > Reiser4 performance dropped in the -mm series due to the write > > throttling patch and also dropped due to a fixed bug (removing type safe > > lists added a bug). We don't yet know if we got quite all the > > performance back, we are still testing. Conservative users should wait > > a week or two to see if bug reports with reiser4 remain, or if indeed we > > did get all the bugs out of the recent cleanup patch. > > > > Hans > >CC fs/proc/kmsg.o >CC fs/proc/proc_tty.o >CC fs/proc/proc_misc.o >CC fs/proc/kcore.o >LD fs/proc/proc.o >LD fs/proc/built-in.o >CC fs/ramfs/inode.o >LD fs/ramfs/ramfs.o >LD fs/ramfs/built-in.o >CC fs/reiser4/debug.o > In file included from fs/reiser4/lock.h:15, > from fs/reiser4/context.h:14, > from fs/reiser4/debug.c:25: > fs/reiser4/txnmgr.h: In function 'spin_atom_init': > fs/reiser4/txnmgr.h:512: error: duplicate case value > fs/reiser4/txnmgr.h:512: error: previously used here > fs/reiser4/txnmgr.h: In function 'spin_txnh_init': > fs/reiser4/txnmgr.h:513: error: duplicate case value > fs/reiser4/txnmgr.h:513: error: previously used here > fs/reiser4/txnmgr.h: In function 'spin_txnmgr_init': > fs/reiser4/txnmgr.h:514: error: duplicate case value > fs/reiser4/txnmgr.h:514: error: previously used here > In file included from fs/reiser4/context.h:14, > from fs/reiser4/debug.c:25: > fs/reiser4/lock.h: In function 'spin_stack_init': > fs/reiser4/lock.h:198: error: duplicate case value > fs/reiser4/lock.h:198: error: previously used here > In file included from fs/reiser4/znode.h:16, > from fs/reiser4/tree.h:15, > from fs/reiser4/super.h:9, > from fs/reiser4/debug.c:26: > fs/reiser4/jnode.h: In function 'spin_jnode_init': > fs/reiser4/jnode.h:344: error: duplicate case value > fs/reiser4/jnode.h:344: error: previously used here > fs/reiser4/jnode.h: In function 'spin_jload_init': > fs/reiser4/jnode.h:348: error: duplicate case value > fs/reiser4/jnode.h:348: error: previously used here > In file included from fs/reiser4/super.h:9, > from fs/reiser4/debug.c:26: > fs/reiser4/tree.h: In function 'spin_epoch_init': > fs/reiser4/tree.h:169: error: duplicate case value > fs/reiser4/tree.h:169: error: previously used here > In file included from fs/reiser4/debug.c:26: > fs/reiser4/super.h: In function 'spin_super_init': > fs/reiser4/super.h:379: error: duplicate case value > fs/reiser4/super.h:379: error: previously used here > make[2]: *** [fs/reiser4/debug.o] Błąd 1 > make[1]: *** [fs/reiser4] Błąd 2 > make: *** [fs] Błąd 2 > > amd64 gentoo box running gcc 4.0.1, 2.6.13 + reiser4-for-2.6.13-1.patch.gz -- Jake Maciejewski <[EMAIL PROTECTED]>
Re: Reiser4 on CentOS 4.1
reiser4 is a completely different filesystem. reiserfsprogs will not work. Use reiser4progs from ftp://ftp.namesys.com/pub/reiser4progs/. You'll need to install libaal first. You shouldn't be using insmod. Use modprobe instead. A clean rebuild of your kernel might fix the symbol error. On Tue, 2005-09-20 at 20:30 -0700, Steve Jacobson wrote: > All, > > I've compiled a new version of the 2.6.9-11.EL kernel for reiser 4 > support. I applied the reiser4 patch, and rebuilt the kernel with it as > a module. I've installed the resultant kernel, and everything seems > fine with it, in general. I downloaded and compiled the reiser tools - > reiserfsprogs-3.6.19 as I couldn't find a reiser4 specific set. I can > create a reiser file system running mkreiserfs with no problem. When I > go to mount it, with 'mount -t reiser4 /dev/sda4 /data' I get 'mount: fs > type reiser4 not supported by kernel'. Same with type reiserfs. lsmod > doesn't show it installed, so I try to insmod the module: 'insmod > reiser4.ko' I get : > > insmod: error inserting 'reiser4.ko': -1 Unknown symbol in module > > > I'm running (and building on) CentOS 4.1, new install with not much on it. > > any thoughts or direction? > > Thanks! > > -steve j > -- Jake Maciejewski <[EMAIL PROTECTED]>
Re: Namesys web page, possible update?
Also, if there's a default for Gentoo, it's ext3. The installation is still completely manual, but the instructions use "mke2fs -j" in the example. On Mon, 2005-09-19 at 00:49 -0500, Dan Oglesby wrote: > The following line of text appears on the main page at > http://www.namesys.com: > > "V3 of reiserfs is used as the default filesystem for SuSE, Lindows, > FTOSX, Libranet, Gentoo, Xandros and Yoper." > > I believe Slackware has defaulted to V3 for some time now. EXT3 and 2 > are still options as well, but the default selection for filesystem type > is ReiserFS when you go through the setup process. > > Just hoping to give you guys another (very mature) distro to add to the > list. > > --Dan > > -- Jake Maciejewski <[EMAIL PROTECTED]>
Re: Reiser4 & Files/Directories question
On Thu, 2005-09-08 at 13:53 -0500, David Masover wrote: > Ross Jekel wrote: > > Newbie question as I'm evaluating Reiser4 as a storage solution for a > > project I'm working on. > > > > It appears Reiser4 has the ability to have a file name be both the name > > for the file data and a directory. Can I take advantage of this at the > > application level? > > I think there's a mount option to turn this behavior back on, but it's > not on at the moment due to HUGE flamefests on the kernel lists. We > don't know if it's coming back anytime soon, or if it'll resemble what > you're thinking when it does. > > For now, I think there might still be a '-o metas' option, or something > similar. I don't know about mount options, but I've enabled metas by changing "#define ENABLE_REISER4_PSEUDO (0)" to "#define ENABLE_REISER4_PSEUDO (1)" in fs/reiser4/reiser4.h > > For instance, can I use python to access the file data directly, and > > access the directory information as well to open any attribute files I > > might want to put in there? Or is that functionality only available > > through non-posix calls from file system plugins and such. > > It will eventually be available through a non-posix call, and maybe > (hopefully, you paying attention, Namesys?) in some limited way from the > xattr calls. > > > I was interested in the design of the livingxml.net solution from the > > testimonials page, but that site is no longer available. Is there a > > project or design document somewhere that summarizes the best way of > > using reiser4 as a database of content with additional metadata for each > > document? > > AFAIK, livingxml was based on reiserfs3, and it had nothing to do with > non-standard extensions to the FS, but rather with the fact that v3 (and > v4) is fast with small text files, making it a good choice for web, > email, XML, or anything else small and text-y. Even more so after we > get the compression plugin. > > > Forgive me if this is answered somewhere. I've searched some mailing > > list archives site and couldn't find the exact answer. > > Maybe not, but if you search the archive for "Silent Semantic Changes in > Reiser4" (or something very similar), you'll find a very long thread on > why Reiser4 doesn't (currently) support files as directories. > -- Jake Maciejewski <[EMAIL PROTECTED]>
Re: WinFS beta out
Yeah, if SQL on NTFS counts as a revolutionary filesystem. I wonder what Namesys could do with MS's resources. On Tue, 2005-08-30 at 00:36 -0400, Gregory Maxwell wrote: > http://it.slashdot.org/it/05/08/29/2241243.shtml?tid=109&tid=218 > > Looks like MSFT will be beating Linux to the nextgen FS punch after all. ;) -- Jake Maciejewski <[EMAIL PROTECTED]>
reiser4 still not working on PPC
Trying to mount reiser4 on PPC still gives me "mount: No such file or
directory". I'm using 2.6.12.2 with the 3rd Namesys patch for 2.6.12,
and my progs are version 1.0.4-1.
I ran mount with strace and got a whole bunch of stuff, but here's the
interesting part, where it deviates from a successful ext2 mount
following the same procedure (note that I used losetup to reduce the
work done by mount):
mount("/dev/loop0", "/home/jake/debug/mnt_reiser4/", "reiser4",
MS_POSIXACL|MS_ACTIVE|MS_NOUSER|0xec, 0) = 268581048
mount("/dev/loop0", "/home/jake/debug/mnt_reiser4/", "reiser4",
MS_POSIXACL|MS_ACTIVE|MS_NOUSER|0xec, 0) = 268581048
mount("/dev/loop0", "/home/jake/debug/mnt_reiser4/", "reiser4",
MS_POSIXACL|MS_ACTIVE|MS_NOUSER|0xec, 0) = -1 ENOENT (No such file or
directory)
rt_sigprocmask(SIG_UNBLOCK, ~[TRAP SEGV RTMIN RT_1], NULL, 8) = 0
lstat64("/home/jake/debug/mnt_reiser4/", {st_mode=S_IFDIR|0755, st_size=1024,
...}) = 0
stat64("/home/jake/debug/mnt_reiser4/", {st_mode=S_IFDIR|0755, st_size=1024,
...}) = 0
stat64("/dev/loop0", {st_mode=S_IFBLK|0660, st_rdev=makedev(7, 0), ...}) = 0
dup(2) = 3
fcntl64(3, F_GETFL) = 0x2 (flags O_RDWR)
fstat64(3, {st_mode=S_IFCHR|0620, st_rdev=makedev(136, 0), ...}) = 0
mmap(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) =
0x30018000
_llseek(3, 0, 0x7fb192a8, SEEK_CUR) = -1 ESPIPE (Illegal seek)
write(3, "mount: No such file or directory"..., 33) = 33
close(3)= 0
munmap(0x30018000, 4096)= 0
exit_group(32) = ?
I don't know much about Linux syscalls, but I thought mount() was
supposed to return 0 or -1. So mount gets a bogus return value, tries
again, gets the same, then tries a third time and gets ENOENT? Then it
looks like it's trying to figure out whether the device file or mount
point doesn't exist, but both exist so it gives me a generic "No such
file or directory" and exits. I get some interesting kernel messages,
however:
ps_hash_table: 32 buckets
ef_hash_table: 8192 buckets
z_hash_table: 8192 buckets
z_hash_table: 8192 buckets
j_hash_table: 16384 buckets
loading reiser4 bitmap..done (2 jiffies)
d_cursor_hash_table: 256 buckets
reiser4[mount(8564)]: key_warning (fs/reiser4/plugin/object.c:96)[nikita-717]:
code: -2 at fs/reiser4/tree_walk.c:168
WARNING: Error for inode 720575940379279360 (-2)
for key: (9102000:0:0:2:a00:0)[*]
Nothing seems to change if I re-run mkfs (same inode, key), or even
create the FS from a known-good AMD64 machine. Unfortunately, if I
enable debugging, attempting to insert the module cause modprobe to
consume 100% CPU and go zombie. So far I've avoided building it in
because my beige g3 is a PITA to boot.
--
Jake Maciejewski <[EMAIL PROTECTED]>
Re: reiser4 plugins
On Tue, 2005-06-28 at 23:47 +0300, Markus Törnqvist wrote: > On Tue, Jun 28, 2005 at 09:44:59AM -0400, Horst von Brand wrote: > > > >No. But just relying on perfect hardware and concientious sysadmins is > >reckless. Hardware /is/ flaky, sysadmins /are/ (sometimes) lazy (and > >besides, today they are increasingly just plain Joe Sixpack users). Also, > >backing up a few hundred GiB is /not/ fun, and then keeping track of all > >the backups is messy. > > Even home users have started to set up raid mirrors at home now that > disk space is cheap. That's a step in the right direction, I > suppose, with hardware never being good. I've lost more data to my own recklessness and stupidity than filesystem corruption and hardware failure combined. RAID isn't really a good solution. My policy for cheap storage (currently the only variety I own) is when I buy a new hard drive, use the old drive for backups. The old drive is always large enough to hold everything I'd miss and then some. Home users should be capable of doing the same, assuming Windows has something similar to rsync. > > Taking backups in an environment where you need a few hundred GiB > backed up is not that difficult. > > Get a separate, redundant box with a big tape changer and drop > periodical backups off at your bank's vault. > > Get a separate, very reduntant box, with a truckload of proven > drives in a separate raid box and run your stuff there. > > Get both of the above. > > If Joe Sixpack loses his mp3 collection, I don't really care, > nor should anyone else. Anything important enough to care > about is easy enough to back up. Always. > > Arrogance? Maybe. > > >Also, I'm not claiming that they are /solely/ responsible, but not having > >the filesystem fall apart utterly every time some bug breaths on it /is/ a > >requirement. > > Reiserfs does not fall apart utterly every time some bug breaths on it. > > >> *still trying to understand how that can be* > >You haven't been around too much yet, do you? > > Rather I take backups, buy better hardware and understand there's a > risk involved. > > Computers as a complete set can't be trusted, you can only make > the best accomodations you can. > -- Jake Maciejewski <[EMAIL PROTECTED]>
README clobbered
The README at ftp://ftp.namesys.com/pub/reiser4-for-2.6/ was modified today. When I tried to check the changes, I noticed that the file is empty. -- Jake Maciejewski <[EMAIL PROTECTED]>
Re: reiser4 on PPC
So you're working on getting reiser4 into vanilla? A recent article linked on Slashdot said it would be in 2.6.12, but I doubt that's going to happen. It's nice to hear you're trying. I'm sure some people have been suspecting that reiser4 has known issues and Namesys is holding it back. One of the reasons I reported the PPC bug was because I thought you would need more architectures working to get into the kernel. Evidently this is not the case. Are we going to see warnings saying reiser4 is currently only supported on x86 and AMD64? On Tue, 2005-05-03 at 11:25 -0700, Hans Reiser wrote: > > We won't turn down hardware, but it might be a few months before we can > do something about the port, we have to deal with kernel entry issues first. > > Hans -- Jake Maciejewski <[EMAIL PROTECTED]>
Re: reiser4 on PPC
On Mon, 2005-05-02 at 18:10 +0400, Alex Zarochentsev wrote: > Hi, > > On Sun, May 01, 2005 at 12:03:13PM -0500, Jake Maciejewski wrote: > > Now that reiser4 seems to be working on AMD64, I'm trying to test it on > > PPC. Unfortunately, I haven't even been able to mount a reiser4 FS. > > Unfortunately we could not test reiser4 on PPC because of lack of test > machine. > Currently no idea where it might fail. > > > I get the following error: "mount: No such file or directory". I've > > tried a loopback filesystem and a native partition. The same native > > patition works when formatted with reiserFS. I've tried the code as a > > module and builtin. I was using reiser4progs 1.0.4 and the latest -mm > > patch on vanilla, which while not officially supported works on AMD64 > > and x86 and shouldn't cause a problem like this. fsck.reiser4 says the > > unmountable filesystem is consistent. Is there anything else I should > > try? > > can you look at your machine /var/log/messages or dmesg(8) output for reiser4 > messages? Well, now that I've actually checked it, there is a warning. I get the same message regardless of the architecture the FS is created on. reiser4[mount(22352)]: key_warning (fs/reiser4/plugin/object.c:96)[nikita-717]: WARNING: Error for inode 720575940379279360 (-2) This is a clean, consistent filesystem we're talking about, so I guess it's a kernel problem. Is it worth trying a different kernel version? I'm trying to avoid -mm because it sometimes breaks alternative architectures, but I wanted the lastest version of the code. As I mentioned before, I used a cutsom patch that works on x86. I'm willing to try other versions if necessary. > > If you have possibility to check the fs by an fsck.reiser4 compiled on i386, > please do it. If you don't have i386 around or have no time to compile the > progs there, make a small file with reiser4 fs image , compress it and make it > downloadable. > > > > > -- > > Jake Maciejewski <[EMAIL PROTECTED]> > > > > Thanks in advance, > Alex. > -- Jake Maciejewski <[EMAIL PROTECTED]>
Re: reiser4 on PPC
On Mon, 2005-05-02 at 18:10 +0400, Alex Zarochentsev wrote: > Hi, > > On Sun, May 01, 2005 at 12:03:13PM -0500, Jake Maciejewski wrote: > > Now that reiser4 seems to be working on AMD64, I'm trying to test it on > > PPC. Unfortunately, I haven't even been able to mount a reiser4 FS. > > Unfortunately we could not test reiser4 on PPC because of lack of test > machine. > Currently no idea where it might fail. I have access to a friend's Mac mini, but you could use PearPC on one of your x86 machines. The website claims it's ~1/15th speed using "JITC-X86", so a fast x86 box would give you a reasonable PPC test environment. > > > I get the following error: "mount: No such file or directory". I've > > tried a loopback filesystem and a native partition. The same native > > patition works when formatted with reiserFS. I've tried the code as a > > module and builtin. I was using reiser4progs 1.0.4 and the latest -mm > > patch on vanilla, which while not officially supported works on AMD64 > > and x86 and shouldn't cause a problem like this. fsck.reiser4 says the > > unmountable filesystem is consistent. Is there anything else I should > > try? > > can you look at your machine /var/log/messages or dmesg(8) output for reiser4 > messages? I don't remember seeing anything unusual. > > If you have possibility to check the fs by an fsck.reiser4 compiled on i386, > please do it. If you don't have i386 around or have no time to compile the > progs there, make a small file with reiser4 fs image , compress it and make it > downloadable. I was able to mount and use it on AMD64, but I don't recall if I fscked it on AMD64. After adding a file to the reiser4 FS, I transfered the image back to the PPC machine and it gave me the same mount error. I suppose I could try making an image on x86 or AMD64. > > > > > -- > > Jake Maciejewski <[EMAIL PROTECTED]> > > > > Thanks in advance, > Alex. > -- Jake Maciejewski <[EMAIL PROTECTED]>
reiser4 on PPC
Now that reiser4 seems to be working on AMD64, I'm trying to test it on PPC. Unfortunately, I haven't even been able to mount a reiser4 FS. I get the following error: "mount: No such file or directory". I've tried a loopback filesystem and a native partition. The same native patition works when formatted with reiserFS. I've tried the code as a module and builtin. I was using reiser4progs 1.0.4 and the latest -mm patch on vanilla, which while not officially supported works on AMD64 and x86 and shouldn't cause a problem like this. fsck.reiser4 says the unmountable filesystem is consistent. Is there anything else I should try? -- Jake Maciejewski <[EMAIL PROTECTED]>
broken out archives
The broken out archives for reiser4 on vanilla (eg. ftp://ftp.namesys.com/pub/reiser4-for-2.6/2.6.11/reiser4-for-2.6.11-broken-out.2.gz ) should be renamed to indicate that they're gzipped tarballs, not gzipped diffs. It would also be convenient if Namesys supplied complete patches as was done with previous vanilla port releases. -- Jake Maciejewski <[EMAIL PROTECTED]>
Re: umount bug?
Thanks, it seems to be working now. On Thu, 2005-03-24 at 19:36 +0300, Vladimir Saveliev wrote: > The attached should help against umount problem on 2.6.11 + > ftp://ftp.namesys.com/pub/reiser4-for-2.6/2.6.11/reiser4-for-2.6.11-1.gz -- Jake Maciejewski <[EMAIL PROTECTED]>
Re: umount bug?
ed. > FSCK: Directory [103fa:456c7669726100:10b1b] (dir40), node [280116], > item [0], unit [4]: entry has wrong offset > [10b1b:0(NAME):1454c5649524120:2da0204869646173:d90d4d8c3e050058]. Should be > [10b1b:0(NAME):1454c5649524120:2da0204869646173:2d7ba794f3fdeba8]. Removed. > FSCK: Directory [103fa:456c7669726100:10b1b] (dir40), node [280116], > item [0], unit [4]: entry has wrong offset > [10b1b:0(NAME):1454c5649524120:2da0204b61706f73:e0d326cd7944dbc0]. Should be > [10b1b:0(NAME):1454c5649524120:2da0204b61706f73:3541800742e6ee70]. Removed. > FSCK: Directory [103fa:456c7669726100:10b1b] (dir40), node [280116], > item [0], unit [4]: entry has wrong offset > [10b1b:0(NAME):1454c5649524120:2da0204b61706f73:e9d2be510cdd28a8]. Should be > [10b1b:0(NAME):1454c5649524120:2da0204b61706f73:e38ca5c4628451b8]. Removed. > FSCK: Node (270533), item (8), [103fa:456c7669726100:10b1b] (stat40): > wrong size (15), Fixed to (5). > FSCK: Node (270533), item (8), [103fa:456c7669726100:10b1b] (stat40): > wrong bytes (1208), Fixed to (350). > Found 5864 objects. > Time interval: Wed Mar 23 18:03:00 2005 - Wed Mar 23 18:03:01 2005 > CLEANUPING STORAGE TREE > Removed items 0 > Time interval: Wed Mar 23 18:03:01 2005 - Wed Mar 23 18:03:01 2005 > * fsck.reiser4 finished at Wed Mar 23 18:03:01 2005 > Closing fs...done > > FS is consistent. > > [EMAIL PROTECTED]:~# fsck.reiser4 /dev/hda2 > *** > This is an EXPERIMENTAL version of fsck.reiser4. Read README first. > *** > > Fscking the /dev/hda2 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 Wed Mar 23 18:03:12 2005 > Reiser4 journal (journal40) on /dev/hda2: 0 transactions replayed of the > total 0 blocks. > Reiser4 fs was detected on /dev/hda2. > Master super block (16): > magic: ReIsEr4 > blksize:4096 > format: 0x0 (format40) > uuid: a4f5a623-b299-4619-a845-128b90df3d83 > label: > > Format super block (17): > plugin: format40 > description:Disk-format for reiser4, ver. 1.0.0 > magic: ReIsEr40FoRmAt > flushes:0 > mkfs id:0x1cf367de > blocks: 4863678 > free blocks:4500553 > root block: 362992 > tail policy:0x2 (smart) > next oid: 0x116e9 > file count: 5862 > tree height:3 > key policy: LARGE > > > CHECKING STORAGE TREE > Read nodes 3820 > Nodes left in the tree 3820 > Leaves of them 3745, Twigs of them 74 > Time interval: Wed Mar 23 18:03:13 2005 - Wed Mar 23 18:03:16 2005 > CHECKING EXTENT REGIONS. > Read twigs 74 > Time interval: Wed Mar 23 18:03:16 2005 - Wed Mar 23 18:03:16 2005 > CHECKING SEMANTIC TREE > Found 5864 objects. > Time interval: Wed Mar 23 18:03:16 2005 - Wed Mar 23 18:03:16 2005 > * fsck.reiser4 finished at Wed Mar 23 18:03:16 2005 > Closing fs...done > > FS is consistent. > > [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 > 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 -- Jake Maciejewski <[EMAIL PROTECTED]> FSCK: On-disk used blocks and really used blocks differ. FSCK: Node (18890670), item (0): 1 mergable units were found in the extent40 unit. Merged. FSCK: Node (13419560), item (0): 1 mergable units were found in the extent40 unit. Merged. FSCK: Node (13576128), item (0): 1 mergable units were found in the extent40 unit. Merged. FSCK: Node (12888089), item (0): 1 mergable units were found in the extent40 unit. Merged. FSCK: Node (14650954), item (0): 1 mergable units were found in the extent40 unit. Merged. FSCK: On-disk used blocks and really used blocks differ. Fixed.
Re: Reiser4 patch for 2.6.11 kernel
2.6.11-mm2 has been stable for me, whereas my "-mm patches on vanilla" hack jobs seem to lock up every few days on AMD64. -mm has its annoyances, however, so an updated vanilla patch would be greatly appreciated. On Mon, 2005-03-07 at 12:58 +0300, Vladimir Saveliev wrote: > Hello > > On Mon, 2005-03-07 at 11:40, Lars Tobias Børsting wrote: > > Hi, > > > > The 2.6.11 kernel has been out for some days now, but no Reiser4 patch > > has yet been released for it at > > http://ftp.namesys.com/pub/reiser4-for-2.6/. I need to update to 2.6.11 > > but I need Reiser4 support. > > > > Has anybody got any idea of if it will be long until a release? Thanks! > > reiser4 patch for 2.6.11 should get out this week > -- Jake Maciejewski <[EMAIL PROTECTED]>
Re: Plugin for corruption resistance?
I think this is a great idea. Solaris ZFS is supposed to have a similar feature, but reiser4 metas would allow application-level access. The purpose of checksumming in ZFS is more like Gregory's 2nd point, except Solaris takes it one step further. If you have RAID, ZFS will fix the corruption automatically. Even if we didn't have automatic correction, which would probably impossible without an integrated volume manager like ZFS, it would still be nice to know if your hard drive is flipping bits behind your back. On Fri, 2005-02-11 at 13:58 -0500, Gregory Maxwell wrote: > Anyone ever given a though to adding support to reiserfs to store a > cryptographic checksum along with a file? > > > The idea is that files get a hidden attribute that contains their SHA1 hash. > If the file is modified, the hash is marked as 'unclean'. A trusted > cleaner comes by eventually and hashes the file, OR the file is hashed > right away if someone tried to read the attribute while the file is > unclean. > > Fsck could be optionally told to go check the hash on every file. > Files could also be tested via a background process that randomly > tests some files every night. > > Why would this be useful? > > 1. Lots of applications today (such a P2P sharing systems) need the > hashes of files.. it's inefficient to keep recomputing them. The file > system always knows when a file changes, so it can be setup to always > return the correct hash. > > 2. Random disk corruption can go undetected (even if the drives ECC is > sufficient to prevent corruption there could be memory, bus, or kernel > issues the corrupt data, a hash will help it be detected). > > 3. Although there are encrypted block devices available in Linux, none > of them can provide authentication.. So it's possible for an attacker > (with access to your disk) to replace hunks of files with random (and > potentially chosen depending on the chaining mode) crud without > detection. > > 4. It could greatly speed up casual verification of files for changes > (if you don't trust the kernel to report the true hash, then you > couldn't trust it to return the real file to some userspace file > verifier either) it could also be used to help locate duplicates > in a very efficient manner.. -- Jake Maciejewski <[EMAIL PROTECTED]>
Re: AMD64 progress?
On Tue, 2005-02-08 at 22:12 +0300, Alex Zarochentsev wrote:
> On Tue, Feb 08, 2005 at 12:25:58PM -0600, Jake Maciejewski wrote:
> > On Mon, 2005-02-07 at 22:51 +0300, Alex Zarochentsev wrote:
> > > On Mon, Feb 07, 2005 at 01:34:56PM -0600, Jake Maciejewski wrote:
> > > > I'm running reiser4progs 1.0.3 and 2.6.10 patched with reiser4 from
> > > > 2.6.11-rc3-mm1 (and this patch).
> > > >
> > > > I've been doing the simultaneous dd and kernel compilation that has
> > > > always crashed reiser4 on AMD64 in the past. After about an hour with
> > > > debugging and two hours without debugging, I'm thinking of more ways to
> > > > torture the FS. For now it looks like reiser4 is working on AMD64!
> > >
> > > i think so. reiser4/amd64 passed 5h of stress testing instead of
> > > crashing in
> > > first 30min.
> > >
> > Have you been stress testing with debugging disabled? I was doing some
> > extreme testing and crashed reiser4 with this patch twice. The same test
>
> how it crashed? Was the fs corrupted after the crash?
As I said, it was extreme testing. I didn't keep track of my testing
procedures because I expected reiser4 to take whatever I threw at it.
Anyway, the first test involved one hard drive with a reiser4 filesystem
on a partition, and another drive with a reiser4 loopback filesystem on
a reiser4 loopback filesystem on XFS. The partition-based filesytem had
bonnie++, a kernel compile, and dd'ing a large file from /dev/zero all
going on at once, as I recall. The top-level loopback filesystem was
also running bonnie++, and I was continually cat'ing its loopback file
to /dev/null. Of course while all this was going, since I didn't expect
trouble, I was seeding about 30 torrents with Azureus (most of which are
actually stored on a Samba server mounted as SMBFS because CIFS has been
unstable ever since I added a gigabit card) and listening to MP3s with
XMMS. The music stopped, X froze, and I couldn't SSH in. After
rebooting, I discovered minor corruption on the parition-based reiser4
filesystem but neither loopback. --fix fixed it and --check after --fix
came up clean. The log from --fix:
FSCK: Directory [12557:6b636f6e666967:1257d]: can't find the object
[1257d:c673796d626f6c2e:12591] pointed by the entry [symbol.c].
FSCK: Directory [12557:6b636f6e666967:1257d]: can't find the object
[1257d:c673796d626f6c2e:12591] pointed by the entry [symbol.c]. Entry is
removed.
I probably should have checked what happened to symbol.c, but I didn't
think anything of it and continued testing on a fresh filesystem.
My next test was dd'ing a large file from /dev/zero, compiling a kernel,
running bonnie++, and "find . -type f -exec cat {} >/dev/null \;", all
looping and running simultaneously on a a fresh filesystem on a
parition, no loopback involved at all. Once again I was doing other
stuff at the time. I know I was watching a movie with mplayer, but I
don't remember if Azureus was going or not. It froze like the previous
time.
Figuring I was onto something with the above test, I tried reiserfs on
the same drive, same parition to eliminate hardware and other errors. It
ran for a few hours until I decided test reiser4 with debugging.
The same crazy combination of dd, kernel compilation, bonnie++, and
find/cat worked at least 7 hours with debugging enabled, although I
might not have been reproducing the conditions exactly because I think I
changed the options to dd so that the filesystem wouldn't fill up, as it
did several times before the crash.
At some point I tried compiling 2.6.11-rc3-mm1, but it failed. My crash
still isn't reproducible, but if I ever get something I have a 32-bit
installation to test if it's an AMD64-only problem.
>
> > that crashed it one of the times passes on reiserfs (didn't try the
> > other), and if enable debugging, I can torture reiser4 all night and
> > still not crash it. I'll do some more tests and try to identify a
> > simple, reproducible crash scenario.
>
> Thanks,
> Alex.
--
Jake Maciejewski <[EMAIL PROTECTED]>
Re: AMD64 progress?
On Mon, 2005-02-07 at 22:51 +0300, Alex Zarochentsev wrote: > On Mon, Feb 07, 2005 at 01:34:56PM -0600, Jake Maciejewski wrote: > > I'm running reiser4progs 1.0.3 and 2.6.10 patched with reiser4 from > > 2.6.11-rc3-mm1 (and this patch). > > > > I've been doing the simultaneous dd and kernel compilation that has > > always crashed reiser4 on AMD64 in the past. After about an hour with > > debugging and two hours without debugging, I'm thinking of more ways to > > torture the FS. For now it looks like reiser4 is working on AMD64! > > i think so. reiser4/amd64 passed 5h of stress testing instead of crashing in > first 30min. > Have you been stress testing with debugging disabled? I was doing some extreme testing and crashed reiser4 with this patch twice. The same test that crashed it one of the times passes on reiserfs (didn't try the other), and if enable debugging, I can torture reiser4 all night and still not crash it. I'll do some more tests and try to identify a simple, reproducible crash scenario. > > > > How did you track this bug down anyway? Do you have AMD64 hardware, or > > yes, we have amd64 h/w now. > > > did you look over the code and discover an invalid assumption? > > I found it only after realizing that reiser4_find_next_set_bit > is broken :( (its simple replacement worked fine) > > > If this > > bug is indeed fixed, are we any closer to inclusion in vanilla? > > > > On Mon, 2005-02-07 at 16:29 +0300, Alex Zarochentsev wrote: > > > Hello, > > > > > > On Sat, Jan 15, 2005 at 09:26:01PM -0500, Isaac Chanin wrote: > > > > > > > > Also tested this patch, similar results as to what I've been getting - > > > > ie. working for awhile (more than a few hours even this time, but that > > > > could just be coincidence, i suppose) and then going down with the > > > > normal > > > > reiser4_find_next_zero_bit(bnode_working_data(bnode), end_offset, > > > > start_offset) >= end_offset error. For the exact message see > > > > http://users.wpi.edu/~chanin/r4newpatch.txt. > > > > > > > > > > please try attached patch (it is for fs/reiser4 subtree) > > > > > -- > > Jake Maciejewski <[EMAIL PROTECTED]> > > > -- Jake Maciejewski <[EMAIL PROTECTED]>
Re: AMD64 progress?
I'm running reiser4progs 1.0.3 and 2.6.10 patched with reiser4 from 2.6.11-rc3-mm1 (and this patch). I've been doing the simultaneous dd and kernel compilation that has always crashed reiser4 on AMD64 in the past. After about an hour with debugging and two hours without debugging, I'm thinking of more ways to torture the FS. For now it looks like reiser4 is working on AMD64! How did you track this bug down anyway? Do you have AMD64 hardware, or did you look over the code and discover an invalid assumption? If this bug is indeed fixed, are we any closer to inclusion in vanilla? On Mon, 2005-02-07 at 16:29 +0300, Alex Zarochentsev wrote: > Hello, > > On Sat, Jan 15, 2005 at 09:26:01PM -0500, Isaac Chanin wrote: > > > > Also tested this patch, similar results as to what I've been getting - > > ie. working for awhile (more than a few hours even this time, but that > > could just be coincidence, i suppose) and then going down with the normal > > reiser4_find_next_zero_bit(bnode_working_data(bnode), end_offset, > > start_offset) >= end_offset error. For the exact message see > > http://users.wpi.edu/~chanin/r4newpatch.txt. > > > > please try attached patch (it is for fs/reiser4 subtree) > -- Jake Maciejewski <[EMAIL PROTECTED]>
Re: AMD64 progress?
I used the 2.6.10-1 patch on an otherwise vanilla 2.6.10. The filesystem
tested was freshly created with 1.0.3. I did my usual dd and kernel
compile. After the kernel compilation failed, all sorts of processes
just hung, even simple stuff like copying and removing files on other
filesystems.
reiser4[cc1(11377)]: check_blocks_bitmap
(fs/reiser4/plugin/space/bitmap.c:1203)[zam-623]:
code: -2 at fs/reiser4/search.c:1285
reiser4 panicked cowardly: assertion failed:
reiser4_find_next_zero_bit(bnode_working_data(bnode), end_offset, start_offset)
>= end_offset
--- [cut here ] - [please bite here ] -
Kernel BUG at debug:131
invalid operand: [1]
CPU 0
Modules linked in: ipv6 i2c_dev it87 i2c_sensor i2c_isa i2c_core ipt_state
ip_conntrack iptable_filter ip_tables snd_ioctl32 snd_seq snd_seq_device
snd_pcm_oss snd_mixer_oss 3c59x e1000 snd_intel8x0 snd_ac97_codec snd_pcm
snd_timer snd soundcore snd_page_alloc ehci_hcd ohci_hcd
Pid: 11377, comm: cc1 Not tainted 2.6.10+reiser4
RIP: 0010:[] {reiser4_do_panic+704}
RSP: 0018:0100168116e8 EFLAGS: 00010246
RAX: 8052f4e0 RBX: 010016811db8 RCX: 8052f4e0
RDX: 01001df1de88 RSI: 01001df1de88 RDI: 01001cb2ec00
RBP: ff6e8090 R08: R09: 000d
R10: R11: R12: 1ce2
R13: 0001 R14: 1c81 R15: 1c81
FS: 002a95863ae0() GS:80546e80() knlGS:
CS: 0010 DS: ES: CR0: 80050033
CR2: 002a95fb8000 CR3: 00101000 CR4: 06e0
Process cc1 (pid: 11377, threadinfo 01001681, task 0100019bb4f0)
Stack: 00300010 0100168117c8 010016811708 2c71
803fc0f0 8042e4c8
0003
Call Trace:{reiser4_block_count+77}
{schedulable+9}
{load_and_lock_bnode+101}
{parse_blocknr+326}
{reiser4_print_prefix+133}
{report_err+9}
{check_blocks_bitmap+1134}
{reiser4_check_block+22}
{zget+1075} {cbk_level_lookup+112}
{cbk_node_lookup+2445}
{lock_tail+1298}
{znode_is_any_locked+37}
{check_jload+52}
{jload_gfp+1092}
{move_lh_internal+1429}
{traverse_tree+1749}
{object_lookup+915}
{find_file_item+565} {read_tail+0}
{read_file+524} {txn_end+218}
{read_unix_file+736}
{done_context+773}
{reiser4_lookup+485}
{reiser4_getattr+332}
{reiser4_read+485} {vfs_read+228}
{sys_read+83} {system_call+126}
Code: 0f 0b 4d ad 40 80 ff ff ff ff 83 00 48 c7 c6 a0 f0 52 80 48
RIP {reiser4_do_panic+704} RSP <0100168116e8>
On Fri, 2005-01-14 at 23:17 +0300, Alex Zarochentsev wrote:
> On Wed, Jan 12, 2005 at 11:33:27PM -0600, Jake Maciejewski wrote:
> > There was mention of Namesys getting an AMD64 machine. Do you guys have
> > it yet? Has there been any progress on my reiser4 bug(s), particularly
> > the "reiser4_find_next_zero_bit(bnode_working_data(bnode), end_offset,
> > start_offset) >= end_offset" problem?
>
> can you test the following patch? I know that amd64 does not require
> strong word aligment, but may be amd64 bitops coded in assembler
> do that?
>
> = plugin/space/bitmap.c 1.185 vs edited =
> --- 1.185/plugin/space/bitmap.c Sun Dec 5 19:49:52 2004
> +++ edited/plugin/space/bitmap.c Fri Jan 14 23:15:53 2005
> @@ -57,13 +57,15 @@
>
> #define CHECKSUM_SIZE4
>
> +#define BYTES_PER_LONG (sizeof(long))
> +
> #if BITS_PER_LONG == 64
> # define LONG_INT_SHIFT (6)
> #else
> # define LONG_INT_SHIFT (5)
> #endif
>
> -#define LONG_INT_MASK (BITS_PER_LONG - 1)
> +#define LONG_INT_MASK (BITS_PER_LONG - 1UL)
>
> typedef unsigned long ulong_t;
>
> @@ -182,12 +184,41 @@
>
> #include
>
> +#if BITS_PER_LONG == 64
> +
> +#define OFF(addr) (((ulong_t)(addr) & (BYTES_PER_LONG - 1)) << 3)
> +#define BASE(addr) ((ulong_t*) ((ulong_t)(addr) & ~(BYTES_PER_LONG - 1)))
> +
> +static inline void reiser4_set_bit(int nr, void * addr)
> +{
> + ext2_set_bit(nr + OFF(addr), BASE(addr));
> +}
> +
> +static inline void reiser4_clear_bit(int nr, void * addr)
> +{
> + ext2_clear_bit(nr + OFF(addr), BASE(addr));
> +}
> +
> +static inline int reiser4_test_bit(int nr, void * addr)
> +{
> + return ext2_test_bit(nr + OFF(addr), BASE(addr));
> +}
> +static inline int reiser4_find_next_zero_bit(void * addr, int maxoffset, int
> offset)
> +{
> + int off = OFF(addr);
> +
> + return ext2_find_next_zero_bit(BASE(addr), maxoffset + off, offset +
> off) - off;
> +}
> +
> +#else
> +
> #define reiser4_set_bit(nr, addr)ext2_set_bit(nr, addr)
>
AMD64 progress?
There was mention of Namesys getting an AMD64 machine. Do you guys have it yet? Has there been any progress on my reiser4 bug(s), particularly the "reiser4_find_next_zero_bit(bnode_working_data(bnode), end_offset, start_offset) >= end_offset" problem? -- Jake Maciejewski <[EMAIL PROTECTED]>
Re: status of reiser4
Have there been any reports other than Isaac's of reiser4 working on AMD64? It still doesn't work for me, and I'd like to know if I'm the only one having problems. On Fri, 2004-12-17 at 10:18 -0800, Hans Reiser wrote: > Vladimir is working on one last bug that occurs if copy from user page > faults on the user space process's buffer, and then we are going to > bundle a set of patches together, send them to andrew morton, and then > start a discussion on the changes to core kernel code that Hellweg and > company object to that currently prevent our inclusion. > > hans -- Jake Maciejewski <[EMAIL PROTECTED]>
Re: making reiser4/AMD64 hardlock
I did more tests, this time with gcc 3.3 rather than 3.4 just in case...
http://people.msoe.edu/~maciejej/patches/AMD64_reiser4_debug/12-08-04/test1/
http://people.msoe.edu/~maciejej/patches/AMD64_reiser4_debug/12-08-04/test2/
test1 panicked with the usual failed assertion in
reiser4_find_next_zero_bit, but test2 did the following:
reiser4[fixdep(10653)]: parse_node40
(fs/reiser4/plugin/node/node40.c:767)[nikita-494]:
code: -2 at fs/reiser4/search.c:1285
WARNING: Wrong level found in node: 1 != 0
reiser4[fixdep(10653)]: parse_node40
(fs/reiser4/plugin/node/node40.c:767)[nikita-494]:
code: -2 at fs/reiser4/search.c:1221
WARNING: Wrong level found in node: 1 != 0
reiser4[fixdep(10653)]: make_space_by_shift_left
(fs/reiser4/carry_ops.c:963)[vs-899]:
code: -5 at fs/reiser4/plugin/node/node40.c:778
WARNING: make_space_by_shift_left: error accessing left neighbor: -5
reiser4[fixdep(10653)]: node_plugin_by_node (fs/reiser4/tree.h:282)[vs-214]:
code: -5 at fs/reiser4/plugin/node/node40.c:778
reiser4 panicked cowardly: assertion failed: znode_is_loaded(node)
--- [cut here ] - [please bite here ] -
... (see link)
On Wed, 2004-12-08 at 11:26 -0600, Jake Maciejewski wrote:
> My tests are always on newly-made filesystems. I'll revert the 10 Nov.
> patch, double check the code to make sure everything's patched right,
> recompile, and test again.
>
> On Wed, 2004-12-08 at 19:24 +0300, Alex Zarochentsev wrote:
> > Hi
> >
> > On Tue, Dec 07, 2004 at 03:46:58PM -0600, Jake Maciejewski wrote:
> > > With this patch get
> > >
> > > reiser4[cc1(10284)]: check_blocks_bitmap
> > > (fs/reiser4/plugin/space/bitmap.c:1174)[zam-623]:
> > > code: -2 at fs/reiser4/search.c:1285
> > > reiser4 panicked cowardly: assertion failed:
> > > reiser4_find_next_zero_bit(bnode_working_data(bnode), end_offset,
> > > start_offset) >= end_offset
> >
> > did you begin the tests with mkfs.reiser4 /dev/ ?
> >
> > >
> > > details at
> > > http://people.msoe.edu/~maciejej/patches/AMD64_reiser4_debug/12-07-04/zam-patch/
> > >
> > > which is pretty much the same thing documented in 11-20-04/sync_mount/ ,
> > > 11-10-04/with_bitmap.c.diff/ , 11-09-04/ , 11-08-04/test2/ ,
> > > 11-04-04/all-R4/ , and 11-04-04/R3-R4/
> > >
> > >
> > > When I also used Vladimir's "10 Nov 2004 19:08:47 +0300" bitmap.c.diff,
> > > my logs filled (~1.7 million lines) with
> > >
> > > WARNING: Wrong level found in node: 1 != 0
> > > reiser4[cc1(11554)]: parse_node40
> > > (fs/reiser4/plugin/node/node40.c:767)[nikita-494]:
> > > code: -2 at fs/reiser4/search.c:1312
> > >
> > > see 12-07-04/both-patches/
> > >
> > > The only other time I've seen an error like this was 11-08-04/test1/
> > > repeating
> > >
> > > WARNING: Failed to delete file body 84672
> > > reiser4[make(22140)]: parse_node40
> > > (fs/reiser4/plugin/node/node40.c:767)[nikita-494]:
> > > code: -2 at fs/reiser4/search.c:1278
> > >
> > >
> > > If you want, I'll run it again and probably hit the
> > > reiser4_find_next_zero_bit error instead. I didn't bother with
> > > fsck.reiser4 --build-fs and --check because now that I think about it,
> > > this isn't the sort of thing fsck needs to be able to fix. If fsck
> > > should be able to handle these cases, someone speak up and I'll provide
> > > more reports like 11-20-04/sync_mount/corruption/.
> > >
> > > On Tue, 2004-12-07 at 15:20 +0300, Alex Zarochentsev wrote:
> > > > On Wed, Nov 10, 2004 at 01:45:40PM -0600, Jake Maciejewski wrote:
> > > > > Does this show what you want?
> > > > > http://people.msoe.edu/~maciejej/patches/AMD64_reiser4_debug/11-10-04/with_bitmap.c.diff/
> > > >
> > > > Please apply the patch below. it definitely fixes one reiser4/amd64
> > > > bug.
> > > >
> > > >
> > > > = plugin/space/bitmap.c 1.183 vs edited =
> > > > --- 1.183/plugin/space/bitmap.c Wed Oct 13 17:22:01 2004
> > > > +++ edited/plugin/space/bitmap.cSun Dec 5 00:18:55 2004
> > > > @@ -170,7 +170,7 @@
> > > > static int
> > > > find_next_zero_bit_in_word(ulong_t word, int start_bit)
> > > > {
> > > > - unsigned int mask = 1 << start_bit;
> > > > + ulong_t mask = 1 << start_bit;
> > > > int i = start_bit;
> > > >
> > > > while ((word & mask) != 0) {
> > > > @@ -234,7 +234,7 @@
> > > > /* search for the first set bit in single word. */
> > > > static int find_last_set_bit_in_word (ulong_t word, int start_bit)
> > > > {
> > > > - unsigned bit_mask;
> > > > + ulong_t bit_mask;
> > > > int nr = start_bit;
> > > >
> > > > assert ("zam-965", start_bit < BITS_PER_LONG);
> > > --
> > > Jake Maciejewski <[EMAIL PROTECTED]>
> > >
> >
--
Jake Maciejewski <[EMAIL PROTECTED]>
Re: making reiser4/AMD64 hardlock
My tests are always on newly-made filesystems. I'll revert the 10 Nov.
patch, double check the code to make sure everything's patched right,
recompile, and test again.
On Wed, 2004-12-08 at 19:24 +0300, Alex Zarochentsev wrote:
> Hi
>
> On Tue, Dec 07, 2004 at 03:46:58PM -0600, Jake Maciejewski wrote:
> > With this patch get
> >
> > reiser4[cc1(10284)]: check_blocks_bitmap
> > (fs/reiser4/plugin/space/bitmap.c:1174)[zam-623]:
> > code: -2 at fs/reiser4/search.c:1285
> > reiser4 panicked cowardly: assertion failed:
> > reiser4_find_next_zero_bit(bnode_working_data(bnode), end_offset,
> > start_offset) >= end_offset
>
> did you begin the tests with mkfs.reiser4 /dev/ ?
>
> >
> > details at
> > http://people.msoe.edu/~maciejej/patches/AMD64_reiser4_debug/12-07-04/zam-patch/
> >
> > which is pretty much the same thing documented in 11-20-04/sync_mount/ ,
> > 11-10-04/with_bitmap.c.diff/ , 11-09-04/ , 11-08-04/test2/ ,
> > 11-04-04/all-R4/ , and 11-04-04/R3-R4/
> >
> >
> > When I also used Vladimir's "10 Nov 2004 19:08:47 +0300" bitmap.c.diff,
> > my logs filled (~1.7 million lines) with
> >
> > WARNING: Wrong level found in node: 1 != 0
> > reiser4[cc1(11554)]: parse_node40
> > (fs/reiser4/plugin/node/node40.c:767)[nikita-494]:
> > code: -2 at fs/reiser4/search.c:1312
> >
> > see 12-07-04/both-patches/
> >
> > The only other time I've seen an error like this was 11-08-04/test1/
> > repeating
> >
> > WARNING: Failed to delete file body 84672
> > reiser4[make(22140)]: parse_node40
> > (fs/reiser4/plugin/node/node40.c:767)[nikita-494]:
> > code: -2 at fs/reiser4/search.c:1278
> >
> >
> > If you want, I'll run it again and probably hit the
> > reiser4_find_next_zero_bit error instead. I didn't bother with
> > fsck.reiser4 --build-fs and --check because now that I think about it,
> > this isn't the sort of thing fsck needs to be able to fix. If fsck
> > should be able to handle these cases, someone speak up and I'll provide
> > more reports like 11-20-04/sync_mount/corruption/.
> >
> > On Tue, 2004-12-07 at 15:20 +0300, Alex Zarochentsev wrote:
> > > On Wed, Nov 10, 2004 at 01:45:40PM -0600, Jake Maciejewski wrote:
> > > > Does this show what you want?
> > > > http://people.msoe.edu/~maciejej/patches/AMD64_reiser4_debug/11-10-04/with_bitmap.c.diff/
> > >
> > > Please apply the patch below. it definitely fixes one reiser4/amd64 bug.
> > >
> > >
> > > = plugin/space/bitmap.c 1.183 vs edited =
> > > --- 1.183/plugin/space/bitmap.c Wed Oct 13 17:22:01 2004
> > > +++ edited/plugin/space/bitmap.c Sun Dec 5 00:18:55 2004
> > > @@ -170,7 +170,7 @@
> > > static int
> > > find_next_zero_bit_in_word(ulong_t word, int start_bit)
> > > {
> > > - unsigned int mask = 1 << start_bit;
> > > + ulong_t mask = 1 << start_bit;
> > > int i = start_bit;
> > >
> > > while ((word & mask) != 0) {
> > > @@ -234,7 +234,7 @@
> > > /* search for the first set bit in single word. */
> > > static int find_last_set_bit_in_word (ulong_t word, int start_bit)
> > > {
> > > - unsigned bit_mask;
> > > + ulong_t bit_mask;
> > > int nr = start_bit;
> > >
> > > assert ("zam-965", start_bit < BITS_PER_LONG);
> > --
> > Jake Maciejewski <[EMAIL PROTECTED]>
> >
>
--
Jake Maciejewski <[EMAIL PROTECTED]>
Re: making reiser4/AMD64 hardlock
With this patch get
reiser4[cc1(10284)]: check_blocks_bitmap
(fs/reiser4/plugin/space/bitmap.c:1174)[zam-623]:
code: -2 at fs/reiser4/search.c:1285
reiser4 panicked cowardly: assertion failed:
reiser4_find_next_zero_bit(bnode_working_data(bnode), end_offset, start_offset)
>= end_offset
details at
http://people.msoe.edu/~maciejej/patches/AMD64_reiser4_debug/12-07-04/zam-patch/
which is pretty much the same thing documented in 11-20-04/sync_mount/ ,
11-10-04/with_bitmap.c.diff/ , 11-09-04/ , 11-08-04/test2/ ,
11-04-04/all-R4/ , and 11-04-04/R3-R4/
When I also used Vladimir's "10 Nov 2004 19:08:47 +0300" bitmap.c.diff,
my logs filled (~1.7 million lines) with
WARNING: Wrong level found in node: 1 != 0
reiser4[cc1(11554)]: parse_node40
(fs/reiser4/plugin/node/node40.c:767)[nikita-494]:
code: -2 at fs/reiser4/search.c:1312
see 12-07-04/both-patches/
The only other time I've seen an error like this was 11-08-04/test1/
repeating
WARNING: Failed to delete file body 84672
reiser4[make(22140)]: parse_node40
(fs/reiser4/plugin/node/node40.c:767)[nikita-494]:
code: -2 at fs/reiser4/search.c:1278
If you want, I'll run it again and probably hit the
reiser4_find_next_zero_bit error instead. I didn't bother with
fsck.reiser4 --build-fs and --check because now that I think about it,
this isn't the sort of thing fsck needs to be able to fix. If fsck
should be able to handle these cases, someone speak up and I'll provide
more reports like 11-20-04/sync_mount/corruption/.
On Tue, 2004-12-07 at 15:20 +0300, Alex Zarochentsev wrote:
> On Wed, Nov 10, 2004 at 01:45:40PM -0600, Jake Maciejewski wrote:
> > Does this show what you want?
> > http://people.msoe.edu/~maciejej/patches/AMD64_reiser4_debug/11-10-04/with_bitmap.c.diff/
>
> Please apply the patch below. it definitely fixes one reiser4/amd64 bug.
>
>
> = plugin/space/bitmap.c 1.183 vs edited =
> --- 1.183/plugin/space/bitmap.c Wed Oct 13 17:22:01 2004
> +++ edited/plugin/space/bitmap.c Sun Dec 5 00:18:55 2004
> @@ -170,7 +170,7 @@
> static int
> find_next_zero_bit_in_word(ulong_t word, int start_bit)
> {
> - unsigned int mask = 1 << start_bit;
> + ulong_t mask = 1 << start_bit;
> int i = start_bit;
>
> while ((word & mask) != 0) {
> @@ -234,7 +234,7 @@
> /* search for the first set bit in single word. */
> static int find_last_set_bit_in_word (ulong_t word, int start_bit)
> {
> - unsigned bit_mask;
> + ulong_t bit_mask;
> int nr = start_bit;
>
> assert ("zam-965", start_bit < BITS_PER_LONG);
--
Jake Maciejewski <[EMAIL PROTECTED]>
AMD64/reiser4 sync mode test, documented corruption
Vladimir, I did another test, my typical dd and make, this time with kernel 2.6.10-rc2-mm2 and reiser4 mounted in sync mode. I'm still having problems with bitmap.c. Details can be found at http://people.msoe.edu/~maciejej/patches/AMD64_reiser4_debug/11-20-04/sync_mount/ Should I repeat the test with the bitmap.c.diff patch you sent me (http://people.msoe.edu/~maciejej/patches/AMD64_reiser4_debug/bitmap.c.diff)? Vitaly, I had the corruption problem again. --check came up clean after --build-fs. Details can be found at http://people.msoe.edu/~maciejej/patches/AMD64_reiser4_debug/11-20-04/sync_mount/corruption/ -- Jake Maciejewski <[EMAIL PROTECTED]>
Re: making reiser4/AMD64 hardlock
Good point. Unfortunately, I wiped out the corrupt filesystem to test 2.6.10-rc1. I didn't notice any corruption in my most recent test, but if it ever happens again, I'll do a --check after --build-fs and post the results. On Fri, 2004-11-12 at 21:17 +0300, Vitaly Fertman wrote: > Would you also run fsck.reiser4 --check on the device after fsck.reiser4 > --build-fs > to find out if fs is fixed or not before continue using it ? -- Jake Maciejewski <[EMAIL PROTECTED]>
Re: making reiser4/AMD64 hardlock
Does this show what you want? http://people.msoe.edu/~maciejej/patches/AMD64_reiser4_debug/11-10-04/with_bitmap.c.diff/ On Wed, 2004-11-10 at 19:08 +0300, Vladimir Saveliev wrote: > Hello > > On Wed, 2004-11-10 at 11:01, Jake Maciejewski wrote: > > I documented a few more AMD64 errors/panics. The system hasn't been > > freezing since I enabled debugging, but make, dd, or whatever else hits > > the bug(s) still freeze. > > > > http://people.msoe.edu/~maciejej/patches/AMD64_reiser4_debug/11-08-04/ > > with reiser4progs 1.0.2 and my custom patched 2.6.9 kernel > > > > http://people.msoe.edu/~maciejej/patches/AMD64_reiser4_debug/11-09-04/ > > with reiser4progs 1.0.2 and 2.6.10-rc1 with the ftp.namesys.com patch > > > > Would you please try to reproduce this problem (reiser4[dd(7926)]: > check_blocks_bitmap (fs/reiser4/plugin/space/bitmap.c:1174)[zam-623]) > with the attached patch? > > > Every test has been on a freshly made filesystem. > > > > You might be interested to know that I think fsck failed to fix > > corruption after my 11-08-04/test1. When I tried to build the kernel > > after a --build-fs, make failed. I didn't have checksums to verify the > > tree, so something else could have been wrong. It froze when I tried to > > dump metadata. > > > > On Thu, 2004-11-04 at 12:52 +0300, Vladimir Saveliev wrote: > > > Hello > > > > > > On Wed, 2004-11-03 at 23:18, Hendrik Visage wrote: > > > > On Wed, Nov 03, 2004 at 02:59:19AM -0600, Jake Maciejewski wrote: > > > > > I've been testing reiser4 on 2.6.9 (patches from 2.6.9-mm1 and fixes > > > > > from reiser4-for-2.6.9.diff). I have reiser4progs and libaal 1.0.1. > > > > > Syslog doesn't catch any errors when I get hardlocks (haven't tried > > > > > SysRq). I figured I could at least give you guys a hint about what > > > > > kind > > > > > of usage pattern kills reiser4. > > > > > > > > > > Please try to get as much debugging information as you can. > > > sysrq+t's output may help to understand the problem. Do you have "File > > > systems" -> "Reiser4" -> "Enable reiser4 debug options" -> "Assertions" > > > turned on? If no, please turn it, it may also help. Try to catch its > > > output, via serial console if it will not be stored in logs. > > > > > > I will try your test in x86. > > > > > > > I recall the last response about this issue: > > > > > > > > We need an AMD64 cpu... > > > > > > > well, yes. > > > > > > > > > > -- Jake Maciejewski <[EMAIL PROTECTED]>
Re: making reiser4/AMD64 hardlock
I documented a few more AMD64 errors/panics. The system hasn't been freezing since I enabled debugging, but make, dd, or whatever else hits the bug(s) still freeze. http://people.msoe.edu/~maciejej/patches/AMD64_reiser4_debug/11-08-04/ with reiser4progs 1.0.2 and my custom patched 2.6.9 kernel http://people.msoe.edu/~maciejej/patches/AMD64_reiser4_debug/11-09-04/ with reiser4progs 1.0.2 and 2.6.10-rc1 with the ftp.namesys.com patch Every test has been on a freshly made filesystem. You might be interested to know that I think fsck failed to fix corruption after my 11-08-04/test1. When I tried to build the kernel after a --build-fs, make failed. I didn't have checksums to verify the tree, so something else could have been wrong. It froze when I tried to dump metadata. On Thu, 2004-11-04 at 12:52 +0300, Vladimir Saveliev wrote: > Hello > > On Wed, 2004-11-03 at 23:18, Hendrik Visage wrote: > > On Wed, Nov 03, 2004 at 02:59:19AM -0600, Jake Maciejewski wrote: > > > I've been testing reiser4 on 2.6.9 (patches from 2.6.9-mm1 and fixes > > > from reiser4-for-2.6.9.diff). I have reiser4progs and libaal 1.0.1. > > > Syslog doesn't catch any errors when I get hardlocks (haven't tried > > > SysRq). I figured I could at least give you guys a hint about what kind > > > of usage pattern kills reiser4. > > > > Please try to get as much debugging information as you can. > sysrq+t's output may help to understand the problem. Do you have "File > systems" -> "Reiser4" -> "Enable reiser4 debug options" -> "Assertions" > turned on? If no, please turn it, it may also help. Try to catch its > output, via serial console if it will not be stored in logs. > > I will try your test in x86. > > > I recall the last response about this issue: > > > > We need an AMD64 cpu... > > > well, yes. > > > > -- Jake Maciejewski <[EMAIL PROTECTED]>
Re: making reiser4/AMD64 hardlock
OK, I have some results for you at http://people.msoe.edu/~maciejej/patches/AMD64_reiser4_debug/11-04-04 all-R4 contains the results of running both make and dd on one reiser4 filesystem. R3-R4 is make on reiser4 and dd on reiserFS. The same assertion fails in both cases, making me even more curious why reiser4 cares that dd is running on a different filesystem. I don't get complete crashes when not in X, but the system requires a reboot because umount fails, ps hangs, etc. Enabling assertions caused log output that I wasn't getting otherwise. In both cases the reiser4 filesystem suffered corruption but fsck seemed to fix it. Other Gentoo users are using my reiser4 patch on x86 and I haven't heard of any problems yet. You can find it at patches/reiser4_from_2.6.9-mm1_for_2.6.9.patch.bz2 > Please try to get as much debugging information as you can. > sysrq+t's output may help to understand the problem. Do you have "File > systems" -> "Reiser4" -> "Enable reiser4 debug options" -> "Assertions" > turned on? If no, please turn it, it may also help. Try to catch its > output, via serial console if it will not be stored in logs. -- Jake Maciejewski <[EMAIL PROTECTED]>
making reiser4/AMD64 hardlock
I've been testing reiser4 on 2.6.9 (patches from 2.6.9-mm1 and fixes from reiser4-for-2.6.9.diff). I have reiser4progs and libaal 1.0.1. Syslog doesn't catch any errors when I get hardlocks (haven't tried SysRq). I figured I could at least give you guys a hint about what kind of usage pattern kills reiser4. One command that seems to do it every time (in no more than a few minutes) is the following, run from a directory containing kernel source: for i in `seq 1 20` ; do make mrproper ; zcat /proc/config.gz > .config ; make ; echo $i ; done & for i in `seq 1 5` ; do dd if=/dev/zero of=large_file bs=1M count=20k ; rm large_file ; echo $i ; done Now here's the interesting part. Other FSs on the same drive can run the command without locking, and better yet, either component of the command runs without trouble on reiser4! It's the combination of make and dd that kills my system. Even stranger is that I can run the dd part of the command on a reiserFS (v3) on the same drive and it still locks. Could the problem be in the patches rather than the reiser4 core? If your answer is "try -mm," I have. It kills -mm too, the only difference being when I tried it on -mm I used make -j16. Also, -mm is a huge pain on anything other than x86 because it usually breaks more features than it fixes, assuming it even compiles. Is there anything more I should try? Does anyone have reiser4 working on AMD64? It would be a shame to make it into vanilla without support for a significant server architecture. -- Jake Maciejewski <[EMAIL PROTECTED]>
