tag name | bcachefs-2024-07-14 (6ee361e216b35a421451cb3c380d24be0dc74ef8) |
tag date | 2024-07-14 21:13:33 -0400 |
tagged by | Kent Overstreet <kent.overstreet@linux.dev> |
tagged object | commit efb2018e4d... |
bcachefs changes for 6.11-rc1
- 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+jvQrE6szbY3KbnYFAmaUehEACgkQE6szbY3K
bnb4uRAAnzDGTkwGKJgNIfOGYO+W80/Zo3v6W1B3fX3bmGNgur6JyAip4hF0g/4h
7OXvzRKM0YS3Et0l82PQCX/LXlW/ak8NpvpI8QtLsYF7BgXrNi6ndLyt4GD5bTqc
kQBAaKDGa0LFhtv0CQlE38zEuSX+y3K0qmk6A4dcdZE/4BrWZynIB8xFFpphhYbA
fAN7etnVpNymGmeRtr0fPi/hQ0DDTObNB8UdscnRh1nAsQx1zbNLpeDTgGWwgEYz
sdN5n+ftTAIZuzm1LbCzLryZrJYVtm6XkWhK5PnfV+fJ1XtK39NMyk8oR30D69C+
dnh58Y5xLx3rEuX+ysM7h5xJDHOXa4nUFaaTxIs6O2+kWX76cQ7Rzfd3wW6H/3OA
8E6b9sApb6RRRPyiCJyMvkcrhUa7Kz8GmXxbCnoqWXBOpE3+T/wctIbJmMa9GudJ
2vVccl6b/RqJBZZfmc4wW1GkNPm2Y6QqfAMvDwXe3ngYU2t644v5J5fws6doo6kH
wUVyIMG2lso+ndeF3PPWG/s5W+v7zhog0fSCh8zCYDkhQBZ4CKm6Nkwzp+Zi5Ppq
PmW3W/Quy3jwOhkdmUkYOQW/7cnUdCpIGJfnEPxVN6PfLAqYZBoApEwKPbmUNqyK
HLu2+DQM6nVCW2zqFlBZMvRX3+E0hLX2MntndbmFh+fyT2OtSK0=
=BPXi
-----END PGP SIGNATURE-----