Date: Thu, 8 Jul 2010 00:45:37 -0700 (PDT) From: Simun Mikecin <numisemis@yahoo.com> To: Andrew Snow <andrew@modulus.org> Cc: freebsd-fs@freebsd.org Subject: Re: Freebsd 8 Release /usr Die After host VMWARE Crash Message-ID: <688583.92527.qm@web112402.mail.gq1.yahoo.com> In-Reply-To: <4C3563A8.7060301@modulus.org> References: <AANLkTiknH3e0X5lu30azKWguKkgbH_-3pOLQKXinCDPs@mail.gmail.com> <AANLkTilN4EA6hYYRwbPggAdz6O6iPjA_5Em5SU8hXTlC@mail.gmail.com> <4C3563A8.7060301@modulus.org>
next in thread | previous in thread | raw e-mail | index | archive | help
----- Original Message ---- > From: Andrew Snow <andrew@modulus.org> > To: Diego Arias <dak.col@gmail.com>; freebsd-fs@freebsd.org > Sent: Thu, July 8, 2010 7:35:36 AM > Subject: Re: Freebsd 8 Release /usr Die After host VMWARE Crash > > This should never happen! I hardly know where to start... > > The possibilities I can think of are: > > 1. A bug in UFS2 filesystem handling code (it has to be considered) > 2. the blade suffered from undetected memory or CPU corruption > 3. A misconfiguration somewhere somehow disabled synchronous disk device > writes. Possibly in freebsd (did you mount it async?), possibly in the SAN >(doubtful unless you powered if off at the same time as the blades), possibly >in vmware (i dont know of any options in esx that let you do something as silly >as this). > 4. You were using VMFS thin provisioning and the volume ran out of space > 5. You were using VMFS extents and one or more LUNs vanished during the host >crashing > > Obviously all of these possibilities seem very unlikely.. but it would take >more precise knowledge of your setup to narrow it down. In the scheme of >things it seems a bit premature to blame FreeBSD but bugs do happen. > AFAIK virtual environments ignore disk sync requests by default. For example, in VirtualBox they are ignored by default, by you could enable it if you want (with a performance penalty). Haven't used VMWare, so not 100% sure about it, maybe someone more knowledgable with VMWare knows what it's defaults are. Described fsck errors are the same if you use a lying ATA drive (disk that reports that it has written data, but it has not) with UFS2+softupdates. Solution for a lying ATA drive is to use a filesystem that uses disk write cache flushing, like UFS2+gjournal or ZFS. I suppose UFS journaling would be ok, too, but haven't used it myself, so cannot comment on that. If VMWare does not honor disk write cache flushing then described solutions would not work on it.
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?688583.92527.qm>