From owner-svn-src-projects@FreeBSD.ORG Tue May 8 14:14:21 2012 Return-Path: Delivered-To: svn-src-projects@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 8C1DA1065673; Tue, 8 May 2012 14:14:21 +0000 (UTC) (envelope-from gber@freebsd.org) Received: from smtp.semihalf.com (smtp.semihalf.com [213.17.239.109]) by mx1.freebsd.org (Postfix) with ESMTP id 34BC78FC1A; Tue, 8 May 2012 14:14:21 +0000 (UTC) Received: from localhost (unknown [213.17.239.109]) by smtp.semihalf.com (Postfix) with ESMTP id E1014119C5C; Tue, 8 May 2012 16:14:10 +0200 (CEST) X-Virus-Scanned: by amavisd-new at semihalf.com Received: from smtp.semihalf.com ([213.17.239.109]) by localhost (smtp.semihalf.com [213.17.239.109]) (amavisd-new, port 10024) with ESMTP id s1Ns8QuuTkre; Tue, 8 May 2012 16:14:10 +0200 (CEST) Received: from [10.0.0.93] (cardhu.semihalf.com [213.17.239.108]) by smtp.semihalf.com (Postfix) with ESMTPSA id 1A977119C38; Tue, 8 May 2012 16:14:10 +0200 (CEST) Message-ID: <4FA94609.3060306@freebsd.org> Date: Tue, 08 May 2012 18:12:57 +0200 From: Grzegorz Bernacki User-Agent: Mozilla/5.0 (X11; U; FreeBSD amd64; en-US; rv:1.9.2.24) Gecko/20120127 Thunderbird/3.1.16 MIME-Version: 1.0 To: Konstantin Belousov References: <201203170318.q2H3ITdI047893@svn.freebsd.org> <20120317085116.GC1340@garage.freebsd.pl> <20120317161050.GI75778@deviant.kiev.zoral.com.ua> <4FA8FFB9.7090002@freebsd.org> <20120508095631.GV2358@deviant.kiev.zoral.com.ua> In-Reply-To: <20120508095631.GV2358@deviant.kiev.zoral.com.ua> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: svn-src-projects@freebsd.org, src-committers@freebsd.org Subject: Re: svn commit: r233072 - projects/nand/sys/kern X-BeenThere: svn-src-projects@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "SVN commit messages for the src " projects" tree" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 08 May 2012 14:14:21 -0000 On 05/08/12 11:56, Konstantin Belousov wrote: > On Tue, May 08, 2012 at 01:12:57PM +0200, Grzegorz Bernacki wrote: >> On 03/17/12 17:10, Konstantin Belousov wrote: >>> On Sat, Mar 17, 2012 at 09:51:16AM +0100, Pawel Jakub Dawidek wrote: >>>> On Sat, Mar 17, 2012 at 03:18:29AM +0000, Grzegorz Bernacki wrote: >>>>> Author: gber >>>>> Date: Sat Mar 17 03:18:28 2012 >>>>> New Revision: 233072 >>>>> URL: http://svn.freebsd.org/changeset/base/233072 >>>>> >>>>> Log: >>>>> Add VFS changes necessary for NANDFS to work. >>>>> >>>>> Ignore B_MANAGED buffer by syncer and ignore signal when msleep as it >>>>> can cause file system inconsistency. >>>> >>>> I'd suggest running these changes through kib@. Especially >>>> vn_start_write() >>>> change below looks ugly, but maybe it is only temporary? >>> It is not only ugly (and object against it). >>> >>> If the change makes any difference for the filesystem, then I just argue >>> that the filesystem is broken. The vn_start_write() is done on the >>> VFS entry peripheral, long before filesystem code is hit. >>> >>> I did not looked at the managed changes, you would need to describe >>> what is wrong with current code and what is the purpose of the changes. >>> B_MANAGED came from xfs, it seems, or at least xfs is the only current >>> consumer of B_MANAGED buffers. >> >> Hi Kostik, >> >> Without our change in getblk() whenewer we allocate new block we get panic: >> >> panic: bremfree: buffer 0xffffff807bf86080 not on a queue. >> >> It is because blocks with B_MANAGED flag are not queued on any queue in >> brelse() function. Could you look at it and give us approval to merge >> this change into HEAD? > > Right, but this is in fact the only function of the B_MANAGED flag. > So the question is, what are you trying to accomplish. Hi Kostik, There are two separate issues. First is that if we have B_MANAGED flag it should not cause the panic when used, so in my opinion fix should go into HEAD regardless of NANDFS. Second thing is the reason of having B_MANAGED flag. We use it because we want to decide when and where to save buffers. Our FS is log filesystem and we write buffers every given amount of time or if number of dirty buffer exceed given threshold. We write buffers in large groups along with metadata related to this group, so we cannot afford writing single buffer. As a result we cannot allow buf deamon to write buffers in an ad hoc manner. I hope I answered your question. Please let me know if you have more concerns. If you have some ideas how we can avoid using B_MANAGED flags please let us know. thanks, grzesiek