Project

General

Profile

Bug #7200

no blocks must be born in a txg after a snapshot is created

Added by Andriy Gapon about 3 years ago. Updated almost 3 years ago.

Status:
Closed
Priority:
High
Assignee:
-
Category:
zfs - Zettabyte File System
Start date:
2016-07-20
Due date:
% Done:

100%

Estimated time:
Difficulty:
Medium
Tags:
needs-triage

Description

No new blocks must be born in a dataset in the same TXG after a snapshot of the dataset is taken.
Those blocks would have the same blk_birth as the dataset's ds_prev_snap_txg and as such they would be presumed to belong o the snapshot while in fact they do not.
All the datasets must be clean before sync tasks are run, so the described scenario may happen only if one of the sync tasks dirties the dataset and another sync task takes its snapshot.
Then, there will be another sync pass because of the dirty data and the new blocks will be born in the same TXG when the data is written out.

It seems that almost all of the existing sync tasks modify only MOS and do not dirty any objsets.
The only exception that I've been able to identify so far is the rollback which can modify an objset when it zeroes out the objset's ZIL.


Related issues

Related to illumos gate - Feature #7197: ztest should test rollbackNew2016-07-20

Actions
Related to illumos gate - Bug #7199: dsl_dataset_rollback_sync may try to free already free blocksClosed2016-07-20

Actions

History

#1

Updated by Andriy Gapon about 3 years ago

#2

Updated by Andriy Gapon about 3 years ago

Another problematic scenario is a rollback synctask followed by a destroy synctask in the same txg,
The former would put the dataset on the dirty list, the latter would destroy the dataset.
The second sync pass will try to sync out the dirty+destroyed dataset and that would lead to a panic.

#3

Updated by Andriy Gapon almost 3 years ago

Perhaps, the destroy operation should remove the dataset from the dirty list?
Alternatively, we could try to isolate any rollback operation into its own txg the same way we disallow two snapshots (of the same dataset) to be created in the same txg.

Yet another possibility is to try to immediately sync the rolled back dataset after clearing its ZIL header.
Don't know how feasible this is to do, but if we could do it and avoid leaving a dirty dataset behind, then, in my opinion, we could kill several birds with one stone.

#4

Updated by Andriy Gapon almost 3 years ago

Something like the following, not even compile tested.

--- uts/common/fs/zfs/dsl_dataset.c
+++ uts/common/fs/zfs/dsl_dataset.c
@@ -881,10 +881,13 @@ static void
 dsl_dataset_zero_zil(dsl_dataset_t *ds, dmu_tx_t *tx)
 {
     objset_t *os;
+    zio_t *zio;

     VERIFY0(dmu_objset_from_ds(ds, &os));
     bzero(&os->os_zil_header, sizeof (os->os_zil_header));
-    dsl_dataset_dirty(ds, tx);
+    zio = zio_root(dp->dp_spa, NULL, NULL, ZIO_FLAG_MUSTSUCCEED)
+    dsl_dataset_sync(ds, zio, tx);
+    VERIFY0(zio_wait(zio));
 }

 uint64_t
#5

Updated by Andriy Gapon almost 3 years ago

  • Related to Bug #7199: dsl_dataset_rollback_sync may try to free already free blocks added
#6

Updated by Matthew Ahrens almost 3 years ago

  • Subject changed from no blocks must be born in a txg after a snaphot is created to no blocks must be born in a txg after a snaphot is created
#7

Updated by Marcel Telka almost 3 years ago

  • Subject changed from no blocks must be born in a txg after a snaphot is created to no blocks must be born in a txg after a snapshot is created
#8

Updated by Electric Monk almost 3 years ago

  • Status changed from New to Closed
  • % Done changed from 0 to 100

git commit bfaed0b91e57062c38bc16b4f89db3c8f0052a9b

commit  bfaed0b91e57062c38bc16b4f89db3c8f0052a9b
Author: Andriy Gapon <andriy.gapon@clusterhq.com>
Date:   2016-11-22T00:10:08.000Z

    7199 dsl_dataset_rollback_sync may try to free already free blocks
    7200 no blocks must be born in a txg after a snaphot is created
    Reviewed by: Matthew Ahrens <mahrens@delphix.com>
    Reviewed by: Brad Lewis <brad.lewis@delphix.com>
    Approved by: Gordon Ross <gordon.w.ross@gmail.com>

Also available in: Atom PDF