Bug 138764 - [zfs] [panic] ZFS panic: "panic: dirtying snapshot!"
Summary: [zfs] [panic] ZFS panic: "panic: dirtying snapshot!"
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: Pawel Jakub Dawidek
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2009-09-12 17:30 UTC by Tim Bishop
Modified: 2009-11-14 14:30 UTC (History)
0 users

See Also:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Tim Bishop freebsd_committer freebsd_triage 2009-09-12 17:30:07 UTC
I'm running with a ZFS root file system using GPT partitioning and gptzfsboot. I then started using ZFS snapshots by using the sysutils/freebsd-snapshot port. This port basically just runs "zfs snapshot" and does some housekeeping.

The first snapshot went fine (when the machine was quiet). The second (when the machine was doing a portupgrade) caused a panic. All I have on the console is:

panic: dirtying snapshot

I traced this down to:

sys/cddl/contrib/opensolaris/uts/common/fs/zfs/dsl_dataset.c:1104

void
dsl_dataset_dirty(dsl_dataset_t *ds, dmu_tx_t *tx)
{
        dsl_pool_t *dp;

        if (ds == NULL) /* this is the meta-objset */
                return;

        ASSERT(ds->ds_user_ptr != NULL);

        if (ds->ds_phys->ds_next_snap_obj != 0)
                panic("dirtying snapshot!");

        dp = ds->ds_dir->dd_pool;

        if (txg_list_add(&dp->dp_dirty_datasets, ds, tx->tx_txg) == 0) {
                /* up the hold count until we can be written out */
                dmu_buf_add_ref(ds->ds_dbuf, ds);
        }
}

I'm not sure what this means though.

Sadly I have no debugging enabled and no crash dump.

How-To-Repeat: Hard to say. Run ZFS root and do snapshots when the machine is busy? I've only seen it once.
Comment 1 Gavin Atkinson freebsd_committer freebsd_triage 2009-09-12 19:06:58 UTC
Responsible Changed
From-To: freebsd-bugs->freebsd-fs

Over to maintainer(s)
Comment 2 Pawel Jakub Dawidek freebsd_committer freebsd_triage 2014-06-01 07:08:32 UTC
State Changed
From-To: open->suspended

At least backtrace is needed to start working on this problem. 
Suspend PR until backtrace is provided. 


Comment 3 Pawel Jakub Dawidek freebsd_committer freebsd_triage 2014-06-01 07:08:32 UTC
Responsible Changed
From-To: freebsd-fs->pjd

I'll take this one.
Comment 4 Pawel Jakub Dawidek freebsd_committer freebsd_triage 2014-06-01 07:08:32 UTC
State Changed
From-To: suspended->feedback

Could you verify if r198703 fixes your problem?
Comment 5 Pawel Jakub Dawidek freebsd_committer freebsd_triage 2014-06-01 07:08:32 UTC
State Changed
From-To: feedback->closed

r198703 should fix the problem.