From owner-freebsd-fs@FreeBSD.ORG Sun Nov 27 11:24:24 2011 Return-Path: Delivered-To: freebsd-fs@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id C6986106566C for ; Sun, 27 Nov 2011 11:24:24 +0000 (UTC) (envelope-from lev@FreeBSD.org) Received: from onlyone.friendlyhosting.spb.ru (onlyone.friendlyhosting.spb.ru [IPv6:2a01:4f8:131:60a2::2]) by mx1.freebsd.org (Postfix) with ESMTP id 639AC8FC14 for ; Sun, 27 Nov 2011 11:24:24 +0000 (UTC) Received: from lion.home.serebryakov.spb.ru (unknown [IPv6:2001:470:923f:1:5974:a369:b987:bc4d]) (Authenticated sender: lev@serebryakov.spb.ru) by onlyone.friendlyhosting.spb.ru (Postfix) with ESMTPA id 78B214AC1C; Sun, 27 Nov 2011 15:24:22 +0400 (MSK) Date: Sun, 27 Nov 2011 15:24:14 +0400 From: Lev Serebryakov Organization: FreeBSD Project X-Priority: 3 (Normal) Message-ID: <1381381670.20111127152414@serebryakov.spb.ru> To: Kostik Belousov In-Reply-To: <20111126084151.GH50300@deviant.kiev.zoral.com.ua> References: <20111123194444.GE50300@deviant.kiev.zoral.com.ua> <201111260725.pAQ7PDow056289@chez.mckusick.com> <20111126080351.GD50300@deviant.kiev.zoral.com.ua> <1961318852.20111126121354@serebryakov.spb.ru> <20111126084151.GH50300@deviant.kiev.zoral.com.ua> MIME-Version: 1.0 Content-Type: text/plain; charset=koi8-r Content-Transfer-Encoding: quoted-printable Cc: Kirk McKusick , freebsd-fs@freebsd.org Subject: Re: Does UFS2 send BIO_FLUSH to GEOM when update metadata (with softupdates)? X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: lev@FreeBSD.org List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 27 Nov 2011 11:24:24 -0000 Hello, Kostik. You wrote 26 =CE=CF=D1=C2=D2=D1 2011 =C7., 12:41:51: > on the operation end. In fact, there is inherited uglyness due to async > nature, namely, the kernel-owned buffer locks. Getting rid of them would > be much more useful then breaking UFS. Why do you name it breaking? How additional piece of meta-information cou= ld break UFS? > The non-broken driver must not return the 'completed' bio into the up > queue until write is sent to hardware and hardware reported the completio= n. So, hold bio without completion for, say, 5 minutes, will be Ok? > Raid controllers which aggressively cache the writes use nvram or > battery backups, and do not allow to turn on write cache if battery is > non-functional. I had not seen SU inconsistencies on RAID 6 on mfi(4), It is not always true. And it could be not true for network attached storage, as here is too many variables in equation in such case. Yes, good controller should do this, I could not agree more. But it is not always possible, unfortunately. > despite one our machine has unfortunate habit of dropping boot disk over > SATA channel each week, for 2 years. Great! But even battery-backed (read: UPS) software realization is not protected from OS crashes. So, it is impossible to implement software RAID5, which plays nicely with UFS (in case of crash -- until ehre is no crash, everyhting is perfect), now. Ok, you could say ``we don't need it at all,'' but I could not agree with this statement. Yes, I'm biased here. But, really, I see some interest to software RAID5 on FreeBSD now. > You again missed the point - if metadata is not reordable, but user > data is, you get security issues. They are similar (but inverse) to what > I described in the previous paragraph. In case of crash -- yes. But, IMHO, in case of crash here could be scenario when some information is leaked in any case. If here is no crash, you haven't security issues. Because every read will return actual information, either from write cache, or from plates. Inconsistent cache implementation is bad thing, for sure, but it is orthogonal question to what we discuss here. --=20 // Black Lion AKA Lev Serebryakov