Date: Wed, 11 Jun 2008 04:40:19 +0400 From: Dmitry Marakasov <amdmi3@amdmi3.ru> To: freebsd-fs@freebsd.org Subject: ZFS, async-like per-filesystem option Message-ID: <20080611004019.GA1119@hades.panopticon>
next in thread | raw e-mail | index | archive | help
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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20080611004019.GA1119>