From owner-freebsd-current@FreeBSD.ORG Sat Oct 2 10:37:45 2004 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id E919216A4CE for ; Sat, 2 Oct 2004 10:37:45 +0000 (GMT) Received: from lara.cc.fer.hr (lara.cc.fer.hr [161.53.72.113]) by mx1.FreeBSD.org (Postfix) with ESMTP id 19C1343D46 for ; Sat, 2 Oct 2004 10:37:45 +0000 (GMT) (envelope-from ivoras@fer.hr) Received: from [127.0.0.1] (localhost.cc.fer.hr [127.0.0.1]) by lara.cc.fer.hr (8.13.1/8.13.1) with ESMTP id i92Ab0YY000725 for ; Sat, 2 Oct 2004 12:37:00 +0200 (CEST) (envelope-from ivoras@fer.hr) Message-ID: <415E84CC.5040502@fer.hr> Date: Sat, 02 Oct 2004 12:37:00 +0200 From: Ivan Voras User-Agent: Mozilla Thunderbird 0.7.3 (X11/20040923) X-Accept-Language: en-us, en MIME-Version: 1.0 To: current@freebsd.org Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Subject: GEOM/ggate or VFS problem? X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 02 Oct 2004 10:37:46 -0000 I've made a GEOM compression layer daemon for ggate (compresses data before storing to underlying file/media). It's still early version and unfinished, and it's available at: http://ivoras.sharanet.org/ggcomp.tgz I know it supports building (and using) an UFS[2] filesystem in it, I haven't tried others (It registers as a device with 8k sectors; it seems it's the maximum UFS can handle, although the compression would be more efficient with larger sector sizes). It's really good at making backups of /dev/zero :) Writing to the device "raw" (e.g. dd if=/dev/zero of=/dev/ggate0) seems to work fine. When I use it to host UFS2 filesystem, and do (relatively) large writes to it, both ggcomp and the writing process (e.g. dd) get stuck in the 'wdrain' state, and the system often cannot be recovered except by hard reboot (e.g. everything (console, network) is still active and responsive, CPU is not being hogged, but any fs writes get stuck). I've reproduced exactly the same problem with the stock ggatel utility (which is probably the simplest ggate class consumer there can be, and ggcomp is based on it), so this might be an important bug. Steps to reproduce: # dd if=/dev/zero of=/tmp/thingie bs=1m count=10 # ggatel create -v /tmp/thingie # newfs /dev/ggate0 # mount /dev/ggate0 /mnt # dd if=/dev/zero of=/mnt/blah bs=1m count=9 (repeat the last step until lockup; it takes less time with ggcomp) I can do this on an old kernel from a few months ago, and also a new BETA6 kernel. Any ideas?