From owner-svn-src-head@FreeBSD.ORG Fri May 1 08:32:07 2009 Return-Path: Delivered-To: svn-src-head@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 411561065675; Fri, 1 May 2009 08:32:07 +0000 (UTC) (envelope-from mav@FreeBSD.org) Received: from cmail.optima.ua (cmail.optima.ua [195.248.191.121]) by mx1.freebsd.org (Postfix) with ESMTP id 545CC8FC19; Fri, 1 May 2009 08:32:05 +0000 (UTC) (envelope-from mav@FreeBSD.org) X-Spam-Flag: SKIP X-Spam-Yversion: Spamooborona-2.1.0 Received: from [212.86.226.226] (account mav@alkar.net HELO mavbook.mavhome.dp.ua) by cmail.optima.ua (CommuniGate Pro SMTP 5.2.9) with ESMTPSA id 241749955; Fri, 01 May 2009 11:32:05 +0300 Message-ID: <49FAB383.2010904@FreeBSD.org> Date: Fri, 01 May 2009 11:32:03 +0300 From: Alexander Motin User-Agent: Thunderbird 2.0.0.21 (X11/20090405) MIME-Version: 1.0 To: Poul-Henning Kamp References: <48416.1241165732@critter.freebsd.dk> In-Reply-To: <48416.1241165732@critter.freebsd.dk> Content-Type: text/plain; charset=KOI8-R; format=flowed Content-Transfer-Encoding: 7bit Cc: svn-src-head@FreeBSD.org, svn-src-all@FreeBSD.org, src-committers@FreeBSD.org Subject: Re: svn commit: r191717 - head/sys/dev/ata X-BeenThere: svn-src-head@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: SVN commit messages for the src tree for head/-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 01 May 2009 08:32:08 -0000 Poul-Henning Kamp wrote: > In message <200905010803.n4183kGE036016@svn.freebsd.org>, Alexander Motin write > s: > >> - Drop pre-dump requests queue on dumping. ATA code, working in dumping >> (interruptless) mode, unable to handle long request queue. Actually, to get >> coherent dump we anyway should do as few unrelated actions as possible. > > It seems a wrong tradeoff to me, to favour dump fidelity over filesystem > coherence. When dump is disabled, queued requests are trashed anyway. Dump does not make the things worse then they are. It just does it's duty as good as possible and as simple as possible. There is no any warranty that completing all queued requests will make filesystem more coherent, it easily can happen opposite. Also, as soon as current system state is known to be invalid (as kernel has just panicked), it could be safer do not try to make any excessive movements. -- Alexander Motin