Skip site navigation (1)Skip section navigation (2)
Date:      Thu, 17 Dec 2009 14:43:26 +0100
From:      Ivan Voras <ivoras@freebsd.org>
To:        freebsd-questions@freebsd.org
Subject:   Re: kernel: g_vfs_done error = 5 and initiate_write_inodeblock_ufs2: already started (panic)
Message-ID:  <hgdchq$6d3$1@ger.gmane.org>
In-Reply-To: <4B2A2DE1.6050908@ose.nl>
References:  <4B2A2DE1.6050908@ose.nl>

next in thread | previous in thread | raw e-mail | index | archive | help
Bas Smeelen wrote:
> Hi,
> 
> We have a FreeBSD 7.2 Release amd64 running at a customers site in a
> vmware esx 3.5 environment with a san.
> This server is sometimes throwing errors and sometimes panicing or
> locking up in ways I have not seen before.
> I would say this has something to do with a failing disk, but this is a
> virtual disk so I'm a little bit puzzled.
> I have suggested to the vmware administrator that this could be
> something within their environment, but they cannot find anything.
> 
> Has someone seen these errors before and maybe have a suggestion how to
> find out what the culprit is?
> 
> Dec  1 01:58:25 tnras166 kernel:
> g_vfs_done():da0s1e[WRITE(offset=4045619200, length=16384)]error = 5
> Dec  1 01:58:25 tnras166 kernel:
> g_vfs_done():da0s1e[WRITE(offset=6742622208, length=16384)]error = 5
> Dec  1 01:58:26 tnras166 kernel:
> g_vfs_done():da0s1f[WRITE(offset=15796846592, length=16384)]error = 5
> 
> 
> I have been running FreeBSD for a long time on real hardware and in
> vmware environments, but never encountered these type of errors before.
> There is no filesystem corruption after these messages or after the
> panic mentioned in the subject. This situation is now happening
> approximately once every six weeks.

I have a number of FreeBSD systems running under various versions of 
VMWare products (ESX, ESXi, Server) and can tell you that this is almost 
certainly a problem on the host side.

It can happen if the SAN is timeouting, for example if it's doing disk 
scrubbing too diligently, etc. or the FC connections are problematic. 
Try to get the vmware admin to look at the logs more closely both on the 
host and on other machines hosted on the same VMWare instance or the 
same SAN.

Btw. which SAN product is it?




Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?hgdchq$6d3$1>