Re: Problem with multiple mounts

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



Lennart Sorensen wrote:
On Wed, Nov 08, 2006 at 11:22:15AM -0800, Suzuki wrote:

"I exported a disk partition using nbd protocol. On the nbd client, I make reiserfs and run fsstress test case on this partition. At the same time, I mount this partition on the nbd server. Then Oops appears as following:"

ReiserFS: sda10: found reiserfs format "3.6" with standard journal
ReiserFS: sda10: using ordered data mode
ReiserFS: sda10: journal params: device sda10, size 8192, journal first block 18, max trans len 1024, max batch 900, max commit age 30, max trans age 30
ReiserFS: sda10: checking transaction log (sda10)

Oops: Kernel access of bad area, sig: 11 [#1]

Call Trace:
[C000000011333090] [C0000000001EDB70] .journal_read+0x165c/0x1b6c (unreliable)
[C000000011333410] [C0000000001EF280] .journal_init+0xdc0/0xee8
[C000000011333530] [C0000000001CDBD8] .reiserfs_fill_super+0xa90/0x1e40
[C000000011333790] [C00000000011E988] .get_sb_bdev+0x208/0x31c
[C000000011333870] [C0000000001CA00C] .get_super_block+0x38/0x60
[C000000011333900] [C00000000011E260] .vfs_kern_mount+0xec/0x198
[C0000000113339B0] [C00000000011E3E0] .do_kern_mount+0x88/0xdc
[C000000011333A50] [C0000000001532CC] .do_mount+0xd50/0xe08
[C000000011333D60] [C000000000175090] .compat_sys_mount+0x368/0x448
[C000000011333E30] [C00000000000861C] syscall_exit+0x0/0x40

But, if we try the steps in the reverse order,

"mount the partition on nbd server first and then try fsstress tests on the client side. This is just to ensure that the server is not seeing an incomplete journal created by the client side runs."

Things work fine !

I doubt if this is due to the mount finding an incomplete journal created by the client side fsstress runs in the first scenario.

My question is : Is this supported ? Mounting a filesystem which is already mounted and replaying the ( - a may be incomplete- ) journal.


Absolutely not supported.  Unless you have a filesystem that is
specifically designed for simultanious read-write mount from multiple
places, then you can't.  For performance reasons most systems cache
writes and updates in many cases, so the data read by one system may be
out of date because another system has an update waiting to go to disk.
You need a filesystem that has the ability for multiple systems to talk
to each other about updates and locking and such things.  Look for a
cluster supporting filesystem or whatever is used to refer to a
filesystem that supports multiple hosts having it mounted to provide
redundant access.  No normal filesystem can do it unless everyone has it
mounted read only.  If you want to share it, use NFS.  That's what it's
for.

Thanks for the response. This problem was reported by one of our test team on 2.6.19. So, I wanted to confirm that what they are doing is not supported !



Thanks,

Suzuki

--
Len Sorensen

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [email protected]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[Index of Archives]     [Kernel Newbies]     [Netfilter]     [Bugtraq]     [Photo]     [Stuff]     [Gimp]     [Yosemite News]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux RAID]     [Video 4 Linux]     [Linux for the blind]     [Linux Resources]
  Powered by Linux