| Message ID | r75jqqdjp24gikil2l26wwtxdxvqxpgfaixb2rqmuyzxnbhseq@6k34emck64hv (mailing list archive) |
|---|---|
| State | New |
| Headers | show |
| Series | [GIT,PULL] bcachefs changes for 6.11 | expand |
Hi Kent, On Sun, 14 Jul 2024 21:26:30 -0400 Kent Overstreet <kent.overstreet@linux.dev> wrote: > > Hi Linus - another opossum for the posse: > > The following changes since commit 0c3836482481200ead7b416ca80c68a29cfdaabd: > > Linux 6.10 (2024-07-14 15:43:32 -0700) > > are available in the Git repository at: > > https://evilpiepirate.org/git/bcachefs.git tags/bcachefs-2024-07-14 > > for you to fetch changes up to efb2018e4d238cc205690ac62c0917d60d291e66: > > bcachefs: Kill bch2_assert_btree_nodes_not_locked() (2024-07-14 19:59:12 -0400) We normally expect branches to not be rebased just before being sent to Linus for merging. See: Documentation/maintainer/rebasing-and-merging.rst
On Sun, 14 Jul 2024 at 18:26, Kent Overstreet <kent.overstreet@linux.dev> wrote: > > Hi Linus - another opossum for the posse: (The kernel naming tends to be related to some random event, in this case we had a family of opossums under our shed for a couple of months) > bcachefs changes for 6.11-rc1 As Stephen pointed out, all of this seems to have been rebased basically as the merge window opened, so if it was in linux-next, I certainly can't easily validate it without having to compare patch ids etc. DON'T DO THIS. Also, the changes to outside fs/bcachefs had questions that weren't answered. So I'm just dropping this all for now. Linus
On Wed, Jul 17, 2024 at 11:53:04AM GMT, Linus Torvalds wrote: > On Sun, 14 Jul 2024 at 18:26, Kent Overstreet <kent.overstreet@linux.dev> wrote: > > > > Hi Linus - another opossum for the posse: > > (The kernel naming tends to be related to some random event, in this > case we had a family of opossums under our shed for a couple of > months) Oh cute :) > > bcachefs changes for 6.11-rc1 > > As Stephen pointed out, all of this seems to have been rebased > basically as the merge window opened, so if it was in linux-next, I > certainly can't easily validate it without having to compare patch ids > etc. DON'T DO THIS. I had to give this some thought; the proximate cause was just fat fingering/old reflexes, but the real issue that's been causing conflicts is that I've got testers running my trees who very much /do/ need to be on the latest tagged release. And I can't just leave it for them to do a rebase/merge, because a) they don't do that, and b) then I'm looking at logs with commits I can't reference. So - here's how my branches are going to be from now on: As before: - bcachefs-testing: code goes here first, until it's passed the testing automation. Don't run this unless you're working with me on something. - for-next: the subset of bcachefs-testing that's believed to be stable - bcachefs-for-upstream: queue for next pull request, generally just hotfixes But my master branch (previously the same as for-next) will now be for-next merged with the latest tag from your tree, and I may do similarly for bcachefs-for-upstream if it's needed. As a bonus, this means the testing automation will now be automatically testing my branch + your latest; this would have caught the breakage from Christoph's FUA changes back in 6.7. > Also, the changes to outside fs/bcachefs had questions that weren't answered. Yeah, those comments should have been added. Waiman, how's this? -- >8 -- From 1d8cbc45ef1bab9be7119e0c5a6f8a05d5e2ca7d Mon Sep 17 00:00:00 2001 From: Kent Overstreet <kent.overstreet@linux.dev> Date: Thu, 18 Jul 2024 17:17:10 -0400 Subject: [PATCH] lockdep: Add comments for lockdep_set_no{validate,track}_class() Cc: Waiman Long <longman@redhat.com> Signed-off-by: Kent Overstreet <kent.overstreet@linux.dev> diff --git a/include/linux/lockdep.h b/include/linux/lockdep.h index b76f1bcd2f7f..bdfbdb210fd7 100644 --- a/include/linux/lockdep.h +++ b/include/linux/lockdep.h @@ -178,9 +178,22 @@ static inline void lockdep_init_map(struct lockdep_map *lock, const char *name, (lock)->dep_map.wait_type_outer, \ (lock)->dep_map.lock_type) +/** + * lockdep_set_novalidate_class: disable checking of lock ordering on a given + * lock + * + * Lockdep will still record that this lock has been taken, and print held + * instances when dumping locks + */ #define lockdep_set_novalidate_class(lock) \ lockdep_set_class_and_name(lock, &__lockdep_no_validate__, #lock) +/** + * lockdep_set_notrack_class: disable lockdep tracking of a given lock entirely + * + * Bigger hammer than lockdep_set_novalidate_class: so far just for bcachefs, + * which takes more locks than lockdep is able to track (48). + */ #define lockdep_set_notrack_class(lock) \ lockdep_set_class_and_name(lock, &__lockdep_no_track__, #lock)
On Thu, Jul 18, 2024 at 05:20:54PM -0400, Kent Overstreet wrote: > From: Kent Overstreet <kent.overstreet@linux.dev> > Date: Thu, 18 Jul 2024 17:17:10 -0400 > Subject: [PATCH] lockdep: Add comments for lockdep_set_no{validate,track}_class() > > Cc: Waiman Long <longman@redhat.com> > Signed-off-by: Kent Overstreet <kent.overstreet@linux.dev> > > diff --git a/include/linux/lockdep.h b/include/linux/lockdep.h > index b76f1bcd2f7f..bdfbdb210fd7 100644 > --- a/include/linux/lockdep.h > +++ b/include/linux/lockdep.h > @@ -178,9 +178,22 @@ static inline void lockdep_init_map(struct lockdep_map *lock, const char *name, > (lock)->dep_map.wait_type_outer, \ > (lock)->dep_map.lock_type) > > +/** > + * lockdep_set_novalidate_class: disable checking of lock ordering on a given > + * lock > + * > + * Lockdep will still record that this lock has been taken, and print held > + * instances when dumping locks > + */ Might want to run this through kernel-doc. I'm pretty sure it wants macro comments to be formatted like function comments. ie: /** * lockdep_set_novalidate_class - Disable lock order checks on this lock. * @lock: The lock to disable order checks for. * * Lockdep will still record that this lock has been taken, and print held * instances when dumping locks. */ > #define lockdep_set_novalidate_class(lock) \ > lockdep_set_class_and_name(lock, &__lockdep_no_validate__, #lock)
On 7/18/24 17:20, Kent Overstreet wrote: > On Wed, Jul 17, 2024 at 11:53:04AM GMT, Linus Torvalds wrote: >> On Sun, 14 Jul 2024 at 18:26, Kent Overstreet <kent.overstreet@linux.dev> wrote: >>> Hi Linus - another opossum for the posse: >> (The kernel naming tends to be related to some random event, in this >> case we had a family of opossums under our shed for a couple of >> months) > Oh cute :) > >>> bcachefs changes for 6.11-rc1 >> As Stephen pointed out, all of this seems to have been rebased >> basically as the merge window opened, so if it was in linux-next, I >> certainly can't easily validate it without having to compare patch ids >> etc. DON'T DO THIS. > I had to give this some thought; the proximate cause was just > fat fingering/old reflexes, but the real issue that's been causing > conflicts is that I've got testers running my trees who very much /do/ > need to be on the latest tagged release. > > And I can't just leave it for them to do a rebase/merge, because a) they > don't do that, and b) then I'm looking at logs with commits I can't > reference. > > So - here's how my branches are going to be from now on: > > As before: > > - bcachefs-testing: code goes here first, until it's passed the testing > automation. Don't run this unless you're working with me on something. > - for-next: the subset of bcachefs-testing that's believed to be stable > - bcachefs-for-upstream: queue for next pull request, generally just > hotfixes > > But my master branch (previously the same as for-next) will now be > for-next merged with the latest tag from your tree, and I may do > similarly for bcachefs-for-upstream if it's needed. > > As a bonus, this means the testing automation will now be automatically > testing my branch + your latest; this would have caught the breakage > from Christoph's FUA changes back in 6.7. > >> Also, the changes to outside fs/bcachefs had questions that weren't answered. > Yeah, those comments should have been added. Waiman, how's this? > > -- >8 -- > > From 1d8cbc45ef1bab9be7119e0c5a6f8a05d5e2ca7d Mon Sep 17 00:00:00 2001 > From: Kent Overstreet <kent.overstreet@linux.dev> > Date: Thu, 18 Jul 2024 17:17:10 -0400 > Subject: [PATCH] lockdep: Add comments for lockdep_set_no{validate,track}_class() > > Cc: Waiman Long <longman@redhat.com> > Signed-off-by: Kent Overstreet <kent.overstreet@linux.dev> > > diff --git a/include/linux/lockdep.h b/include/linux/lockdep.h > index b76f1bcd2f7f..bdfbdb210fd7 100644 > --- a/include/linux/lockdep.h > +++ b/include/linux/lockdep.h > @@ -178,9 +178,22 @@ static inline void lockdep_init_map(struct lockdep_map *lock, const char *name, > (lock)->dep_map.wait_type_outer, \ > (lock)->dep_map.lock_type) > > +/** > + * lockdep_set_novalidate_class: disable checking of lock ordering on a given > + * lock > + * > + * Lockdep will still record that this lock has been taken, and print held > + * instances when dumping locks > + */ > #define lockdep_set_novalidate_class(lock) \ > lockdep_set_class_and_name(lock, &__lockdep_no_validate__, #lock) > > +/** > + * lockdep_set_notrack_class: disable lockdep tracking of a given lock entirely > + * > + * Bigger hammer than lockdep_set_novalidate_class: so far just for bcachefs, > + * which takes more locks than lockdep is able to track (48). > + */ > #define lockdep_set_notrack_class(lock) \ > lockdep_set_class_and_name(lock, &__lockdep_no_track__, #lock) > > That should be good enough. Thanks, Longman
On 7/18/24 17:27, Matthew Wilcox wrote: > On Thu, Jul 18, 2024 at 05:20:54PM -0400, Kent Overstreet wrote: >> From: Kent Overstreet <kent.overstreet@linux.dev> >> Date: Thu, 18 Jul 2024 17:17:10 -0400 >> Subject: [PATCH] lockdep: Add comments for lockdep_set_no{validate,track}_class() >> >> Cc: Waiman Long <longman@redhat.com> >> Signed-off-by: Kent Overstreet <kent.overstreet@linux.dev> >> >> diff --git a/include/linux/lockdep.h b/include/linux/lockdep.h >> index b76f1bcd2f7f..bdfbdb210fd7 100644 >> --- a/include/linux/lockdep.h >> +++ b/include/linux/lockdep.h >> @@ -178,9 +178,22 @@ static inline void lockdep_init_map(struct lockdep_map *lock, const char *name, >> (lock)->dep_map.wait_type_outer, \ >> (lock)->dep_map.lock_type) >> >> +/** >> + * lockdep_set_novalidate_class: disable checking of lock ordering on a given >> + * lock >> + * >> + * Lockdep will still record that this lock has been taken, and print held >> + * instances when dumping locks >> + */ > Might want to run this through kernel-doc. I'm pretty sure it wants > macro comments to be formatted like function comments. ie: > > /** > * lockdep_set_novalidate_class - Disable lock order checks on this lock. > * @lock: The lock to disable order checks for. > * > * Lockdep will still record that this lock has been taken, and print held > * instances when dumping locks. > */ > >> #define lockdep_set_novalidate_class(lock) \ >> lockdep_set_class_and_name(lock, &__lockdep_no_validate__, #lock) Yes, that is true. It is not in the proper kernel-doc format. Either use the proper format or use a single "*" instead. Cheers, Longman
On Thu, 18 Jul 2024 at 14:21, Kent Overstreet <kent.overstreet@linux.dev> wrote: > > But my master branch (previously the same as for-next) will now be > for-next merged with the latest tag from your tree, and I may do > similarly for bcachefs-for-upstream if it's needed. No. No back-merges. We actually have documentation about this, so I won't repeat the hundreds of emails I've sent out: Documentation/maintainer/rebasing-and-merging.rst But the gist of it (well, one of them) is that you should keep your branch *YOUR* branch, not think that you should merge in other peoples work into it (or rebase it on top of random work by other developers). There are valid reasons to rebase, but they are balanced against some VERY valid reasons not to do it, so if you have to rebase, make sure those reasons really outweigh the reasons not to. And don't do it just before a pull request - and if there is some catastrophic event that caused a recent rebase, let me know in the pull request. > As a bonus, this means the testing automation will now be automatically > testing my branch + your latest No. That's what linux-next is about - it does integration testing. Your development branch IS NOT FOR TESTING OTHER RANDOM THINGS. You are actively making things worse if you do: you should worry about YOUR code, not about all the random other things going on. Now, if you want to do _additional_ testing along the lines of "what happens with my branch and Linus' latest" then that is ok - but that should be something you see as completely separate from testing your own work. IOW, you can certainly wear "multiple hats" - your bcachefs developer hat that worries about your bcachefs branch, and if you want to *also* do some integration testing, go right ahead and have another "integration testing branch" that you then test separately. But I don't want your integration path. When I get a bcachefs pull, I want the *bcachefs* side to be solid and tested. Not something else. So by all means keep multiple branches for different reasons. If you think you have users that need to test some integration branch (which honestly sounds like a horrible idea, but you do you), make them a branch too if you really want to. But again, that has NOTHING to do with bcachefs development, and you should not mix that up with what you send me. Linus
On Thu, Jul 18, 2024 at 03:06:07PM GMT, Linus Torvalds wrote: > On Thu, 18 Jul 2024 at 14:21, Kent Overstreet <kent.overstreet@linux.dev> wrote: > > > > But my master branch (previously the same as for-next) will now be > > for-next merged with the latest tag from your tree, and I may do > > similarly for bcachefs-for-upstream if it's needed. > > No. No back-merges. We actually have documentation about this, so I > won't repeat the hundreds of emails I've sent out: Sorry, I must not have been clear. My master branch is a) not where I do development, and b) not not a branch that I will be sending to you - that's simply the primary branch I publish for people testing the latest bcachefs code. So: master will now be just updated by a hook on the server whenever I update for-next. > There are valid reasons to rebase, but they are balanced against some > VERY valid reasons not to do it, so if you have to rebase, make sure > those reasons really outweigh the reasons not to. > > And don't do it just before a pull request - and if there is some > catastrophic event that caused a recent rebase, let me know in the > pull request. Yes, this will help with that; last cycle I had to rebase at rc4 because of something my testers were hitting, but it wasn't affecting my development so with the new setup my development branches will be able to stay based on rc1. > > As a bonus, this means the testing automation will now be automatically > > testing my branch + your latest > > No. That's what linux-next is about - it does integration testing. Oh? Does it now? I've gotten essentially zero in the way of test feedback from for-next (except from Stephen Rothwell directly, the odd build warning or merge issue, but 0day mostly catches the build stuff before it hits next). And I don't think the rest of the filesystem community is any different, because a major subject at LSF this year was in fact the need for someone to start a fs-next branch for integration testing. > Your development branch IS NOT FOR TESTING OTHER RANDOM THINGS. > > You are actively making things worse if you do: you should worry about > YOUR code, not about all the random other things going on. > > Now, if you want to do _additional_ testing along the lines of "what > happens with my branch and Linus' latest" then that is ok - but that > should be something you see as completely separate from testing your > own work. Yes, that's exactly what I was describing. > > IOW, you can certainly wear "multiple hats" - your bcachefs developer > hat that worries about your bcachefs branch, and if you want to *also* > do some integration testing, go right ahead and have another > "integration testing branch" that you then test separately. > > But I don't want your integration path. When I get a bcachefs pull, I > want the *bcachefs* side to be solid and tested. Not something else. Ditto > So by all means keep multiple branches for different reasons. If you > think you have users that need to test some integration branch (which > honestly sounds like a horrible idea, but you do you), No, the integration branch isn't for testing other code, it's because they don't want to be running rc1 if rc4 or rc7 is out. That's literally all it is.
On Thu, 18 Jul 2024 at 15:24, Kent Overstreet <kent.overstreet@linux.dev> wrote: > > Sorry, I must not have been clear. My master branch is a) not where I do > development, and b) not not a branch that I will be sending to you - > that's simply the primary branch I publish for people testing the latest > bcachefs code. > > So: master will now be just updated by a hook on the server whenever I > update for-next. Oh, ok, then that's fine. > > Now, if you want to do _additional_ testing along the lines of "what > > happens with my branch and Linus' latest" then that is ok - but that > > should be something you see as completely separate from testing your > > own work. > > Yes, that's exactly what I was describing. Good, sounds like we're on the same page. Linus
The pull request you sent on Sun, 14 Jul 2024 21:26:30 -0400:
> https://evilpiepirate.org/git/bcachefs.git tags/bcachefs-2024-07-14
has been merged into torvalds/linux.git:
https://git.kernel.org/torvalds/c/2e118ba36d56acf78084518dfb7cb53b1d417da0
Thank you!
On Thu, Jul 18, 2024 at 06:24:08PM -0400, Kent Overstreet wrote: > > I've gotten essentially zero in the way of test feedback from > for-next (except from Stephen Rothwell directly, the odd build > warning or merge issue, but 0day mostly catches the build stuff > before it hits next). I am currently running regular testing on the new linux-next's fs-next branch. Things which are still blocking me from announcing it are: *) Negotiating with Konstantin about the new lists.linux.dev mailing list. *) A few minor bug fixes / robustification improves in the "gce-xfstests watch" --- for example, right now if git fetch fails due to load throttling / anti-DOS protections on git.kernel.org trip the git watcher dies. Obviously, I need to teach it to do exponential backoff retries, because I'm not going to leave my kernel.org credentials on a VM running in the cloud to bypass the kernel.org DOS protections. :-) As far as bcachefs is concerned, my xfstests-bld infrastructure isn't set up to build rust userspace, and Debian has a very ancient bcachefs packages --- the latest version in Debian stable and unstable dates from November 2022. So I haven't enabled bcachefs support in gce-xfstests and kvm-xfstests yet. Patches gratefully accepted. :-) In any case, I'm hoping to have some publically accessible regular test results of fs-next. I've just been crazy busy lately.... - Ted
On Fri, Jul 19, 2024 at 10:30:01AM GMT, Theodore Ts'o wrote: > On Thu, Jul 18, 2024 at 06:24:08PM -0400, Kent Overstreet wrote: > > > > I've gotten essentially zero in the way of test feedback from > > for-next (except from Stephen Rothwell directly, the odd build > > warning or merge issue, but 0day mostly catches the build stuff > > before it hits next). > > I am currently running regular testing on the new linux-next's fs-next > branch. Things which are still blocking me from announcing it are: > > *) Negotiating with Konstantin about the new lists.linux.dev mailing > list. > > *) A few minor bug fixes / robustification improves in the > "gce-xfstests watch" --- for example, right now if git fetch fails > due to load throttling / anti-DOS protections on git.kernel.org > trip the git watcher dies. Obviously, I need to teach it to do > exponential backoff retries, because I'm not going to leave my > kernel.org credentials on a VM running in the cloud to bypass the > kernel.org DOS protections. :-) > > As far as bcachefs is concerned, my xfstests-bld infrastructure isn't > set up to build rust userspace, and Debian has a very ancient bcachefs > packages --- the latest version in Debian stable and unstable dates > from November 2022. So I haven't enabled bcachefs support in > gce-xfstests and kvm-xfstests yet. Patches gratefully accepted. :-) I can apt install 1.9.1? But I just discovered, because I had to switch my own testing to the debian package, that the mount helper wasn't being run previously (doesn't check /usr/local/sbin); and mounts with the mount helper are failing with -EBUSY. Presumably there's a race, since before calling the mount syscall, our mount helper has to open and close the block device (we have to read the superblock to check if it's encrypted, we may need to ask for a passphrase). The delayed_fput stuff that was causing issues with io_uring - I suspect something similar. But the plot thickens - all the failing tests are ones that use device mapper...
On Sat, Jul 20, 2024 at 11:48:09AM -0400, Kent Overstreet wrote: > > As far as bcachefs is concerned, my xfstests-bld infrastructure isn't > > set up to build rust userspace, and Debian has a very ancient bcachefs > > packages --- the latest version in Debian stable and unstable dates > > from November 2022. So I haven't enabled bcachefs support in > > gce-xfstests and kvm-xfstests yet. Patches gratefully accepted. :-) > > I can apt install 1.9.1? Ah, I see. bcachefs-tools is currently in Debian unstable, but not in Debian testing[1]; it's currently hung up due to the auto-libsodium transition[2]. Once that clears I can look at backporting it to debian-backports (since my test appliance runs on Debian stable, for better repeatable test appliance creation. :-) [1] https://tracker.debian.org/pkg/bcachefs-tools [2] https://release.debian.org/transitions/html/auto-libsodium.html - Ted
Hi Linus - another opossum for the posse: The following changes since commit 0c3836482481200ead7b416ca80c68a29cfdaabd: Linux 6.10 (2024-07-14 15:43:32 -0700) are available in the Git repository at: https://evilpiepirate.org/git/bcachefs.git tags/bcachefs-2024-07-14 for you to fetch changes up to efb2018e4d238cc205690ac62c0917d60d291e66: bcachefs: Kill bch2_assert_btree_nodes_not_locked() (2024-07-14 19:59:12 -0400) ---------------------------------------------------------------- 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 ---------------------------------------------------------------- Ariel Miculas (2): bcachefs: bch2_dir_emit() - fix directory reads in the fuse driver bcachefs: bch2_btree_insert() - add btree iter flags Brian Foster (2): bcachefs: fix smatch data leak warning in fs usage ioctl MAINTAINERS: remove Brian Foster as a reviewer for bcachefs Hongbo Li (5): bcachefs: implement FS_IOC_GETVERSION to support lsattr bcachefs: support get fs label bcachefs: support FS_IOC_SETFSLABEL bcachefs: support STATX_DIOALIGN for statx file bcachefs: show none if label is not set Kent Overstreet (89): bcachefs: Print allocator stuck on timeout in fallocate path bcachefs: btree ids are 64 bit bitmasks bcachefs: uninline fallocate functions bcachefs: add capacity, reserved to fs_alloc_debug_to_text() bcachefs: sysfs internal/trigger_journal_writes bcachefs: sysfs trigger_freelist_wakeup bcachefs: bch2_btree_reserve_cache_to_text() bcachefs: fix ei_update_lock lock ordering bcachefs: fix missing include bcachefs: add might_sleep() annotations for fsck_err() bcachefs: Check for bsets past bch_btree_ptr_v2.sectors_written bcachefs: btree_ptr_sectors_written() now takes bkey_s_c bcachefs: bch2_printbuf_strip_trailing_newline() bcachefs: check_key_has_inode() bcachefs: bch_alloc->stripe_sectors bcachefs: BCH_DATA_unstriped bcachefs: metadata version bucket_stripe_sectors bcachefs: KEY_TYPE_accounting bcachefs: Accumulate accounting keys in journal replay bcachefs: btree write buffer knows how to accumulate bch_accounting keys bcachefs: Disk space accounting rewrite bcachefs: Coalesce accounting keys before journal replay bcachefs: dev_usage updated by new accounting bcachefs: Kill bch2_fs_usage_initialize() bcachefs: Convert bch2_ioctl_fs_usage() to new accounting bcachefs: kill bch2_fs_usage_read() bcachefs: Kill writing old accounting to journal bcachefs: Delete journal-buf-sharded old style accounting bcachefs: Kill bch2_fs_usage_to_text() bcachefs: Kill fs_usage_online bcachefs: Kill replicas_journal_res bcachefs: Convert gc to new accounting bcachefs: Convert bch2_replicas_gc2() to new accounting bcachefs: bch2_verify_accounting_clean() bcachefs: bch_acct_compression bcachefs: Convert bch2_compression_stats_to_text() to new accounting bcachefs: bch2_fs_accounting_to_text() bcachefs: bch2_fs_usage_base_to_text() bcachefs: bch_acct_snapshot bcachefs: bch_acct_btree bcachefs: bch_acct_rebalance_work bcachefs: Eytzinger accumulation for accounting keys bcachefs: Kill bch2_mount() bcachefs: bch2_fs_get_tree() cleanup bcachefs: Don't block journal when finishing check_allocations() bcachefs: Walk leaf to root in btree_gc bcachefs: Initialize gc buckets in alloc trigger bcachefs: Delete old assertion for online fsck bcachefs: btree_types bitmask cleanups bcachefs: fsck_err() may now take a btree_trans bcachefs: Plumb more logging through stdio redirect bcachefs: twf: convert bch2_stdio_redirect_readline() to darray bcachefs: bch2_stdio_redirect_readline_timeout() bcachefs: twf: delete dead struct fields bcachefs: Unlock trans when waiting for user input in fsck bcachefs: BCH_IOCTL_QUERY_ACCOUNTING bcachefs: Fix race in bch2_accounting_mem_insert() bcachefs: Refactor disk accounting data structures bcachefs: bch2_accounting_mem_gc() bcachefs: Fix bch2_gc_accounting_done() locking bcachefs: Kill gc_pos_btree_node() bcachefs: bch2_btree_id_to_text() bcachefs: bch2_gc_pos_to_text() bcachefs: btree_node_unlock() assert bcachefs: btree_path_cached_set() bcachefs: kill key cache arg to bch2_assert_pos_locked() bcachefs: per_cpu_sum() bcachefs: Reduce the scope of gc_lock bcachefs: bch2_btree_key_cache_drop() now evicts bcachefs: split out lru_format.h bcachefs: Ensure buffered writes write as much as they can bcachefs: Fix missing BTREE_TRIGGER_bucket_invalidate flag bcachefs: Improve "unable to allocate journal write" message bcachefs: Simplify btree key cache fill path bcachefs: spelling fix bcachefs: Ratelimit checksum error messages bcachefs: bch2_extent_crc_unpacked_to_text() bcachefs: Make read_only a mount option again, but hidden bcachefs: Self healing on read IO error bcachefs: Improve startup message bcachefs: Convert clock code to u64s bcachefs: Improve copygc_wait_to_text() lockdep: lockdep_set_notrack_class() bcachefs: Add lockdep support for btree node locks bcachefs: btree node scan: fall back to comparing by journal seq bcachefs: drop packed, aligned from bkey_inode_buf bcachefs: __bch2_read(): call trans_begin() on every loop iter bcachefs: Rename BCH_WRITE_DONE -> BCH_WRITE_SUBMITTED bcachefs: Kill bch2_assert_btree_nodes_not_locked() Pankaj Raghav (2): bcachefs: use FGP_WRITEBEGIN instead of combining individual flags bcachefs: set fgf order hint before starting a buffered write Reed Riley (1): bcachefs: support REMAP_FILE_DEDUP in bch2_remap_file_range Thomas Bertschinger (6): bcachefs: make offline fsck set read_only fs flag bcachefs: don't expose "read_only" as a mount option bcachefs: allow passing full device path for target options bcachefs: add printbuf arg to bch2_parse_mount_opts() bcachefs: Add error code to defer option parsing bcachefs: use new mount API Uros Bizjak (1): bcachefs: Use try_cmpxchg() family of functions instead of cmpxchg() Youling Tang (5): bcachefs: Fix missing spaces in journal_entry_dev_usage_to_text bcachefs: Align the display format of `btrees/inodes/keys` bcachefs: Use filemap_read() to simplify the execution flow bcachefs: track writeback errors using the generic tracking infrastructure bcachefs: Add tracepoints for bch2_sync_fs() and bch2_fsync() MAINTAINERS | 1 - fs/bcachefs/Makefile | 3 +- fs/bcachefs/acl.c | 4 +- fs/bcachefs/alloc_background.c | 189 +++++--- fs/bcachefs/alloc_background.h | 41 +- fs/bcachefs/alloc_background_format.h | 2 + fs/bcachefs/alloc_foreground.c | 20 +- fs/bcachefs/alloc_foreground.h | 1 + fs/bcachefs/backpointers.c | 22 +- fs/bcachefs/bcachefs.h | 29 +- fs/bcachefs/bcachefs_format.h | 70 +-- fs/bcachefs/bcachefs_ioctl.h | 36 +- fs/bcachefs/bkey_methods.c | 1 + fs/bcachefs/btree_cache.c | 16 +- fs/bcachefs/btree_cache.h | 2 + fs/bcachefs/btree_gc.c | 287 ++++-------- fs/bcachefs/btree_gc.h | 23 +- fs/bcachefs/btree_gc_types.h | 13 +- fs/bcachefs/btree_io.c | 45 +- fs/bcachefs/btree_io.h | 6 +- fs/bcachefs/btree_iter.c | 87 ++-- fs/bcachefs/btree_iter.h | 15 +- fs/bcachefs/btree_journal_iter.c | 23 +- fs/bcachefs/btree_journal_iter.h | 17 + fs/bcachefs/btree_key_cache.c | 344 ++++++-------- fs/bcachefs/btree_locking.c | 12 +- fs/bcachefs/btree_locking.h | 9 +- fs/bcachefs/btree_node_scan.c | 51 ++- fs/bcachefs/btree_node_scan_types.h | 1 + fs/bcachefs/btree_trans_commit.c | 171 ++++--- fs/bcachefs/btree_types.h | 19 +- fs/bcachefs/btree_update.c | 6 +- fs/bcachefs/btree_update.h | 36 +- fs/bcachefs/btree_update_interior.c | 42 +- fs/bcachefs/btree_update_interior.h | 2 + fs/bcachefs/btree_write_buffer.c | 138 +++++- fs/bcachefs/btree_write_buffer.h | 49 +- fs/bcachefs/btree_write_buffer_types.h | 2 + fs/bcachefs/buckets.c | 764 +++++++------------------------ fs/bcachefs/buckets.h | 71 +-- fs/bcachefs/buckets_types.h | 17 +- fs/bcachefs/chardev.c | 103 +++-- fs/bcachefs/checksum.c | 5 +- fs/bcachefs/clock.c | 65 ++- fs/bcachefs/clock.h | 9 +- fs/bcachefs/clock_types.h | 3 +- fs/bcachefs/dirent.c | 8 + fs/bcachefs/disk_accounting.c | 790 +++++++++++++++++++++++++++++++++ fs/bcachefs/disk_accounting.h | 219 +++++++++ fs/bcachefs/disk_accounting_format.h | 162 +++++++ fs/bcachefs/disk_accounting_types.h | 19 + fs/bcachefs/disk_groups.c | 2 +- fs/bcachefs/ec.c | 117 +++-- fs/bcachefs/errcode.h | 3 +- fs/bcachefs/error.c | 56 ++- fs/bcachefs/error.h | 22 +- fs/bcachefs/extents.c | 29 +- fs/bcachefs/extents.h | 4 + fs/bcachefs/eytzinger.h | 11 + fs/bcachefs/fs-common.h | 2 + fs/bcachefs/fs-io-buffered.c | 41 +- fs/bcachefs/fs-io-direct.c | 4 +- fs/bcachefs/fs-io-pagecache.c | 37 +- fs/bcachefs/fs-io-pagecache.h | 7 +- fs/bcachefs/fs-io.c | 23 +- fs/bcachefs/fs-ioctl.c | 80 +++- fs/bcachefs/fs.c | 209 ++++++--- fs/bcachefs/fsck.c | 280 ++++++------ fs/bcachefs/inode.c | 60 ++- fs/bcachefs/inode.h | 2 +- fs/bcachefs/io_misc.c | 6 +- fs/bcachefs/io_read.c | 114 +++-- fs/bcachefs/io_write.c | 36 +- fs/bcachefs/io_write.h | 2 +- fs/bcachefs/journal.c | 17 +- fs/bcachefs/journal.h | 8 +- fs/bcachefs/journal_io.c | 27 +- fs/bcachefs/lru.c | 8 +- fs/bcachefs/lru.h | 12 - fs/bcachefs/lru_format.h | 25 ++ fs/bcachefs/move.c | 2 +- fs/bcachefs/movinggc.c | 11 +- fs/bcachefs/opts.c | 120 +++-- fs/bcachefs/opts.h | 15 +- fs/bcachefs/printbuf.c | 14 + fs/bcachefs/printbuf.h | 1 + fs/bcachefs/recovery.c | 134 ++++-- fs/bcachefs/recovery_passes.c | 5 + fs/bcachefs/recovery_passes_types.h | 1 + fs/bcachefs/reflink.c | 2 +- fs/bcachefs/replicas.c | 251 ++--------- fs/bcachefs/replicas.h | 16 +- fs/bcachefs/replicas_types.h | 16 - fs/bcachefs/sb-clean.c | 62 --- fs/bcachefs/sb-downgrade.c | 113 ++++- fs/bcachefs/sb-downgrade.h | 1 + fs/bcachefs/sb-errors_format.h | 4 +- fs/bcachefs/snapshot.c | 24 +- fs/bcachefs/subvolume.c | 20 +- fs/bcachefs/super-io.c | 5 +- fs/bcachefs/super.c | 92 ++-- fs/bcachefs/sysfs.c | 126 +++--- fs/bcachefs/tests.c | 14 +- fs/bcachefs/thread_with_file.c | 87 ++-- fs/bcachefs/thread_with_file.h | 4 +- fs/bcachefs/thread_with_file_types.h | 5 +- fs/bcachefs/trace.h | 50 +++ fs/bcachefs/two_state_shared_lock.h | 11 +- fs/bcachefs/util.h | 21 +- include/linux/lockdep.h | 4 + include/linux/lockdep_types.h | 1 + kernel/locking/lockdep.c | 9 +- 112 files changed, 3876 insertions(+), 2679 deletions(-) create mode 100644 fs/bcachefs/disk_accounting.c create mode 100644 fs/bcachefs/disk_accounting.h create mode 100644 fs/bcachefs/disk_accounting_format.h create mode 100644 fs/bcachefs/disk_accounting_types.h create mode 100644 fs/bcachefs/lru_format.h