From owner-freebsd-fs@FreeBSD.ORG Thu Dec 9 15:42:09 2010 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 26BE71065674 for ; Thu, 9 Dec 2010 15:42:09 +0000 (UTC) (envelope-from l.pizzamiglio@bally-wulff.de) Received: from mail2.bally-wulff-berlin.de (mail2.bally-wulff-berlin.de [212.144.118.9]) by mx1.freebsd.org (Postfix) with ESMTP id A746A8FC1A for ; Thu, 9 Dec 2010 15:42:08 +0000 (UTC) Received: from bwex.bally-wulff.de (unknown [192.9.204.106]) by mail2.bally-wulff-berlin.de (Postfix) with ESMTP id 6FF469907F for ; Thu, 9 Dec 2010 16:19:21 +0100 (CET) Received: from [192.9.205.177] ([192.9.205.177]) by bwex.bally-wulff.de with Microsoft SMTPSVC(6.0.3790.4675); Thu, 9 Dec 2010 16:19:21 +0100 Message-ID: <4D00F369.90004@bally-wulff.de> Date: Thu, 09 Dec 2010 16:19:05 +0100 From: Luca Pizzamiglio User-Agent: Mozilla/5.0 (X11; U; FreeBSD i386; en-US; rv:1.9.2.12) Gecko/20101029 Thunderbird/3.1.6 MIME-Version: 1.0 To: freebsd-fs@freebsd.org Content-Type: multipart/mixed; boundary="------------010503030304070507020702" X-OriginalArrivalTime: 09 Dec 2010 15:19:22.0051 (UTC) FILETIME=[74D98130:01CB97B4] Subject: Softupdate on UFS and "sometimes" slow flash disk X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 09 Dec 2010 15:42:09 -0000 This is a multi-part message in MIME format. --------------010503030304070507020702 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Hi list, I'm writing here, hoping this is the right list. We're using a PC with a Flash PATA module (4GB, non properly a SSD). The disk is 2.8 GB used (more or less) and the root partition is around 3.8 GB. During the update/restore procedure (based on restore(8)) I encountered a "disk full message" when the procedure is around 1 GB. After this message, the procedure continues without any other problem. At the end, disk has, as usual, 1 GB available space. I investigate deeply the problem and I monitored the softdep_request_cleanup() function that frees pending blocks. In one case of my scenario it return without freeing nothing, but there are a lot of free pending blocks. After further analysis I discovered that my flash module sometimes is dramatically slow (I don't know what the controller is doing...). softdep_request_cleanup() implements a time control system. Before to free blocks, it invokes ffs_update() in a blocking manner. On my "sometimes" slow flash module this ffs_update() takes more than 2 seconds and softdep_request_cleanup() return without freeing. Other invocations are not so slow and everything is fine. I know that probably there is some problem inside my flash module, but I guess that the initialization of the time control mechanism should be made after the ffs_update(). I propose here a patch, that should correct that behavior. Best regards Luca Pizzamiglio --------------010503030304070507020702 Content-Type: text/plain; name="ffs_softdep.c.patch" Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename="ffs_softdep.c.patch" Index: ffs_softdep.c =================================================================== --- ffs_softdep.c (revision 3162) +++ ffs_softdep.c (working copy) @@ -5796,7 +5796,6 @@ ump = VTOI(vp)->i_ump; mtx_assert(UFS_MTX(ump), MA_OWNED); needed = fs->fs_cstotal.cs_nbfree + fs->fs_contigsumsize; - starttime = time_second + tickdelay; /* * If we are being called because of a process doing a * copy-on-write, then it is not safe to update the vnode @@ -5809,6 +5808,7 @@ if (error != 0) return (0); } + starttime = time_second + tickdelay; while (fs->fs_pendingblocks > 0 && fs->fs_cstotal.cs_nbfree <= needed) { if (time_second > starttime) return (0); --------------010503030304070507020702--