Date: Tue, 08 May 2012 18:12:57 +0200 From: Grzegorz Bernacki <gber@freebsd.org> To: Konstantin Belousov <kostikbel@gmail.com> Cc: svn-src-projects@freebsd.org, src-committers@freebsd.org Subject: Re: svn commit: r233072 - projects/nand/sys/kern Message-ID: <4FA94609.3060306@freebsd.org> In-Reply-To: <20120508095631.GV2358@deviant.kiev.zoral.com.ua> 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>
next in thread | previous in thread | raw e-mail | index | archive | help
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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?4FA94609.3060306>