summaryrefslogtreecommitdiff
tag namebcachefs-2024-07-14 (6ee361e216b35a421451cb3c380d24be0dc74ef8)
tag date2024-07-14 21:13:33 -0400
tagged byKent Overstreet <kent.overstreet@linux.dev>
tagged objectcommit 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-----