This fix plus the fix for '6495013 Loops and recursion in metaslab_ff_alloc can kill performance, even on a pool with lots of free data' will greatly help your situation.
Both of these fixes will be in Solaris 10 update 4. Thanks, George ?ukasz wrote: > I have a huge problem with ZFS pool fragmentation. > I started investigating problem about 2 weeks ago > http://www.opensolaris.org/jive/thread.jspa?threadID=34423&tstart=0 > > I found workaround for now - changing recordsize - but I want better > solution. > The best solution would be a defragmentator tool, but I can see that it is > not easy. > > When ZFS pool is fragmented then: > 1. spa_sync function is executing very long ( > 5 seconds ) > 2. spa_sync thread often takes 100% CPU > 3. metaslab space map is very big > > There are some changes hidding the problem like this > http://bugs.opensolaris.org/bugdatabase/view_bug.do?bug_id=6512391 > and I hope there will be available in Solaris 10 update 4 > > But I suggest that: > 1. in sync phase when for the first time we did not found block we need > ( for example 128k ), pool schould remember this for some time ( 5 minutes ) > and stop asking for this kind of blocks. > > 2. We should be more careful with unloading space maps. > At the end of sync phase space maps for metaslabs without active flag are > unloaded. > On my fragmented pool spacemap with 800MB space available ( from 2GB ) > is unloaded because there was no 128K blocks. > > > This message posted from opensolaris.org > _______________________________________________ > zfs-discuss mailing list > zfs-discuss@opensolaris.org > http://mail.opensolaris.org/mailman/listinfo/zfs-discuss _______________________________________________ zfs-discuss mailing list zfs-discuss@opensolaris.org http://mail.opensolaris.org/mailman/listinfo/zfs-discuss
