From owner-freebsd-hackers@FreeBSD.ORG Thu Sep 30 10:29:09 2004 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id D851C16A4CE for ; Thu, 30 Sep 2004 10:29:09 +0000 (GMT) Received: from lara.cc.fer.hr (lara.cc.fer.hr [161.53.72.113]) by mx1.FreeBSD.org (Postfix) with ESMTP id 094C243D2D for ; Thu, 30 Sep 2004 10:29:07 +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 i8UASIZG068086 for ; Thu, 30 Sep 2004 12:28:19 +0200 (CEST) (envelope-from ivoras@fer.hr) Message-ID: <415BDFC2.1020304@fer.hr> Date: Thu, 30 Sep 2004 12:28:18 +0200 From: Ivan Voras User-Agent: Mozilla Thunderbird 0.7.3 (X11/20040923) X-Accept-Language: en-us, en MIME-Version: 1.0 To: hackers@freebsd.org Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Subject: GEOM (ggate) compression consumer +problem X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 30 Sep 2004 10:29:10 -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 (caveat: don't overflow it; e.g. storing 50MB from /dev/zero onto a device backed by a 10MB file is fine (with -c5 switch), but doing the same with /dev/random is not (risk of kernel panic)) 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 :) Now the problem: I currently only tested this on an old kernel (5.2-CURRENT from a few months ago), so this might be fixed in newer versions, but when I stress it with writing large files, the system 'hangs' with my process (ggcomp) in 'wdrain' state. I'm not doing anything extraordinary (except that compression takes time...) in it, so I don't think it's "my fault". Any ideas?