From owner-freebsd-geom@FreeBSD.ORG Tue May 13 07:56:21 2008 Return-Path: Delivered-To: freebsd-geom@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id BF2E2106566C; Tue, 13 May 2008 07:56:21 +0000 (UTC) (envelope-from avg@icyb.net.ua) Received: from hosted.kievnet.com (hosted.kievnet.com [193.138.144.10]) by mx1.freebsd.org (Postfix) with ESMTP id 77C358FC1F; Tue, 13 May 2008 07:56:21 +0000 (UTC) (envelope-from avg@icyb.net.ua) Received: from localhost ([127.0.0.1] helo=edge.pp.kiev.ua) by hosted.kievnet.com with esmtpa (Exim 4.62) (envelope-from ) id 1JvpMx-00074j-8w; Tue, 13 May 2008 10:56:19 +0300 Message-ID: <4829499B.6080007@icyb.net.ua> Date: Tue, 13 May 2008 10:56:11 +0300 From: Andriy Gapon User-Agent: Thunderbird 2.0.0.12 (X11/20080320) MIME-Version: 1.0 To: freebsd-geom@freebsd.org, freebsd-fs@freebsd.org Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Cc: Subject: handling of EGAIN from softdep_check_suspend (gjournal) X-BeenThere: freebsd-geom@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: GEOM-specific discussions and implementations List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 13 May 2008 07:56:21 -0000 As being reported from time to time, sometimes there is a following error message produced by gjournal activity: kernel: fsync: giving up on dirty kernel: 0xc32b8bb0: tag devfs, type VCHR kernel: usecount 1, writecount 0, refcount 50 mountedhere 0xc323d200 kernel: flags () kernel: v_object 0xc10499b0 ref 0 pages 451 kernel: lock type devfs: EXCL (count 1) by thread 0xc3208000 (pid 39) kernel: dev ad4s1e.journal kernel: GEOM_JOURNAL: Cannot suspend file system /export (error=35). errno 35 is EAGAIN/EWOULDBLOCK and it is returned from vfs_write_suspend on FFS. The only place where this return code is present in the whole FFS/UFS code is softdep_check_suspend. Comment in the function says the following (for non-softupdates case): /* * Reasons for needing more work before suspend: * - Dirty buffers on devvp. * - Secondary writes occurred after start of vnode sync loop */ I wonder what is recommended handling of this return code? Maybe we should try 'AGAIN' instead of just giving up immediately? -- Andriy Gapon