From owner-freebsd-fs@FreeBSD.ORG Wed Jun 11 01:31:27 2008 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 02971106568C for ; Wed, 11 Jun 2008 01:31:27 +0000 (UTC) (envelope-from amdmi3@amdmi3.ru) Received: from cp65.agava.net (cp65.agava.net [89.108.66.215]) by mx1.freebsd.org (Postfix) with ESMTP id AD6258FC7C for ; Wed, 11 Jun 2008 01:31:26 +0000 (UTC) (envelope-from amdmi3@amdmi3.ru) Received: from [213.148.20.85] (helo=hive.panopticon) by cp65.agava.net with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.63 (FreeBSD)) (envelope-from ) id 1K6EUX-0003bP-SI for freebsd-fs@freebsd.org; Wed, 11 Jun 2008 04:47:09 +0400 Received: from hades.panopticon (hades.panopticon [192.168.0.32]) by hive.panopticon (Postfix) with ESMTP id 3ADF27AB4 for ; Wed, 11 Jun 2008 04:40:46 +0400 (MSD) Received: by hades.panopticon (Postfix, from userid 1000) id B63621702D; Wed, 11 Jun 2008 04:40:19 +0400 (MSD) Date: Wed, 11 Jun 2008 04:40:19 +0400 From: Dmitry Marakasov To: freebsd-fs@freebsd.org Message-ID: <20080611004019.GA1119@hades.panopticon> MIME-Version: 1.0 Content-Type: text/plain; charset=koi8-r Content-Disposition: inline User-Agent: Mutt/1.5.18 (2008-05-17) X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - cp65.agava.net X-AntiAbuse: Original Domain - freebsd.org X-AntiAbuse: Originator/Caller UID/GID - [0 0] / [26 6] X-AntiAbuse: Sender Address Domain - amdmi3.ru X-Source: X-Source-Args: X-Source-Dir: Subject: ZFS, async-like per-filesystem option 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: Wed, 11 Jun 2008 01:31:27 -0000 Hi! There are cases when you don't care about safeness and integrity of your files at all, but still you need to store them on hdd. The example is massive ports building: I use WRKDIRPREFIX=/usr/work so all workdirs reside in the same place, and I absolutely don't care if I lose the whole directory on blackout. Still I can't use md(4) or tmpfs for it, as those are limited by memory+swap sizes, and, having 2Gb mem + 2Gb swap I'm likely to run out of space. Using ZFS for /usr/work makes my disks make horrible noise during build, and I can also guess that performance drops significantly because processes are likely to wait more time to read from disk, thus 2 CPU cures are not 100% loaded most time with 3 parallel builds. As ZFS heavily uses caching, I thought that it may be ideal solution if it had something like `async' (or more corretly, `nosync') property for filesysems. Turning it on will make specific filesystem completely ignore fsync() calls, so files will stay in memory until they are pushed out of cache by newer/more recently used/more frequently used data. That should reduce disk load, increase performance and free me from thinking how much size I need for md(4). So, my questions are: - Is something like that planned or already implemented upstream? - How hard would it be to implement it? The easy way seems to make zfs_freebsd_fsync() no-op, but I'm not sure of side-effects. The correct way I guess is to bypass ZIL conditionally. -- Dmitry A. Marakasov | jabber: amdmi3@jabber.ru amdmi3@amdmi3.ru | http://www.amdmi3.ru