I just took the latest version of OCFS2 code from Subversions today. I am using a Fedora Core 1 system with all updates applied. I am using a Firewire Maxtor drive to put it on. Currently only testing with one computer and one drive. I was able to build the OCFS2 and OCFS-TOOLS components with no problems. I copied the ocfs2.o module to my local /lib/modules... Directory. I ran: mkfs.ocfs -F -b 128 -L ocfs-test -m /ocfs /dev/sda1 (not sure why mkfs.ocfs wants to know where the partition will be mounted???) I ran: ocfstool and created my /etc/ocfs.conf I then ran: load_ocfs2 and it complained about ip_port_v2 missing. So I created an ip_port_v2 entry with a value of 7002. Re-ran: load_ocfs2 and the driver loaded. I then tried to mount the volume: mount -t ocfs /dev/sda1 /ocfs waited for awhile and it returned but no drive was mounted :( So I'm not sure what I did wrong. Any suggestions would be appreciated. John
On Thu, Jan 29, 2004 at 03:21:58PM -0800, Villalovos, John L wrote:> I just took the latest version of OCFS2 code from Subversions today. > > I am using a Fedora Core 1 system with all updates applied. > > I am using a Firewire Maxtor drive to put it on. Currently only testing > with one computer and one drive. > > I was able to build the OCFS2 and OCFS-TOOLS components with no > problems. > > I copied the ocfs2.o module to my local /lib/modules... Directory. > > I ran: > mkfs.ocfs -F -b 128 -L ocfs-test -m /ocfs /dev/sda1 > (not sure why mkfs.ocfs wants to know where the partition will > be mounted???) > > I ran: > ocfstool and created my /etc/ocfs.conf > > I then ran: > load_ocfs2 and it complained about ip_port_v2 missing. So I > created an ip_port_v2 entry with a value of 7002. > > Re-ran: > load_ocfs2 and the driver loaded. > > I then tried to mount the volume: > mount -t ocfs /dev/sda1 /ocfs > > waited for awhile and it returned but no drive was mounted :( > > So I'm not sure what I did wrong. > > Any suggestions would be appreciated.The filesystem type for OCFS2 is "ocfs2", not "ocfs". Not sure why it would take a long time with "ocfs" though.. Try with "ocfs2" and see what happens. -Manish
> > > > I then tried to mount the volume: > > mount -t ocfs /dev/sda1 /ocfs > > > > waited for awhile and it returned but no drive was mounted :( > > > > So I'm not sure what I did wrong. > > > > Any suggestions would be appreciated. > > The filesystem type for OCFS2 is "ocfs2", not "ocfs". Not > sure why it would > take a long time with "ocfs" though.. > > Try with "ocfs2" and see what happens.Sorry my mistake. I did it run it before with ocfs2. A did a spelling error in my previous message :( John
So I am playing with OCFS2 and this is what happens when I attempt to mount a parition: First load the driver: Feb 2 11:43:43 linuxjohn2 kernel: Oracle Cluster FileSystem 1.9.9-UNSTABLE Thu Jan 29 14:13:02 PST 2004 (build b806b510b69ae78da50b3aba40b3e052) Feb 2 11:43:43 linuxjohn2 kernel: ocfs2: hostname is linuxjohn2.co.intel.com I did a rescan-scsi-bus here: Feb 2 11:44:30 linuxjohn2 -- root[2835]: ROOT LOGIN ON tty2 Feb 2 11:44:49 linuxjohn2 kernel: scsi singledevice 0 0 1 0 Feb 2 11:44:49 linuxjohn2 kernel: scsi singledevice 0 0 2 0 Feb 2 11:44:49 linuxjohn2 kernel: scsi singledevice 0 0 3 0 Feb 2 11:44:49 linuxjohn2 kernel: scsi singledevice 0 0 4 0 Feb 2 11:44:49 linuxjohn2 kernel: scsi singledevice 0 0 5 0 Feb 2 11:44:49 linuxjohn2 kernel: scsi singledevice 0 0 6 0 Feb 2 11:44:49 linuxjohn2 kernel: scsi singledevice 0 0 7 0 Feb 2 11:44:49 linuxjohn2 kernel: scsi singledevice 1 0 0 0 Feb 2 11:44:49 linuxjohn2 kernel: blk: queue ccba4614, I/O limit 4095Mb (mask 0xffffffff) Feb 2 11:44:49 linuxjohn2 kernel: Vendor: Maxtor Model: OneTouch Rev: 0200 Feb 2 11:44:49 linuxjohn2 kernel: Type: Direct-Access ANSI SCSI revision: 06 Feb 2 11:44:49 linuxjohn2 kernel: blk: queue ccba4414, I/O limit 4095Mb (mask 0xffffffff) Feb 2 11:44:49 linuxjohn2 kernel: Attached scsi disk sda at scsi1, channel 0, id 0, lun 0 Feb 2 11:44:49 linuxjohn2 kernel: SCSI device sda: 398295040 512-byte hdwr sectors (203927 MB) Feb 2 11:44:49 linuxjohn2 kernel: sda: sda1 Feb 2 11:44:49 linuxjohn2 kernel: scsi singledevice 1 0 1 0 Feb 2 11:44:49 linuxjohn2 kernel: scsi singledevice 1 0 2 0 Feb 2 11:44:49 linuxjohn2 kernel: scsi singledevice 1 0 3 0 Feb 2 11:44:49 linuxjohn2 kernel: scsi singledevice 1 0 4 0 Feb 2 11:44:49 linuxjohn2 kernel: scsi singledevice 1 0 5 0 Feb 2 11:44:49 linuxjohn2 kernel: scsi singledevice 1 0 6 0 Feb 2 11:44:49 linuxjohn2 kernel: scsi singledevice 1 0 7 0 Here is where I did the: mount -t ocfs2 /dev/sda1 /ocfs/ Feb 2 11:45:02 linuxjohn2 kernel: ------------[ cut here ]------------ Feb 2 11:45:02 linuxjohn2 kernel: kernel BUG at hash.c:1321! Feb 2 11:45:02 linuxjohn2 kernel: invalid operand: 0000 Feb 2 11:45:02 linuxjohn2 kernel: sd_mod ocfs2 parport_pc lp parport autofs 3c59x floppy sg sr_mod microcode sbp2 ide-scsi scsi_mod ide-cd cdrom ohci1394 ieee1394 keybdev mousedev hid input us Feb 2 11:45:02 linuxjohn2 kernel: CPU: 0 Feb 2 11:45:02 linuxjohn2 kernel: EIP: 0060:[<d097fd8b>] Not tainted Feb 2 11:45:02 linuxjohn2 kernel: EFLAGS: 00010292 Feb 2 11:45:02 linuxjohn2 kernel: Feb 2 11:45:02 linuxjohn2 kernel: EIP is at __ocfs_inode_hash_lookup [ocfs2] 0x1b (2.4.22-1.2149.nptl) Feb 2 11:45:02 linuxjohn2 kernel: eax: 0024e000 ebx: 00000000 ecx: c9bd0000 edx: 00000000 Feb 2 11:45:02 linuxjohn2 kernel: esi: ca323a34 edi: 0024e000 ebp: 00000000 esp: c9b4dd08 Feb 2 11:45:02 linuxjohn2 kernel: ds: 0068 es: 0068 ss: 0068 Feb 2 11:45:02 linuxjohn2 kernel: Process mount (pid: 3318, stackpage=c9b4d000) Feb 2 11:45:02 linuxjohn2 kernel: Stack: ca2bae80 ca2b2380 00000000 00000000 00000000 00000000 ca323a34 d0980007 Feb 2 11:45:02 linuxjohn2 kernel: ca323a34 0024e000 00000000 c9bd0000 c9bd0000 00000000 00000000 00000000 Feb 2 11:45:02 linuxjohn2 kernel: 0024e000 00000000 ca323008 00000000 00000000 ca323000 ca323008 d099b89b Feb 2 11:45:02 linuxjohn2 kernel: Call Trace: [<d0980007>] ocfs_inode_hash_insert [ocfs2] 0xc7 (0xc9b4dd24) Feb 2 11:45:02 linuxjohn2 kernel: [<d099b89b>] ocfs_create_root_oin [ocfs2] 0x2af (0xc9b4dd64) Feb 2 11:45:02 linuxjohn2 kernel: [<d09a1629>] ocfs_mount_volume [ocfs2] 0x4e9 (0xc9b4ddc4) Feb 2 11:45:02 linuxjohn2 kernel: [<d09a19b6>] ocfs_mount_volume [ocfs2] 0x876 (0xc9b4ddd4) Feb 2 11:45:02 linuxjohn2 kernel: [<d099fa7c>] ocfs_del_sem [ocfs2] 0xdc (0xc9b4de48) Feb 2 11:45:02 linuxjohn2 kernel: [<c0149ffd>] set_blocksize [kernel] 0xfd (0xc9b4de6c) Feb 2 11:45:02 linuxjohn2 kernel: [<d099fb90>] ocfs_read_super [ocfs2] 0xf4 (0xc9b4de84) Feb 2 11:45:02 linuxjohn2 kernel: [<c0149743>] get_sb_bdev [kernel] 0x1a3 (0xc9b4deb4) Feb 2 11:45:02 linuxjohn2 kernel: [<d09b73b0>] ocfs_fs_type [ocfs2] 0x0 (0xc9b4def8) Feb 2 11:45:02 linuxjohn2 kernel: [<c0149ab1>] do_kern_mount [kernel] 0x121 (0xc9b4df00) Feb 2 11:45:02 linuxjohn2 kernel: [<d09b73b0>] ocfs_fs_type [ocfs2] 0x0 (0xc9b4df04) Feb 2 11:45:02 linuxjohn2 kernel: [<c015d053>] do_add_mount [kernel] 0x93 (0xc9b4df24) Feb 2 11:45:02 linuxjohn2 kernel: [<c015d380>] do_mount [kernel] 0x160 (0xc9b4df44) Feb 2 11:45:02 linuxjohn2 kernel: [<c015d1c9>] copy_mount_options [kernel] 0x79 (0xc9b4df74) Feb 2 11:45:02 linuxjohn2 kernel: [<c015d7a1>] sys_mount [kernel] 0xb1 (0xc9b4df94) Feb 2 11:45:02 linuxjohn2 kernel: [<c0109747>] system_call [kernel] 0x33 (0xc9b4dfc0) Feb 2 11:45:02 linuxjohn2 kernel: Feb 2 11:45:02 linuxjohn2 kernel: Feb 2 11:45:02 linuxjohn2 kernel: Code: 0f 0b 29 05 6d ba 9a d0 8b 06 99 52 89 eb 50 c1 eb 09 89 f9 Thanks, John
Villalovos, John L
2004-Feb-02 17:17 UTC
[Ocfs2-devel] RE: [Ocfs2-users] RE: Playing with OCFS2
Enclosed please find a patch which fixes the issue I had. The root cause is that spin_trylock will always return 1 on a Uniprocessor (UP) system. It appears the code in this case had an assumption of a SMP system. The spin_trylock appears to be used as a debugging mechanism to make sure that a lock had been previously made before the function was called. My patch is just to use the #ifdef CONFIG_SMP but I think that this may go against the kernel guidelines but I am not sure. John -------------- next part -------------- A non-text attachment was scrubbed... Name: up-fix.diff Type: application/octet-stream Size: 565 bytes Desc: up-fix.diff Url : http://oss.oracle.com/pipermail/ocfs2-users/attachments/20040202/6edf6c6f/up-fix.obj
Ahh, good catch! I removed those lines of code as that check is not really needed (it's simple enough to follow). Thanks! --Mark On Mon, Feb 02, 2004 at 03:13:39PM -0800, Villalovos, John L wrote:> Enclosed please find a patch which fixes the issue I had. > > The root cause is that spin_trylock will always return 1 on a > Uniprocessor (UP) system. > > It appears the code in this case had an assumption of a SMP system. The > spin_trylock appears to be used as a debugging mechanism to make sure > that a lock had been previously made before the function was called. > > My patch is just to use the #ifdef CONFIG_SMP but I think that this may > go against the kernel guidelines but I am not sure. > > John> _______________________________________________ > Ocfs2-devel mailing list > Ocfs2-devel@oss.oracle.com > http://oss.oracle.com/mailman/listinfo/ocfs2-devel-- Mark Fasheh Software Developer, Oracle Corp mark.fasheh@oracle.com