You mean RHEL 5.3. I have (rh)el5.3 with udev-095-14.19.el5 and it is
working as expected. I don't see the problem you are referring to.
Nikola Ciprich wrote:
> Hi Sunil,
> well, I don't know exact version which started creating them,
> but latest centos (based on RHEL 5.4) uses version 95, which
Hi Sunil,
well, I don't know exact version which started creating them,
but latest centos (based on RHEL 5.4) uses version 95, which doesn't
create them for me.
Version 127 I used for tests already creates them correctly..
BR
nik
On Mon, Apr 06, 2009 at 12:08:34PM -0700, Sunil Mushran wrote:
> AFA
AFAIK, this is not an issue on (rh)el4/sles9. It could be that the
enterprise distros never shipped that older version of udev.
I could cross check. Do you know the version of udev that started
creating the /dev/dm-xx devices?
Nikola Ciprich wrote:
> OK, I've got it...
> the problem is, that moun
OK, I've got it...
the problem is, that mounted.ocfs2 scans devices appearing in /proc/partitions,
and only in directly under /dev
but I'm using device mapper based storage, andd older versions of udev do not
create all device mapper devices also in /dev/dm-XX, but only in
/dev/mapper/... which
Email me the ouput of:
$ mounted.ocfs2 -d
Also, does hb stop using uuid work?
$ ocfs2_hb_ctl -K -u o2cb
Lastly, what versions of the fs, tools, kernel?
On Apr 4, 2009, at 1:24 AM, Nikola Ciprich
wrote:
> Hi,
> it says:
> /sbin/ocfs2_hb_ctl
> on both nodes, which's correct - the binary is th
Hi,
it says:
/sbin/ocfs2_hb_ctl
on both nodes, which's correct - the binary is there...
n.
On Fri, Apr 03, 2009 at 02:27:34PM -0700, Sunil Mushran wrote:
> Do:
> $ cat /proc/sys/fs/ocfs2/nm/hb_ctl_path
>
>
> Nikola Ciprich wrote:
>> Hi Sunil,
>> thanks for reply..
>> I don't observe any segfaults.
Do:
$ cat /proc/sys/fs/ocfs2/nm/hb_ctl_path
Nikola Ciprich wrote:
> Hi Sunil,
> thanks for reply..
> I don't observe any segfaults...
> regarding info You want, as I wrote, umount doesn't decrease refcount...:
>
> [r...@vbox4 ~]# ocfs2_hb_ctl -I -d /dev/vgshared/lvs
> 2A5D351D0A934061BBC6B5392A30
Hi Sunil,
thanks for reply..
I don't observe any segfaults...
regarding info You want, as I wrote, umount doesn't decrease refcount...:
[r...@vbox4 ~]# ocfs2_hb_ctl -I -d /dev/vgshared/lvs
2A5D351D0A934061BBC6B5392A30187E: 1 refs
[r...@vbox4 ~]# umount /home/LVS
[r...@vbox4 ~]# ocfs2_hb_ctl -I -d
umount is supposed to stop the heartbeat. In bz1053, ocfs2_hb_ctl was
segfaulting.
Are you seeing any segfaults or any other errors during umount?
Also, run the following before and after umount:
$ ocfs2_hb_ctl -I -d /dev/sdX o2cb
Email me the output.
Nikola Ciprich wrote:
> Hello Tao,
> and th
Hello Tao,
and thanks a lot for reply!
It seems not to be the same bug, at least applying the patch didn't help.
stopping hb using -K parameter really helps, but why doesn't this work
automatically
on umount?
it always happens on the second node...
I don't see any error in logs, anything.
But the
Hi Nikola,
Nikola Ciprich wrote:
> Hi,
> I'm trying ocfs2 RHEL5 distro, 2.6.29 kernel, ocfstools-1.4.1. I'm using DRBD
> in primary/primary mode
> as shared storage...
>
> I've configured the service according to quickstart document, and everything
> works,
> but when I umount fs on both nodes,
Hi,
I'm trying ocfs2 RHEL5 distro, 2.6.29 kernel, ocfstools-1.4.1. I'm using DRBD
in primary/primary mode
as shared storage...
I've configured the service according to quickstart document, and everything
works,
but when I umount fs on both nodes, stopping o2cb service on one of the nodes
always
12 matches
Mail list logo