[prev in list] [next in list] [prev in thread] [next in thread] 

List:       freebsd-fs
Subject:    Re: ZFS Recordsize tuning & transmission (bittorent daemon)
From:       Bob Friesenhahn <bfriesen () simple ! dallas ! tx ! us>
Date:       2010-05-19 14:53:54
Message-ID: alpine.GSO.2.01.1005190947480.12887 () freddy ! simplesystems ! org
[Download RAW message or body]

On Wed, 19 May 2010, Arnaud Houdelette wrote:
>
> ZFS recordsize on both pools are default (128k). But as transmission 
> bittorrent client has no write (nor read) cache, it could mean that data is 
> written is smaller chunks during download. Could this lead to data being 
> stored in many not-full records ? Does those unfull records would have to be 
> read as whole (128k) during the move, which would explain the above 
> difference on read/write ?

Zfs always writes full blocks.  If bittorrent updates just part of the 
blocks, then the whole block will be re-written to a new location via 
COW.  This causes file fragmentation.  The file fragmentation will be 
worse if the pool is very full.  There should be less fragmentation if 
the system has quite a lot of RAM for buffering the writes.  With a 
lot of RAM, zfs will write less often (waiting as long as 30 seconds).

If your filesystem is only used for bittorrent and if bittorrent 
always uses the same block size, then it may be useful to set the 
receiving filesystem to use the bittorrent block size.  If the 
bittorrent block size is variable, then this tuning is not possible.

Bob
-- 
Bob Friesenhahn
bfriesen@simple.dallas.tx.us, http://www.simplesystems.org/users/bfriesen/
GraphicsMagick Maintainer,    http://www.GraphicsMagick.org/
_______________________________________________
freebsd-fs@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-fs
To unsubscribe, send any mail to "freebsd-fs-unsubscribe@freebsd.org"
[prev in list] [next in list] [prev in thread] [next in thread]