Re: A Word of Warning about Linux Software Raid
Hello, On Fri, 11 Aug 2006 21:34:50 +0200 Adrian Ulrich [EMAIL PROTECTED] wrote: | It seems that the kernel does not check the integrity of the data on mirrored raid, | | It does if you tell the kernel to do so: | | # echo check /sys/block/md0/md/sync_action I have just upgraded from an older kernel to be able to use such a functionality but : boogie:~# cat /proc/mdstat Personalities : [linear] [raid0] [raid1] [raid5] [raid4] [raid6] [multipath] md0 : active raid0 sde1[0] sdk1[6] sdj1[5] sdi1[4] sdh1[3] sdg1[2] sdf1[1] 501773440 blocks 64k chunks unused devices: none boogie:~# echo check /sys/block/md0/md/sync_action -bash: /sys/block/md0/md/sync_action: Permission denied boogie:~# mount | grep sys sysfs on /sys type sysfs (rw) What am i missing here ? Thanks, Philippe
Re: cryptcompress 2.6.16-5 reiser4 and/or 2.6.17-mm5
Danny Milosavljevic wrote: Hi, So after an insane amount of time of slacking off I'm actually trying the cryptcompress stuff now... However, I face some problems setting it up, because I deviate from the instructions :) What I tried: 1) download ftp://ftp.namesys.com/pub/tmp/cryptcompress_patches/2.6.16/ reiser4progs-1.0.6.tar.gz 2) compile and run, ./mkfs.reiser4 -o create=ccreg40 /dev/sda1 in the source directory Works fine, it seems (note that I used libaal 1.0.5). 3) get my 2.6.17-mm5 version without any extra patches to support it (probably no use trying, but...) mount /dev/sda1 /mnt/tmp dmesg [ 3584.914789] reiser4[mount(28515)]: plugin_by_unsafe_id (/home/dannym/work/src/kernels/linux-2.6.17/fs/reiser4/plugin/plugin.c:276) [nikita-2913]: [ 3584.914792] WARNING: Invalid plugin id: [16:4] [ 3584.914798] reiser4[mount(28515)]: unknown_plugin (/home/dannym/work/src/kernels/linux-2.6.17/fs/reiser4/plugin/item/ static_stat.c:58)[nikita-620]: [ 3584.914801] WARNING: Unknown plugin 4 in 42 [ 3584.914804] reiser4[mount(28515)]: init_inode_static_sd (/home/dannym/work/src/kernels/linux-2.6.17/fs/reiser4/plugin/item/ static_stat.c:177)[nikita-631]: [ 3584.914807] WARNING: unused space in inode 42 failed (as expected, probably)... 4) okay, so I thought it was time to do it properly and tried to use 2.6.16 vanilla, plus ftp://ftp.namesys.com/pub/reiser4-for-2.6/2.6.16/ reiser4-for-2.6.16-5.patch.gz plus ftp://ftp.namesys.com/pub/tmp/cryptcompress_patches/2.6.16/patches/* Hmm... This is for internal usage only. I have removed it, sorry (nothing really confidential, but this stuff changes disk format including your old reiser4 partitions). Wait for official release. Everyone who wants to test it, send us a private message. Unfortunately, the patches from the last URL do not apply to that (most were already applied, save a few hunks that actually did get applied fine and the small remainder of rejects). trying to mount the filesystem with that kind of monster kernel (yeah, I actually finished compiling that kernel :)) causes: mount /dev/sda1 /mnt/tmp reiser4[mount(1190)]: init_read_super (fs/reiser4/init_super.c:602)[nikita-2608]: WARNING: mmcblk0p1: wrong master super block magic So, are there any more current 2.6.16 cryptcompress patches? Should I do it differently? Is it ok to start from reiser4-for-2.6.16-2.patch as README says? Yes, follow the instructions precisely, and please, read warnings in the README carefully. libaal-1.0.5 - ok. Thanks, Edward. I figured rather start from the latest reiser4 fixes so that my testing makes any sense... (as for my choice of 2.6.16, it's the one with the newest mtime on the directory (ftp://ftp.namesys.com/pub/reiser4-for-2.6/;), and it was easier to do :)) cheers, Danny
Re: reiser4-2.6.18-rc2-mm1: possible circular locking dependency detected in txn_end
Le 03.08.2006 17:07, Laurent Riffard a écrit :
Le 03.08.2006 08:09, Alexander Zarochentsev a écrit :
On Tuesday 01 August 2006 01:29, Laurent Riffard wrote:
Le 31.07.2006 21:55, Vladimir V. Saveliev a écrit :
Hello
What kind of load did you run on reiser4 at that time?
I just formatted a new 2GB Reiser4 FS, then I moved a whole ccache
cache tree to this new FS (cache size was about 20~30 Mbytes).
Something like:
# mkfs.reiser4 /dev/vglinux1/ccache
# mount -tauto -onoatime /dev/vglinux1/ccache /mnt/disk
# mv ~laurent/.ccache/* /mnt/disk/
I was not able to reproduce it. Can you please try the following patch?
lock validator friendly locking of new atom in
atom_begin_and_assign_to_txnh and locking of two atoms.
Signed-off-by: Alexander Zarochentsev [EMAIL PROTECTED]
---
fs/reiser4/txnmgr.c | 14 --
fs/reiser4/txnmgr.h | 15 +++
2 files changed, 23 insertions(+), 6 deletions(-)
[patch snipped]
I tried this patch: it's slow as hell (CPU is ~100% system) and it
panics when syncing...
reiser4 panicked cowardly: reiser4[shutdown(1904)]: spin_lock_atom
(fs/reiser4/txmgr.h:509)[]:
Hello,
I tried again with linux 2.6.18-rc3-mm2+hotfixes.
# booted to runlevel 1
~$ mount
...
/dev/mapper/vglinux1-lvhome on /home type reiserfs (rw)
/dev/mapper/vglinux1-lvccache on /home/laurent/.ccache type reiser4
(rw,nosuid,nodev,noatime)
...
~$ df ~/.ccache
FilesystemSize Used Avail Use% Mounted on
/dev/mapper/vglinux1-lvccache
2.0G 53M 1.9G 3% /home/laurent/.ccache
~$ time mv ~/.ccache/* ~/tmp/ccache
0.10user 6.01system 0:07.92elapsed 77%CPU (0avgtext+0avgdata 0maxresident)k
0inputs+0outputs (1major+296minor)pagefaults 0swaps
dmesg output:
===
[ INFO: possible circular locking dependency detected ]
---
mv/1255 is trying to acquire lock:
(txnh-hlock){--..}, at: [e101f0cf] txn_end+0x191/0x368 [reiser4]
but task is already holding lock:
(atom-alock){--..}, at: [e101b674] txnh_get_atom+0xf6/0x39e [reiser4]
which lock already depends on the new lock.
the existing dependency chain (in reverse order) is:
- #1 (atom-alock){--..}:
[c012ce82] lock_acquire+0x60/0x80
[c0291c08] _spin_lock+0x19/0x28
[e101cc0b] try_capture+0x7cf/0x1cd7 [reiser4]
[e10096e5] longterm_lock_znode+0x427/0x84f [reiser4]
[e1038fe7] seal_validate+0x221/0x5ee [reiser4]
[e10652a1] find_entry+0x126/0x307 [reiser4]
[e1065974] rem_entry_common+0xe9/0x4ba [reiser4]
[e104c9bc] unlink_common+0x258/0x364 [reiser4]
[c015f7bc] vfs_unlink+0x47/0x87
[c01611b4] do_unlinkat+0x8c/0x122
[c016125a] sys_unlink+0x10/0x12
[c0102c39] sysenter_past_esp+0x56/0x8d
- #0 (txnh-hlock){--..}:
[c012ce82] lock_acquire+0x60/0x80
[c0291c08] _spin_lock+0x19/0x28
[e101f0cf] txn_end+0x191/0x368 [reiser4]
[e10109b5] reiser4_exit_context+0x1c2/0x571 [reiser4]
[e104cabd] unlink_common+0x359/0x364 [reiser4]
[c015f7bc] vfs_unlink+0x47/0x87
[c01611b4] do_unlinkat+0x8c/0x122
[c016125a] sys_unlink+0x10/0x12
[c0102c39] sysenter_past_esp+0x56/0x8d
other info that might help us debug this:
3 locks held by mv/1255:
#0: (inode-i_mutex/1){--..}, at: [c0161181] do_unlinkat+0x59/0x122
#1: (inode-i_mutex){--..}, at: [c0290a94] mutex_lock+0x21/0x24
#2: (atom-alock){--..}, at: [e101b674] txnh_get_atom+0xf6/0x39e
[reiser4]
stack backtrace:
[c0103a97] show_trace+0xd/0x10
[c0103ff6] dump_stack+0x19/0x1b
[c012c20d] print_circular_bug_tail+0x59/0x64
[c012ca2c] __lock_acquire+0x814/0x9a5
[c012ce82] lock_acquire+0x60/0x80
[c0291c08] _spin_lock+0x19/0x28
[e101f0cf] txn_end+0x191/0x368 [reiser4]
[e10109b5] reiser4_exit_context+0x1c2/0x571 [reiser4]
[e104cabd] unlink_common+0x359/0x364 [reiser4]
[c015f7bc] vfs_unlink+0x47/0x87
[c01611b4] do_unlinkat+0x8c/0x122
[c016125a] sys_unlink+0x10/0x12
[c0102c39] sysenter_past_esp+0x56/0x8d
~$ time sync
0.00user 0.02system 0:00.49elapsed 4%CPU (0avgtext+0avgdata 0maxresident)k
0inputs+0outputs (1major+202minor)pagefaults 0swaps
Move the files backward...
~$ time mv ~/tmp/ccache/* ~/.ccache/
0.11user 3.98system 0:04.09elapsed 100%CPU (0avgtext+0avgdata 0maxresident)k
0inputs+0outputs (0major+286minor)pagefaults 0swaps
~$ time sync
0.00user 0.00system 0:01.86elapsed 0%CPU (0avgtext+0avgdata 0maxresident)k
0inputs+0outputs (0major+204minor)pagefaults 0swaps
So this problem still appears in 2.6.18-rc3-mm2+hotfixes.
I applied the patch zam sent 01 August 2006. Compile, boot to
runlevel 1 and test again. The warning
reiserfs panic (device null superblock) check_internal_block_head
Hi, I'm experiencing a very strange issue with my reiserfs partition. I was trying to delete a file, when I saw that the rm command segfaulted. then my whole system froze. it turned out, that a kernel panic occured when I tried to delete the file, probably in the reiserfs driver. now whenever I try to mount the partition read-write, it tries to replay the delete, which produces the same kernel panic. the message I get is about the following: reiserfs panic (device null superblock) check_internal_block_head (couldn't copy the whole of it, as the machine itself freezes afterwards) strangely enough, doing a reiserfsck says that all is OK with the partition. I can also mount it read-only (obviously the journal is not played back at that time). also tried to mount with -o nolog, but that didn't give better results. how would I solve this issue? should I rebould the superblock? Akos
Re: cryptcompress 2.6.16-5 reiser4 and/or 2.6.17-mm5
Hi, On Sat, 12 Aug 2006 17:14:34 +0400, Edward Shishkin wrote: Danny Milosavljevic wrote: [...] Hmm... This is for internal usage only. I have removed it, sorry (nothing really confidential, but this stuff changes disk format including your old reiser4 partitions). Wait for official release. Everyone who wants to test it, send us a private message. I am trying it on another computer that doesn't have anything on it, so no danger here. [...] Should I do it differently? Is it ok to start from reiser4-for-2.6.16-2.patch as README says? Yes, follow the instructions precisely, and please, read warnings in the README carefully. libaal-1.0.5 - ok. Okay :) cheers, Danny
