Corey Kovacs wrote:
My mistake, I'd assumed (yes I know the implications of that word)
that this was on an NFS mount point. the rsize attribute only pertains
to NFS mounted filesystems
-C
2009/2/4 Randy Brown <randy.brown@xxxxxxxx>:
I'm having trouble getting the file system to mount after adding the rsize
parameter. Here is my fstab entry:
/dev/vgdevl/shared /fs/shared gfs defaults 0 0
I changed it to:
/dev/vgdevl/shared /fs/shared gfs defaults,rsize=8192
0 0
and when I try to mount the file system I get:
[root@nfs2-cluster etc]# mount /fs/shared
/sbin/mount.gfs: error mounting /dev/mapper/vgdevl-shared on /fs/shared:
Invalid argument
Looking though the man pages, it appears that the rsize switch should work.
Any thoughts?
Thanks,
Randy
Randy Brown wrote:
Great. Thanks. I'll give that a shot. I just need to find umount and
mount that file system to see if it worked.
Randy
Corey Kovacs wrote:
I had a similar problem. Reducing my rsize back to 8k from 32k fixed it.
Problem root was the lock files in the .qt directory.
Regards,
Corey
On Feb 4, 2009, at 16:00, Randy Brown <randy.brown@xxxxxxxx> wrote:
We are seeing a very strange issue with KDE with all kernels later than
2.6.18-53.1.21 on our cluster nodes. When users attempt to log into the
machine using KDE, it never makes it to the KDE splash screen. The machine
just hangs on a solid blue screen. I can then restart the Xserver and login
using Gnome, and it logs in without any issues. Unfortunately, for us, KDE
is the standard desktop environment used by our development group. I can
reboot the the cluster to the 2.6.18-53.1.21 kernel and both KDE and Gnome
work as expected. Obviously, I'd prefer to be running the latest kernel. I
will gladly provide more info if needed. Any help or suggestions would be
greatly appreciated.
Randy
Info about our cluster:
It is a 2 node cluster running Centos 5 with up to date patches. I am
using the cluster as a NAS head to serve NFS mounts out to our network from
an iscsi SAN.
Current running kernel:
2.6.18-53.1.21.el5 (Running this kernel so KDE logins work)
Most current installed kernel:
2.6.18-92.1.22.el5
Cluster packages:
lvm2-cluster-2.02.32-4.el5
cman-2.0.84-2.el5_2.3
gfs2-utils-0.1.44-1.el5_2.1
rgmanager-2.0.38-2.el5_2.1
<randy_brown.vcf>
--
Linux-cluster mailing list
Linux-cluster@xxxxxxxxxx
https://www.redhat.com/mailman/listinfo/linux-cluster
--
Linux-cluster mailing list
Linux-cluster@xxxxxxxxxx
https://www.redhat.com/mailman/listinfo/linux-cluster
--
Linux-cluster mailing list
Linux-cluster@xxxxxxxxxx
https://www.redhat.com/mailman/listinfo/linux-cluster
--
Linux-cluster mailing list
Linux-cluster@xxxxxxxxxx
https://www.redhat.com/mailman/listinfo/linux-cluster
--
Linux-cluster mailing list
Linux-cluster@xxxxxxxxxx
https://www.redhat.com/mailman/listinfo/linux-cluster
Although your probably on the right track to the problem.
KDE has known problems with NFS, because NFS cannot guarantee that a
lock is granted. KDE requires that locks will to be granted on a user's
/home directory otherwise you will get exactly what you are experiencing
(KDE only get's through 3 of the 5 steps during logon, then hangs at a
blue screen).
Do a google search for "KDE on NFS" or something like that, and you'll
see that it's a fairly common problem.
The KDE developers themselves state that you should never use KDE when
your home directories are on NFS, but there are ways around it. Home
directories on NFS is fairly common in large linux/unix deployments.
If your experiencing this problem when your user home directories sit on
GFS I would investigate GFS locking first up. There's probably
something there that KDE disagrees with.
Regards,
Stewart
--
Linux-cluster mailing list
Linux-cluster@xxxxxxxxxx
https://www.redhat.com/mailman/listinfo/linux-cluster
