Skip site navigation (1)Skip section navigation (2)
Date:      Thu, 30 Sep 2004 20:40:23 -0300
From:      =?ISO-8859-1?Q?Jo=E3o_Carlos_Mendes_Lu=EDs?= <jonny@jonny.eng.br>
To:        Ivan Voras <ivoras@fer.hr>, hackers@freebsd.org
Subject:   Re: GEOM (ggate) compression consumer +problem
Message-ID:  <415C9967.3090309@jonny.eng.br>
In-Reply-To: <415BDFC2.1020304@fer.hr>
References:  <415BDFC2.1020304@fer.hr>

next in thread | previous in thread | raw e-mail | index | archive | help
Instead of block compression, wouldn't it be better (and maybe easier) 
to use file compresion, in a VFS layer (and a threaded daemon)?

A real useful VFS layer would have an option to compress only rarely 
used files.  And keep the real layer accessible, to allow dumping of 
compressed backend files.

Also, an option to encrypt the backend files could be useful. 
Encrypting after compressing is always better.

This is what I would like to see in a compressed file system.

Ivan Voras wrote:
> 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?
> 
> _______________________________________________
> freebsd-hackers@freebsd.org mailing list
> http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
> To unsubscribe, send any mail to "freebsd-hackers-unsubscribe@freebsd.org"


                                         Jonny

-- 
João Carlos Mendes Luís - Networking Engineer - jonny@jonny.eng.br



Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?415C9967.3090309>