RAID-1 and Reiser4 issue: umount hangs
Hi, I'm using Reiser4 for my filesystems on disk (/dev/sda) , and it works just fine. Recently I bought a second disk (/dev/sdb) for RAID-1 mirroring. With mdadm I created a degraded raid-1 array on /dev/md/0, devices missing,/dev/sdb1. After that I created a Reiser4 filesystem on /dev/md/0 and mounted it at /mnt. Then I copied the data from /dev/sda1 to /mnt. All goes well until I umount /mnt, umount simply hangs without any error. Syslog doesn't report any error. In /proc/mdstat, the array remains "active sync". Shutting down linux fails because the umount is still waiting and seems to block other umounts. The umount process cannot be killed by the root. A hard reset is the only resolution to get my system functioning normally, but without the raid-1 of course. The problem seems to emerge only with the combination of RAID and Reiser4. I've created an ext-2 filesystem on /dev/md/0, and after that mount ; cp -ax ; umount works without a problem, and the hanging umount re-appears when using Reiser4 again. My questions: - how can I find the cause of the hanging umount? - how can I fix it? A few details of my linux-box: Gentoo Linux, 2.6.16 kernel with Reiser4-for-2.6.16-2.patch.gz i686 AMD Athlon(tm) XP 2400+ DC4300 SATA-II controller (Silicon Image 3124, libata + sata_sil24 drivers) 2 x Samsung SP2504C hard disk I've posted this issue to the linux-kernel mailing list, but Neil Brown wrote: > This looks very much like a reiser4 problem rather than a raid > problem, or at least you will need someone very familiar with reiser4 > to understand what is going on here. > So here's my post. The call trace of the hanging umount is the following: > syslog-ng R running 0 7581 17197 (NOTLB) > umountD C011B591 0 7588 7200 (NOTLB) > f6643c98 c1808320 c011b591 f7db5ad0 f4d18c00 003d092a > f7db5ad0 c1808320 f4d18c00 003d092a f6b33540 c1808320 > f4d18c00 003d092a f6b33540 f6b33668 c1808320 f6643cfc > Call Trace: > [] __wake_up_common+0x41/0x70 > [] io_schedule+0x26/0x30 > [] sync_page+0x4b/0x60 > [] __wait_on_bit+0x45/0x70 > [] sync_page+0x0/0x60 > [] wait_on_page_bit+0xad/0xc0 > [] wake_bit_function+0x0/0x60 > [] wake_bit_function+0x0/0x60 > [] jwait_io+0x59/0x80 > [] update_journal_header+0x83/0xb0 > [] commit_tx+0xca/0x110 > [] reiser4_write_logs+0x141/0x1e0 > [] commit_current_atom+0x171/0x2c0 > [] try_commit_txnh+0x13f/0x1e0 > [] commit_txnh+0x34/0xd0 > [] txn_end+0x2c/0x30 > [] txn_restart+0x10/0x30 > [] txn_restart_current+0x1a/0x20 > [] force_commit_atom+0x3f/0x70 > [] txnmgr_force_commit_all+0xea/0x130 > [] release_format40+0x7e/0x150 > [] init_context+0x58/0x80 > [] reiser4_put_super+0x89/0xf0 > [] invalidate_inodes+0x5d/0x80 > [] generic_shutdown_super+0x156/0x160 > [] kill_block_super+0x2d/0x50 > [] deactivate_super+0x60/0x80 > [] sys_umount+0x3f/0x90 > [] do_page_fault+0x1c0/0x5a8 > [] sys_munmap+0x51/0x80 > [] sys_oldumount+0x17/0x20 > [] sysenter_past_esp+0x54/0x75 Thanx in advance, Arend
reiser4 for 2.6.16 (version 3)
Hello ftp://ftp.namesys.com/pub/reiser4-for-2.6/2.6.16/reiser4-for-2.6.16-3.patch.gz contains the most recent reiser4 code which is considered stable inside Namesys. This code is supposed to be in mm kernel next to 2.6.17-rc4-mm3. Please try it. Any feedback is welcome.
RE: Bug#369285: reiserfsprogs: can't mount reiserfs volume with 8kb block size
Hi Domenico, Currently ReiserFS supports 4 KB block only. Following link will explain you more on this. www.oracle.com/technology/pub/articles/calish_filesys.html Kindly come back, still if you have any doubts Regards, Masthan -Original Message- From: Domenico Andreoli [mailto:[EMAIL PROTECTED] Sent: Monday, May 29, 2006 11:58 AM To: Andreas Beckmann Cc: reiserfs-list@namesys.com; [EMAIL PROTECTED]; [EMAIL PROTECTED]; [EMAIL PROTECTED] Subject: Re: Bug#369285: reiserfsprogs: can't mount reiserfs volume with 8kb block size forwarded 369285 reiserfs-list@namesys.com merge 304342 369285 thanks On Sun, May 28, 2006 at 11:03:11PM +0200, Andreas Beckmann wrote: > > Hi, hi Andreas, > I just created a new reiserfs volume with the following command: > mkreiserfs -d -l backup -b 8192 /dev/hda11 but mounting it fails > with the error: > mount: wrong fs type, bad option, bad superblock on /dev/hda11, >missing codepage or other error >In some cases useful info is found in syslog - try >dmesg | tail or so > and dmesg says: > ReiserFS: hda11: warning: sh-2011: read_super_block: can't find a > reiserfs filesystem on (dev hda11, block 32, size 2048) > ReiserFS: hda11: warning: sh-2021: reiserfs_fill_super: can not find > reiserfs on hda11 > > Other blocksizes just work fine. that block sizes different from 4k do not work is a known problem, please see bug #304342. last news i heard about this is of more than a year ago. Vitaly, maybe you have a nice release under the cover? :) cheers domenico -[ Domenico Andreoli, aka cavok --[ http://people.debian.org/~cavok/gpgkey.asc ---[ 3A0F 2F80 F79C 678A 8936 4FEE 0677 9033 A20E BC50
