kern/181377: zfs recv causes an inconsistant pool

Christopher Harrison harrison at glsan.com
Sun Aug 18 15:40:03 UTC 2013


>Number:         181377
>Category:       kern
>Synopsis:       zfs recv causes an inconsistant pool
>Confidential:   no
>Severity:       non-critical
>Priority:       low
>Responsible:    freebsd-bugs
>State:          open
>Quarter:        
>Keywords:       
>Date-Required:
>Class:          sw-bug
>Submitter-Id:   current-users
>Arrival-Date:   Sun Aug 18 15:40:03 UTC 2013
>Closed-Date:
>Last-Modified:
>Originator:     Christopher Harrison
>Release:        9.2-RC2
>Organization:
>Environment:
>Description:
When receiving a large zfs send -R stream if the system is interrupted the system does not recover gracefully.   The zpool will end up in an inconsistent state and not zfs list, zpool import or zpool scrub.   The system will run out of available memory resources and "hang" killing all user land processes in the process.


This functionality is different from prior releases as the system would "normally" roll back the inconsistent dataset to a consistent state (all bent to a prior state which might have lost data).

I would be happy to provide core files

Attempts to roll back the zpool to a prior transaction fall too with a zdb core dump (zdb -F z, zdb -X z).   

On initial check/import/list of the inconsistent pool an error is generated:
Solaris: WARNING: can't open objset for z/Systems/volumes/images                 

digging into this using zdb -dddd  z/Systems/volumes/images    

The follow message occurs:
Could not open gls/Systems/volumes/images, error 16


>How-To-Repeat:
upgrade the zpool the to the latest version flags (or create a new zpool).   Have a system with a smaller amount of memory (I have 8GB).    Send a large zfs dataset (>100GB) to the newly created pool, after 50% complete pull the power or have a system interruption which causing the system to need to reboot.

After the reboot, the system come up in an inconsistent state and quickly becomes memory starved, thus crashing over and over again.   The system will consume memory without releasing any and will experience a memory starvation situation within 10min of issuing a zpool command on the inconsistent pool



>Fix:


>Release-Note:
>Audit-Trail:
>Unformatted:


More information about the freebsd-bugs mailing list