Re: ZFS panic space_map.c line 110

This panic indicates that the caller expected there to be free space
between start and  (start + size), but none was found. This could be a
locking bug or a space map corruption (depressing).

There really isn't enough context here for me to go on. If you can't
get a core, please at least provide us with a backtrace from ddb.

Thanks,
Kip


On Thu, May 7, 2009 at 12:05 PM, Martin <nakal_at_web.de> wrote:
>
> Hi,
>
> I have a file server running ZFS on -CURRENT. Someone has tried to
> transfer a file with several gigabytes onto the system. The kernel
> crashed with a panic and freezed up during spewing the panic. I've only
> written down the most important messages:
>
> solaris assert ss==NULL
> zfs/space_map.c line 110
>
> process: 160 spa_zio
>
> I've heard that I can try to move the zpool cache away and import the
> zpool with force once again. Will this help? I am asking because I
> don't know if the panic is caused by a corrupt cache or corrupt
> file system metadata. Maybe someone can explain it. (I had to switch the
> server off very ungently and the underlying RAID is rebuilding, so I
> can try it out later.)
>
> Is this issue with inconsistent zpools well known? I've seen some posts
> from 2007 and January 2009 that reported similar problems. Apparently
> some people have lost their entire zpools multiple times already, as
> far as I understood it.
>
> One more piece of information I can give is that every hour the ZFS file
> systems create snapshots. Maybe it triggered some inconsistency between
> the writes to a file system and the snapshot, I cannot tell, because I
> don't understand the condition.
>
> --
> Martin
> _______________________________________________
> freebsd-current_at_freebsd.org mailing list
> http://lists.freebsd.org/mailman/listinfo/freebsd-current
> To unsubscribe, send any mail to "freebsd-current-unsubscribe_at_freebsd.org"
>



-- 
All that is necessary for the triumph of evil is that good men do nothing.
    Edmund Burke