On 05/15/2012 03:19 PM, Johannes Schild wrote: > Hi, > > thanks for your fast reply. > > But now i run into a nullpointer exception while mounting /dev/osd0 > > > [ 329.919112] Modules linked in: raid456 async_raid6_recov async_pq > raid6_pq async_memcpy bnx2i cnic cxgb4i cxgb3i iscsi_tcp be2iscsi > iscsi_boot_sysfs uio cxgb4 libcxgbi cxgb3 mdio libiscsi_tcp libiscsi > scsi_transport_iscsi fuse ip6t_REJECT nf_conntrack_ipv6 > nf_defrag_ipv6 xt_state nf_conntrack 8021q ip6table_filter ip6_tables > garp stp llc fcoe libfcoe libfc scsi_transport_fc scsi_tgt > snd_ens1371 gameport snd_rawmidi snd_ac97_codec ac97_bus joydev > snd_seq snd_seq_device snd_pcm ppdev vmw_balloon floppy parport_pc > snd_timer snd pcnet32 microcode parport pcspkr mii snd_page_alloc > i2c_piix4 i2c_core shpchp uinput mptspi mptscsih mptbase > scsi_transport_spi [last unloaded: iscsi_tcp] [ 329.919133] One thing that worries me here is this: [last unloaded: iscsi_tcp] Actually it should be in the loaded bunch not unloaded. I have no idea how can that happen. Do you see any prints in dmsg regarding iscsi, before the crash? > [ 329.919134] Pid: 2234, comm: mount Not tainted 3.3.0-pnfs #1 VMware, Inc. VMware Virtual Platform/440BX Desktop Reference Platform > [ 329.919137] RIP: 0010:[<ffffffff81259799>] [<ffffffff81259799>] exofs_free_sbi+0x59/0xa0 > [ 329.919139] RSP: 0018:ffff88003c4e5bc8 EFLAGS: 00010246 > [ 329.919141] RAX: 0000000000000000 RBX: 0000000000000000 RCX: 0000000000001795 > [ 329.919142] RDX: 0000000000000000 RSI: 0000000000000046 RDI: ffff88003c4f5000 > [ 329.919143] RBP: ffff88003c4e5bd8 R08: 0000000000000000 R09: 0000000000000000 > [ 329.919144] R10: 0000000000000000 R11: 0000000000000001 R12: ffff88003c4f5000 > [ 329.919145] R13: ffff88003c4e5d58 R14: 00000000fffffffb R15: ffff88003bd4e360 > [ 329.919146] FS: 00007f68ce81d800(0000) GS:ffff88003fc00000(0000) knlGS:0000000000000000 > [ 329.919148] CS: 0010 DS: 0000 ES: 0000 CR0: 000000008005003b > [ 329.919149] CR2: 0000000000000000 CR3: 000000003cbfd000 CR4: 00000000000406f0 > [ 329.919152] DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 > [ 329.919155] DR3: 0000000000000000 DR6: 00000000ffff0ff0 DR7: 0000000000000400 > [ 329.919156] Process mount (pid: 2234, threadinfo ffff88003c4e4000, task ffff88003aa42e40) > [ 329.919157] Stack: > [ 329.919158] ffff88003c4f5000 ffff88003c4f5800 ffff88003c4e5d18 ffffffff8125a780 > [ 329.919160] ffff88003c4e5c84 0000000081f27618 ffffffff81f27600 ffff88003f80c288 > [ 329.919162] ffff88003ddbeee0 0000000000000000 ffff88003c4e5c48 ffffffff812c8433 > [ 329.919164] Call Trace: > [ 329.919166] [<ffffffff8125a780>] exofs_fill_super+0x440/0x6e0 > [ 329.919171] [<ffffffff812c8433>] ? idr_pre_get+0x53/0x90 > [ 329.919173] [<ffffffff8125a340>] ? exofs_read_lookup_dev_table+0x480/0x480 > [ 329.919176] [<ffffffff81180e18>] mount_nodev+0x58/0xb0 > [ 329.919178] [<ffffffff812594ff>] exofs_mount+0x4f/0x80 > [ 329.919179] [<ffffffff81181e13>] mount_fs+0x43/0x1b0 > [ 329.919182] [<ffffffff8119b56a>] vfs_kern_mount+0x6a/0xf0 > [ 329.919183] [<ffffffff8119bd44>] do_kern_mount+0x54/0x110 > [ 329.919185] [<ffffffff8119d4b4>] do_mount+0x1a4/0x830 > [ 329.919188] [<ffffffff8115da33>] ? alloc_pages_current+0xa3/0x110 > [ 329.919191] [<ffffffff811229e4>] ? __get_free_pages+0x14/0x50 > [ 329.919193] [<ffffffff8119d18a>] ? copy_mount_options+0x3a/0x170 > [ 329.919194] [<ffffffff8119dc80>] sys_mount+0x90/0xe0 > [ 329.919199] [<ffffffff81605aa9>] system_call_fastpath+0x16/0x1b > [ 329.919200] Code: 66 90 41 8b 84 24 70 03 00 00 83 eb 01 39 c3 72 50 41 8b 94 24 74 03 00 00 01 c2 39 d3 73 42 89 da 29 c2 49 8b 84 24 88 03 00 00 <48> 8b 04 d0 48 8b 38 48 85 ff 74 0c 48 c7 00 00 00 00 00 e8 6f > [ 329.919214] RIP [<ffffffff81259799>] exofs_free_sbi+0x59/0xa0 > [ 329.919216] RSP <ffff88003c4e5bc8> > [ 329.919217] CR2: 0000000000000000 > [ 329.919220] ---[ end trace e5a3b1124e42d9e3 ]--- > > could you please do: []$ gdb fs/exofs/exofs.ko Inside gdb > list *(exofs_free_sbi+0x59) and also > list *(exofs_fill_super+0x440) > Is there any possibility to avoid these failure? > I've never had it lets try to resolve it. Could you enable CONFIG_EXOFS_DEBUG it's under: miscellaneous-filesystems/exofs in make xconfig Then re-run everything send me the output []$ ./do-osd stop []$ ls /dev/osd* <1> []$ ./do-osd []$ ls /dev/osd* []$ ./do-exofs format Send me the output of that []$ ./do-exofs start Send me the dmesg output of this stage, or if not too big the dmesg output of from before ./do-osd <1> > Just now i am using the 3.3.0 kernel from the linux-pnfs repository. > When compiling the Kernel, Did you enable CONFIG_PNFSD ? (That is the pNFSD Server Kernel Support) What platform are you using? Distro + ARCH ? This should be a good tree. Though usually I use an open-osd.org/linux-open-osd.git based tree. But I don't see much difference. Let me have a look if there is something grossly missing. > > Thanks in adavance > Sorry for your trouble I have neglected the public trees for a while. Let me see if I can push a more tested tree up on open-osd.org. > Cheers > Johannes > Thanks Boaz > -------- Original-Nachricht -------- >> Datum: Tue, 15 May 2012 12:48:08 +0300 >> Von: Boaz Harrosh <bharrosh@xxxxxxxxxxx> >> An: Johannes Schild <JSchild@xxxxxx> >> CC: linux-nfs@xxxxxxxxxxxxxxx, open-osd <osd-dev@xxxxxxxxxxxx> >> Betreff: Re: Questions about Exofs > >> On 05/15/2012 12:03 PM, Johannes Schild wrote: >> >>> Hi, >>> >>> i try to set up the object-based layout with pnfs. >>> I am using the OSC-OSD as target. It works well and i can login. >>> Trying the scripts "do-*" from git://git.open-osd.org/open-osd.git the >> do-osd script works for me. The do-exofs doesnt, here i have some question: >>> >>> 1. Is the UUID in the do-exofs script optional? >>> >> >> >> No it is not optional >> >>> 2. If no how can i get it for my device? >>> >> >> >> Exactly! the ./do-exofs format command will set this for you, as well as >> mkfs.exofs the >> FS for you. >> >>> 3. It is mandatory to use raid-driver (raid456) in the script? Why? >>> >> >> >> What? where? Rrrr you are right. this is a very old tree. Let me see >> if I have something newer to push. It should all load automatically now. >> >> But yes the dependency on raid456.ko is built in. Though if you use >> raid=0 on the format command line it will not be used in run time. >> >>> >>> The error is: >>> mount -t exofs -o >> osdname=d2683732-c906-4ee1-9dbd-c10c27bb40df,pid=0x10000,_netdev /dev/osd0 /mnt/osd0/ >>> mount: wrong fs type, bad option, bad superblock on /dev/osd0, >>> missing codepage or helper program, or other error >>> In some cases useful info is found in syslog - try >>> dmesg | tail or so >>> >>> dmesg says: >>> exofs: Unable to mount exofs on (null) pid=0x0 err=-22 >>> >> >> >> Probably you forgot the "./do-exofs format" stage. Please read the script >> before, you might need to edit it. It is the stage that calls mkfs.exofs >> to make a new filesystem for you. (An OSD is a raw device that can host >> many filesystems each in it's own osd-partition. >> >>> >>> Thanks for answering my questions. >> >> >>> Regards >>> Johannes >>> >> >> >> Cheers >> Boaz >> >> -- >> To unsubscribe from this list: send the line "unsubscribe linux-nfs" in >> the body of a message to majordomo@xxxxxxxxxxxxxxx >> More majordomo info at http://vger.kernel.org/majordomo-info.html > -- To unsubscribe from this list: send the line "unsubscribe linux-nfs" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
