diff options
author | Kent Overstreet <kent.overstreet@linux.dev> | 2025-06-08 02:16:12 +0300 |
---|---|---|
committer | Kent Overstreet <kent.overstreet@linux.dev> | 2025-06-17 02:03:52 +0300 |
commit | 17c3395e25f7db23fa5758c257a372d410d16cfd (patch) | |
tree | 793b58a1dce3f6491937a05645cad7bf5a14f290 /scripts/lib/kdoc/kdoc_output.py | |
parent | 191334400d8031df367eb74b6ab49bc163f6f821 (diff) | |
download | linux-17c3395e25f7db23fa5758c257a372d410d16cfd.tar.xz |
bcachefs: opts.journal_rewind
Add a mount option for rewinding the journal, bringing the entire
filesystem to where it was at a previous point in time.
This is for extreme disaster recovery scenarios - it's not intended as
an undelete operation.
The option takes a journal sequence number; the desired sequence number
can be determined with 'bcachefs list_journal'
Caveats:
- The 'journal_transaction_names' option must have been enabled (it's on
by default). The option controls emitting of extra debug info in the
journal, so we can see what individual transactions were doing;
It also enables journalling of keys being overwritten, which is what
we rely on here.
- A full fsck run will be automatically triggered since alloc info will
be inconsistent. Only leaf node updates to non-alloc btrees are
rewound, since rewinding interior btree updates isn't possible or
desirable.
- We can't do anything about data that was deleted and overwritten.
Lots of metadata updates after the point in time we're rewinding to
shouldn't cause a problem, since we segragate data and metadata
allocations (this is in order to make repair by btree node scan
practical on larger filesystems; there's a small 64-bit per device
bitmap in the superblock of device ranges with btree nodes, and we try
to keep this small).
However, having discards enabled will cause problems, since buckets
are discarded as soon as they become empty (this is why we don't
implement fstrim: we don't need it).
Hopefully, this feature will be a one-off thing that's never used
again: this was implemented for recovering from the "vfs i_nlink 0 ->
subvol deletion" bug, and that bug was unusually disastrous and
additional safeguards have since been implemented.
But if it does turn out that we need this more in the future, I'll
have to implement an option so that empty buckets aren't discarded
immediately - lagging by perhaps 1% of device capacity.
Signed-off-by: Kent Overstreet <kent.overstreet@linux.dev>
Diffstat (limited to 'scripts/lib/kdoc/kdoc_output.py')
0 files changed, 0 insertions, 0 deletions