Skip site navigation (1)Skip section navigation (2)
Date:      Thu, 3 Sep 2009 10:06:57 +0200
From:      "Robert Eckardt" <rol@robert-eckardt.de>
To:        Adrian Penisoara <ady@freebsd.ady.ro>
Cc:        hackers@freebsd.org
Subject:   Fw: Re: ZFS continuously growing
Message-ID:  <20090903080558.M13772@Robert-Eckardt.de>
In-Reply-To: <20090903071913.M84990@Robert-Eckardt.de>
References:  <20090902193059.M336@Robert-Eckardt.de> <78cb3d3f0909030009y505a30by769052258576bfeb@mail.gmail.com> <20090903071913.M84990@Robert-Eckardt.de>

next in thread | previous in thread | raw e-mail | index | archive | help
On Thu, 3 Sep 2009 09:09:19 +0200, Adrian Penisoara wrote
> Hi,
> 
> On Wed, Sep 2, 2009 at 10:22 PM, Robert Eckardt
> <Robert.Eckardt@robert-eckardt.de> wrote:
> > Do I have to be worried?
> > Is there a memory leak in the current ZFS implementation?
> > Why is used space growing slower than free space is shrinking?
> > Is there some garbage collection needed in ZFS?
> >
> > Besides, although the backup server has 3 GB RAM I had to tune arc_max
> > to 150MB to copy the backed-up data from an 2.8TB ZFS (v6) to the
> > 4.5 TB ZFS (v13) by "zfs send|zfs recv" without kmalloc panic.
> > (I.e., the defaults algorithm was not sufficient.)
> 
>  Do I take you are using ZFS snapshots in between rsync'ing 
> (send/recv requires snapshots) ? Could you please post the "zfs 
> list" output after subsequent runs to clarify ?
> 
> Regards,
> Adrian
> EnterpriseBSD

Hi Adrian,

no I'm not using snapshots. Just seperate directories, where identical 
files are hardlinked by rsync to the version one day older.
The send|recv was neccessary when I increased the raidz of the backup-fs.
(Copying everthing to two 1.5TB HDDs and after adding disks back again.
I used s.th. like "zfs send bigpool/big@backup | zfs recv big/big".)

Here the zfs list of the last five days:
Thu Sep  3 09:36:12 CEST 2009  (Today add. 2GB of data were transfered.)
big          1861882752          0 1861882752     0%        5 14545959    
0%   /big 
big/big      4676727168 2814844416 1861882752    60% 43137409 14545959   
75%   /big/big 
NAME      USED  AVAIL  REFER  MOUNTPOINT 
big      2.72T  1.73T  31.5K  /big 
big/big  2.72T  1.73T  2.62T  /big/big

Wed Sep  2 09:36:24 CEST 2009
big          1869058944        128 1869058816     0%        5 14602022    
0%   /big 
big/big      4679698688 2810639872 1869058816    60% 43226966 14602022   
75%   /big/big 
NAME      USED  AVAIL  REFER  MOUNTPOINT 
big      2.72T  1.74T  31.5K  /big 
big/big  2.72T  1.74T  2.62T  /big/big

Tue Sep  1 09:36:33 CEST 2009
big          1875352064          0 1875352064     0%        5 14651188    
0%   /big 
big/big      4683241856 2807889792 1875352064    60% 43316454 14651188   
75%   /big/big 
NAME      USED  AVAIL  REFER  MOUNTPOINT 
big      2.71T  1.75T  31.5K  /big 
big/big  2.71T  1.75T  2.62T  /big/big

Mon Aug 31 09:45:26 CEST 2009
big          1881967616        128 1881967488     0%        5 14702871    
0%   /big 
big/big      4686380928 2804413440 1881967488    60% 43406044 14702871   
75%   /big/big 
NAME      USED  AVAIL  REFER  MOUNTPOINT 
big      2.71T  1.75T  31.5K  /big 
big/big  2.71T  1.75T  2.61T  /big/big

Sun Aug 30 09:39:31 CEST 2009
big          1891064192          0 1891064192     0%        5 14773939    
0%   /big 
big/big      4694821376 2803757184 1891064192    60% 43496712 14773939   
75%   /big/big 
NAME      USED  AVAIL  REFER  MOUNTPOINT 
big      2.70T  1.76T  31.5K  /big 
big/big  2.70T  1.76T  2.61T  /big/big

Regards,
Robert

--
Dr. Robert Eckardt    ---    Robert.Eckardt@Robert-Eckardt.de



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