NFS Server running 2.6.0-test2

NFS Server running 2.6.0-test2

[Robert L. Harris]

[-- Attachment #1: Type: text/plain, Size: 1063 bytes --]



Just converted my nfs server to 2.6.0-test2 last night.  This morning I
found this on my console:

{0}:/>
Message from syslogd@camel at Tue Jul 29 00:02:30 2003 ...
camel kernel: journal commit I/O error


{0}:/>mount
.
.
/dev/md/0 on /mnt/data1 type ext3 (rw)

{0}:/>find /mnt/data1/backups/www/tarballs -name www-\*tgz -mtime +7 -exec rm {} \;
rm: cannot remove `/mnt/data1/backups/www/tarballs/www-20030721.tgz':
Read-only file system

{0}:/>mount -o remount,rw /dev/md0
mount: block device /dev/md/0 is write-protected, mounting read-only


I have NFS Version 3 enabled but TCP disabled (was very laggy).


Robert

:wq!
---------------------------------------------------------------------------
Robert L. Harris                     | GPG Key ID: E344DA3B
                                         @ x-hkp://pgp.mit.edu 
DISCLAIMER:
      These are MY OPINIONS ALONE.  I speak for no-one else.

Diagnosis: witzelsucht  	

IPv6 = robert@ipv6.rdlg.net	http://ipv6.rdlg.net
IPv4 = robert@mail.rdlg.net	http://www.rdlg.net

[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]

Re: NFS Server running 2.6.0-test2

[Neil Brown]

On Tuesday July 29, Robert.L.Harris@rdlg.net wrote:
> 
> 
> Just converted my nfs server to 2.6.0-test2 last night.  This morning I
> found this on my console:
> 
> {0}:/>
> Message from syslogd@camel at Tue Jul 29 00:02:30 2003 ...
> camel kernel: journal commit I/O error
> 

I'm guessing that the filesystem got an I/O error when writing to the
device.
Anything in the kernel log that might confirm or deny this?

NeilBrown

Re: NFS Server running 2.6.0-test2

[Robert L. Harris]

[-- Attachment #1: Type: text/plain, Size: 1460 bytes --]



The messages file is completely empty of any error messages related to
anything disk or filesystem related from about 6 hours prior to the
error up until the time I rebooted.  In addition the actual device
(RAID5 filesystem) is intact.

Robert



Thus spake Neil Brown (neilb@cse.unsw.edu.au):

> On Tuesday July 29, Robert.L.Harris@rdlg.net wrote:
> > 
> > 
> > Just converted my nfs server to 2.6.0-test2 last night.  This morning I
> > found this on my console:
> > 
> > {0}:/>
> > Message from syslogd@camel at Tue Jul 29 00:02:30 2003 ...
> > camel kernel: journal commit I/O error
> > 
> 
> I'm guessing that the filesystem got an I/O error when writing to the
> device.
> Anything in the kernel log that might confirm or deny this?
> 
> NeilBrown
> -
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at  http://www.tux.org/lkml/

:wq!
---------------------------------------------------------------------------
Robert L. Harris                     | GPG Key ID: E344DA3B
                                         @ x-hkp://pgp.mit.edu 
DISCLAIMER:
      These are MY OPINIONS ALONE.  I speak for no-one else.

Diagnosis: witzelsucht  	

IPv6 = robert@ipv6.rdlg.net	http://ipv6.rdlg.net
IPv4 = robert@mail.rdlg.net	http://www.rdlg.net

[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]

Re: NFS Server running 2.6.0-test2

[Neil Brown]

On Tuesday July 29, Robert.L.Harris@rdlg.net wrote:
> 
> 
> The messages file is completely empty of any error messages related to
> anything disk or filesystem related from about 6 hours prior to the
> error up until the time I rebooted.  In addition the actual device
> (RAID5 filesystem) is intact.
> 

Well, it looks quite unplesant then.
That error message can only get printed if the JFS_ABORT flag is set
for the ext3 journal, and whenever JFS_ABORT is set, the message:
   Aborting journal on device ...
comes first.  If you don't have that message, then the impossible has
happened.

The impossible is usually caused either by bad memory (and a
single-bit-error in memory could have caused this probem), or by some
stray pointer corrupting something.

So, I would suggest memtest86 if that is convenient, followed by
reporting the problem to the ext3 developers (see the MAINAINERS
file). 

This problem is unlikely to be related to the machine being an NFS
server, though until we know the cause, nothing should be ruled out.

NeilBrown