zfs discuss - Jul 2007 - ZFS pool fragmentation

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

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 at opensolaris.org
> http://mail.opensolaris.org/mailman/listinfo/zfs-discuss