Hello Erblichs,
Two years later... :)
It turned out to be a problem with metaslabs fragmentation.
Lowering recordsize to 8k helps slightly but still it's not fixed.
--
Best regards,
Robert Milkowskimailto:[EMAIL PROTECTED]
htt
> Same problem here (snv_60).
> Robert, did you find any solutions?
>
> gino
check this http://www.opensolaris.org/jive/thread.jspa?threadID=34423&tstart=0
Check spa_sync function time
remember to change POOL_NAME !
dtrace -q -n fbt::spa_sync:entry'/(char *)(((spa_t*)arg0)->spa_name) ==
"POOL_
Hello Victor,
Wednesday, June 27, 2007, 1:19:44 PM, you wrote:
VL> Gino wrote:
>> Same problem here (snv_60).
>> Robert, did you find any solutions?
VL> Couple of week ago I put together an implementation of space maps which
VL> completely eliminates loops and recursion from space map alloc
VL>
Robert Milkowski wrote:
If it happens again I'll try to get some more specific data - however
it depends on when it happens as during peak hours I'll probably just
destroy a snapshot to get it working.
If it happens again, it would be great if you could gather some data
before you destroy the
Matthew Ahrens wrote On 10/16/06 09:07,:
Robert Milkowski wrote:
Hello zfs-discuss,
S10U2+patches. ZFS pool of about 2TB in size. Each day snapshot is
created and 7 copies are kept. There's quota set for a file system
however there's always at least 50GB of free space in a file system
Robert Milkowski wrote:
Hello zfs-discuss,
S10U2+patches. ZFS pool of about 2TB in size. Each day snapshot is
created and 7 copies are kept. There's quota set for a file system
however there's always at least 50GB of free space in a file system
(and much more in a pool). ZFS file system
