| Message ID | 20210427164419.3729180-1-kent.overstreet@gmail.com (mailing list archive) |
|---|---|
| Headers | show |
| Series | bcachefs support | expand |
On Tue, Apr 27, 2021 at 12:44:16PM -0400, Kent Overstreet wrote: > A small patch adding bcachefs support, and two other patches for consideration: As bcachefs is not upstream yet, I think we should re-visit bcachefs support after it's in upstream. OTOH, I have some minor comments go to patch 1. Thanks, Eryu > > Kent Overstreet (3): > Initial bcachefs support > Improved .gitignore > Use --yes option to lvcreate > > .gitignore | 3 +++ > common/attr | 6 ++++++ > common/config | 3 +++ > common/dmlogwrites | 7 +++++++ > common/quota | 4 ++-- > common/rc | 31 +++++++++++++++++++++++++++++++ > tests/generic/042 | 3 ++- > tests/generic/081 | 2 +- > tests/generic/108 | 2 +- > tests/generic/425 | 3 +++ > tests/generic/441 | 2 +- > tests/generic/482 | 27 ++++++++++++++++++++------- > tests/generic/558 | 2 ++ > 13 files changed, 82 insertions(+), 13 deletions(-) > > -- > 2.31.1
On Sun, May 09, 2021 at 10:20:38PM +0800, Eryu Guan wrote: > On Tue, Apr 27, 2021 at 12:44:16PM -0400, Kent Overstreet wrote: > > A small patch adding bcachefs support, and two other patches for consideration: > > As bcachefs is not upstream yet, I think we should re-visit bcachefs > support after it's in upstream. I disagree completely. I've been waiting for this to land for some time so I can actually run fstests against bcachefs easily to evaluate it's current state of stability and support. The plans are to get bcachefs merged upstream, and so having support already in fstests makes it much easier for reviewers and developers to actually run tests and find problems prior to merging. As an upstream developer and someone who will be reviewing bcachefs when it is next proposed for merge, I would much prefer to see extensive and long term fstests coverage *before* the code is even merged upstream. Given that filesystems take years to develop to the point where they are stable and ready for merge, saying "can't enable the test environment until it is merged upstream" is not very helpful. As a general principle, we want developers of new filesystems to start using fstests early in the development process of their filesystem. We should be encouraging new filesystems to be added to fstests, not saying "we only support upstream filesystems". If the filesystem plans to be merged upstream, then fstests support for that filesystem should be there long before the filesytsem is even proposed for merge. We need to help people get new filesystems upstream, not place arbitrary "not upstream so not supported" catch-22s in their way... Hence I ask that you merge bcachefs support to help the process of getting bcachefs suport upstream. Cheers, Dave.
On Tue, May 11, 2021 at 09:14:46AM +1000, Dave Chinner wrote: > On Sun, May 09, 2021 at 10:20:38PM +0800, Eryu Guan wrote: > > On Tue, Apr 27, 2021 at 12:44:16PM -0400, Kent Overstreet wrote: > > > A small patch adding bcachefs support, and two other patches for consideration: > > > > As bcachefs is not upstream yet, I think we should re-visit bcachefs > > support after it's in upstream. > > I disagree completely. I've been waiting for this to land for some > time so I can actually run fstests against bcachefs easily to > evaluate it's current state of stability and support. The plans are > to get bcachefs merged upstream, and so having support already in > fstests makes it much easier for reviewers and developers to > actually run tests and find problems prior to merging. > > As an upstream developer and someone who will be reviewing bcachefs > when it is next proposed for merge, I would much prefer to see > extensive and long term fstests coverage *before* the code is even > merged upstream. Given that filesystems take years to develop to the > point where they are stable and ready for merge, saying "can't > enable the test environment until it is merged upstream" is not very > helpful. > > As a general principle, we want developers of new filesystems to > start using fstests early in the development process of their > filesystem. We should be encouraging new filesystems to be added to > fstests, not saying "we only support upstream filesystems". If the > filesystem plans to be merged upstream, then fstests support for > that filesystem should be there long before the filesytsem is even > proposed for merge. We need to help people get new filesystems > upstream, not place arbitrary "not upstream so not supported" > catch-22s in their way... > > Hence I ask that you merge bcachefs support to help the process of > getting bcachefs suport upstream. /me notes that both Eryu and Dave have been willing to merge surprisingly large quantities of code for XFS reflink and online fsck long before either of those features landed in mainline, so I think it's perfectly fine to merge Kent's relatively small changes to enable 'FSTYP=bcachefs'. (With all of Eryu's review comments fixed, obviously...) --D > Cheers, > > Dave. > -- > Dave Chinner > david@fromorbit.com
On Mon, May 10, 2021 at 06:26:45PM -0700, Darrick J. Wong wrote: > On Tue, May 11, 2021 at 09:14:46AM +1000, Dave Chinner wrote: > > On Sun, May 09, 2021 at 10:20:38PM +0800, Eryu Guan wrote: > > > On Tue, Apr 27, 2021 at 12:44:16PM -0400, Kent Overstreet wrote: > > > > A small patch adding bcachefs support, and two other patches for consideration: > > > > > > As bcachefs is not upstream yet, I think we should re-visit bcachefs > > > support after it's in upstream. > > > > I disagree completely. I've been waiting for this to land for some > > time so I can actually run fstests against bcachefs easily to > > evaluate it's current state of stability and support. The plans are > > to get bcachefs merged upstream, and so having support already in > > fstests makes it much easier for reviewers and developers to > > actually run tests and find problems prior to merging. > > > > As an upstream developer and someone who will be reviewing bcachefs > > when it is next proposed for merge, I would much prefer to see > > extensive and long term fstests coverage *before* the code is even > > merged upstream. Given that filesystems take years to develop to the > > point where they are stable and ready for merge, saying "can't > > enable the test environment until it is merged upstream" is not very > > helpful. > > > > As a general principle, we want developers of new filesystems to > > start using fstests early in the development process of their > > filesystem. We should be encouraging new filesystems to be added to > > fstests, not saying "we only support upstream filesystems". If the > > filesystem plans to be merged upstream, then fstests support for > > that filesystem should be there long before the filesytsem is even > > proposed for merge. We need to help people get new filesystems > > upstream, not place arbitrary "not upstream so not supported" > > catch-22s in their way... OK, that makes sense. Actually, I should have made my "upstream first" more clear. I'd love to merge non-upstream features/new fs supports if the proposed new feature/new filesystem has been developmented actively and the community has generally made the agreement that will merge the new feature/filesystem when it's in a good shape. IOW, it's not some random new features/filesystems, which are very likely to be dropped in the half way. And providing such info in the patch is very helpful to reviewers. > > > > Hence I ask that you merge bcachefs support to help the process of > > getting bcachefs suport upstream. Sure, bcachefs looks promising to me now :) > > /me notes that both Eryu and Dave have been willing to merge > surprisingly large quantities of code for XFS reflink and online fsck > long before either of those features landed in mainline, so I think it's Because I know you and the xfs commnity will work on it continuously and very unlikely make the new tests dead code :) Thanks, Eryu > perfectly fine to merge Kent's relatively small changes to enable > 'FSTYP=bcachefs'. > > (With all of Eryu's review comments fixed, obviously...) > > --D > > > Cheers, > > > > Dave. > > -- > > Dave Chinner > > david@fromorbit.com