tag name | bcachefs-2024-07-18 (15f861f13a7ab4f8545912241de4fc7125203b56) |
tag date | 2024-07-18 18:34:56 -0400 |
tagged by | Kent Overstreet <kent.overstreet@linux.dev> |
tagged object | commit 6f719cbe0c... |
bcachefs changes for 6.11-rc1 (version 2)
Additional fixes on top of the original 6.11 pull request:
- undefined behaviour fixes, originally noted as breaking userspace LTO
builds
- fix a spurious warning in fsck_err, reported by Marcin
- fix an integer overflow on trans->nr_updates, also reported by Marcin;
this broke during deletion of highly fragmented indirect extents
- Add comments for lockdep functions
======
- Metadata version 1.8: Stripe sectors accounting, BCH_DATA_unstriped
This splits out the accounting of dirty sectors and stripe sectors in
alloc keys; this lets us see stripe buckets that still have unstriped
data in them.
This is needed for ensuring that erasure coding is working correctly, as
well as completing stripe creation after a crash.
- Metadata version 1.9: Disk accounting rewrite
The previous disk accounting scheme relied heavily on percpu counters
that were also sharded by outstanding journal buffer; it was fast but
not extensible or scalable, and meant that all accounting counters were
recorded in every journal entry.
The new disk accounting scheme stores accounting as normal btree keys;
updates are deltas until they are flushed by the btree write buffer.
This means we have no practical limit on the number of counters, and a
new tagged union format that's easy to extend.
We now have counters for compression type/ratio, per-snapshot-id usage,
per-btree-id usage, and pending rebalance work.
- Self healing on read IO/checksum error
data is now automatically rewritten if we get a read error and then a
successful retry
- Mount API conversion (thanks to Thomas Bertschinger)
- Better lockdep coverage
Previously, btree node locks were tracked individually by lockdep, like
any other lock. But we may take _many_ btree node locks simultaneously,
we easily blow through the limit of 48 locks that lockdep can track,
leading to lockdep turning itself off.
Tracking each btree node lock individually isn't really necessary since
we have our own cycle detector for deadlock avoidance and centralized
tracking of btree node locks, so we now have a single lockdep_map in
btree_trans for "any btree nodes are locked".
- some more small incremental work towards online check_allocations
- lots more debugging improvements, fixes
-----BEGIN PGP SIGNATURE-----
iQIzBAABCgAdFiEEKnAFLkS8Qha+jvQrE6szbY3KbnYFAmaZmJgACgkQE6szbY3K
bnZgZxAAg3lelPEq/1cYlHUekxMc0NO4kfRboKHjo5lgROu32T3L7r6+Zk8XWIZI
ifUTcHqz4/cyejxFx3llyPjTkjvKOvMei0h5FfX2a/0vkIf0XGAsLp14Tn5a8Ehj
I9AG701c43LSxrmSZxxBnzNvJXraasxFvVYOeg2xFozQeL1/7UM+0BkaqM8KIKWo
YnOuueISM03l/1igdURtQUGac1x7U4jMpqBeUNisHAJmUT/iRyb6wswFVlZuR5n0
h9Zr9aE47LepzZhCjgekQCRJZKDkSIlI/7jXqgq0FWPjTBT4PVZ3odYByEoMM69h
n7B9H0ChYBRlZ2iWVxZMJS47+ltiHrBR7/UJ8LGKGNy2CHUZVuoYgQKfuhSLL+l8
iTNATpsbCAL37jDo4YkaH3m5H1gmHpYfiSWeI29fTvdYV1iuoSVFVB0roRiHU3Ec
V2LJuD/qKODolks4oujtdPXl7G3ulk2wxpGwtcPfCbvDB3/sh08MtRjj73LU8++L
SPwfQa5uCgP7mGYZHw5CtmTh4cxOx7swrJ79ydcFVC7cw+my29PHLtQYM79ao+fR
JtQgRakNdcHAZpSZcgVE69OswZ+M+zlWM4ktVQE1+4n39cdNvM6f42kCAEuVCfpj
FC6t3fsblMeeMoyofG+DbaLIUuG8anclEw/iL+bdbec8LKxZ19Y=
=wU3H
-----END PGP SIGNATURE-----