Bug 181377 - [zfs] zfs recv causes an inconsistant pool
Summary: [zfs] zfs recv causes an inconsistant pool
Status: Closed FIXED
Alias: None
Product: Base System
Classification: Unclassified
Component: kern (show other bugs)
Version: Unspecified
Hardware: Any Any
: Normal Affects Only Me
Assignee: freebsd-bugs (Nobody)
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2013-08-18 16:40 UTC by harrison
Modified: 2024-12-17 06:33 UTC (History)
1 user (show)

See Also:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description harrison 2013-08-18 16:40:03 UTC
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
Comment 1 Mark Linimon freebsd_committer freebsd_triage 2013-08-19 02:12:15 UTC
Responsible Changed
From-To: freebsd-bugs->freebsd-fs

Over to maintainer(s).
Comment 2 Steven Hartland & 2013-08-19 09:21:36 UTC
You may well be hitting something thats already got a proposed
fix upstream:
http://cr.illumos.org/~webrev/csiden/illumos-3970/

Might want to give that a go and see if it fixes it for you.

    Regards
    Steve

================================================
This e.mail is private and confidential between Multiplay (UK) Ltd. and the person or entity to whom it is addressed. In the event of misdirection, the recipient is prohibited from using, copying, printing or otherwise disseminating it or any information contained in it. 

In the event of misdirection, illegible or incomplete transmission please telephone +44 845 868 1337
or return the E.mail to postmaster@multiplay.co.uk.
Comment 3 Eitan Adler freebsd_committer freebsd_triage 2017-12-31 07:58:53 UTC
For bugs matching the following criteria:

Status: In Progress Changed: (is less than) 2014-06-01

Reset to default assignee and clear in-progress tags.

Mail being skipped
Comment 4 Michael Dexter freebsd_triage 2024-12-17 06:33:06 UTC
Appears to be fixed. Please re-open if that is inaccurate.