From owner-freebsd-stable@FreeBSD.ORG Mon Mar 29 19:32:27 2004 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 172A916A4CE; Mon, 29 Mar 2004 19:32:27 -0800 (PST) Received: from mail.globo.com (smtp2.globo.com [200.208.9.169]) by mx1.FreeBSD.org (Postfix) with ESMTP id C93D443D39; Mon, 29 Mar 2004 19:32:26 -0800 (PST) (envelope-from jonny@jonny.eng.br) Received: from jonny.eng.br (200.217.93.206) by mail.globo.com (6.0.053) (authenticated as jcml21@globo.com) id 40628EA70004617D; Tue, 30 Mar 2004 00:32:25 -0300 Message-ID: <4068EA56.3060600@jonny.eng.br> Date: Tue, 30 Mar 2004 00:32:38 -0300 From: =?ISO-8859-1?Q?Jo=E3o_Carlos_Mendes_Lu=EDs?= User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.6) Gecko/20040113 X-Accept-Language: pt-br, en-us, en, pt MIME-Version: 1.0 To: hackers@freebsd.org, stable@freebsd.org Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Subject: Serious bug in vinum? X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 30 Mar 2004 03:32:27 -0000 Sorry for the cross-posting, but nor the Author nor freebsd-bugs did acknowledge my message, and I think this is a very serious bug in vinum, leading to loss of data... If these are not the correct foruns for this, please forgive me and tell me which is the correct one. PS: Please CC: me, since I'm not currently subscribed to these lists. ==================================================== Hi Greg, I've been a big fan of vinum since it's beggining. I use it for RAID0 and RAID1 solution for lots of servers. In some RAID0 (stripe) configurations, though, I've had some serious problems. If an underlying disk fails, the respective plex and volume do not fail, as they should. This leads to full corruption of data, but worst of that, leads to a system which believes the data is safe. In one ocasion, for example, the backup ran and overwrote good data with bad data, full of zeros. I am not fully aware of vinum programming details, but a quick look at 4.9-STABLE, in file vinumstate.c, dated Jul, 7, 2000, at line 588, function update_volume_state() sets volume state to up if plex state is corrupt or better for at least one plex: for (plexno = 0; plexno < vol->plexes; plexno++) { struct plex *plex = &PLEX[vol->plex[plexno]]; /* point to the plex */ if (plex->state >= plex_corrupt) { /* something accessible, */ vol->state = volume_up; break; } } I think this should be like: if (plex->state > plex_corrupt) { /* something accessible, */ Or, in other words, volume state is up only if plex state is degraded or better. I did not test this, since the situation is not easy to reproduce, but I think it depends only on the real meaning of the "corrupt" state. Thanks in advance for your attention, Jonny