Hi, On Wed, Sep 2, 2009 at 10:22 PM, Robert Eckardt <robert.ecka...@robert-eckardt.de> wrote: > > Hi folks, > > after upgrading my backup server to 8.0-BETA2, I noticed that the > available space shrinks from backup to backup (a tree each day with > differential rsync) although with each new tree the oldest tree gets > removed. > > Since I removed some subdirectories on my active server the number > of used inodes now is reduced by approx. 90000 on each run. > At the same time used space grows by between 650MB and 6.7GB and > free space gets reduced by 4.4 to 9GB (see table below). The output > of "df" and "zfs list" is consistent. > > Although I understand that the backed-up file by rsync can be much > larger than the data transferred I get worried that without changing > much the available space shrinks continuously. (Remember, the number > of backup trees stays constant since the oldest gets removed and > 6GB/d results in more that 1TB over half a year.) > > 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 _______________________________________________ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "freebsd-hackers-unsubscr...@freebsd.org"