gluster-devel
[Top][All Lists]
Advanced

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

Re: [Gluster-devel] Bug Reports


From: Gordan Bobic
Subject: Re: [Gluster-devel] Bug Reports
Date: Mon, 09 Feb 2009 12:57:25 +0000
User-agent: Thunderbird 2.0.0.19 (X11/20090107)

Krishna Srinivas wrote:
On Sun, Feb 8, 2009 at 7:14 PM, Gordan Bobic <address@hidden> wrote:
Another one - "tail -f" doesn't appear to work correctly for logs on
GlusterFS. The logs themselves seem to be OK (not corrupted), but tail -f
doesn't seem to properly list them incrementally, the output ends up
corrupted (missing lines, line breaks, etc). This was observed in the case
where /var/log/glusterfs/glusterfs.log is on glusterfs (AFR). Not checked
whether syslog managed logs suffer the same problem.

http://zresearch.com/pipermail/gluster-users/20090113/001362.html

Is there a way to specify --disable-direct-io-mode in fstab?

My use-case is somewhat unusual, so I thought I'd report these since they
may not get tripped under "normal" use. This is against 2.0.0rc1.

Setup is a shared root on GlusterFS/AFR with only one node (2nd node not yet
built).

Something weird seems to happen with some uses of ncurses libraries and
headers. If I try to compile the kernel using "make menuconfig" while the
root FS (including ncurses libraries and headers) is on GlusterFS, it fails
complaining that it couldn't find the headers. The exact same system image
(same tar ball) expanded onto an ext3 file system doesn't exhibit this
problem. In both cases /usr/src/linux is on an NFS file system, so since
that is the same in both test cases, the problem seems to be connected to
the root FS. Unfortunately, I cannot seem to get the logs out of the root FS
mount since they are initially created on the initrd which gets deallocated
after booting. :(

A similar, but wider-ranging problem happens when installing nVidia drivers
from the nVidia supplied shell archives. It, too, fails to find curses and
falls back to text mode. But it also then fails to install properly. It
first complains about being unable to back up the files it is replacing,
then it complains that it couldn't install some of the files. The files it
places on the FS end up being badly corrupted and are not even identified as
elf libraries (including the kernel module it builds). This works fine on
the ext3 FS, and putting the said files into the tar ball and extracting
them onto the Gluster root that way, creates the files correctly.

Can you see if the above problem happens if the root FS is not
glusterfs but the sources being compiled are on glusterfs?

The kernel is in both case on NFS (the very same share mounted with the same parameters). So surely, this cannot be a factor?

Gordan




reply via email to

[Prev in Thread] Current Thread [Next in Thread]