On Mon, May 9, 2022 at 9:20 PM Darrick J. Wong <djwong@xxxxxxxxxx> wrote: > > [drop my oracle email from cc, outlook sux] > > On Mon, May 09, 2022 at 10:50:20AM +0300, Amir Goldstein wrote: > > Hi Darrick and Dave, > > > > I might have asked this back when reflink was introduced, but cannot > > find the question nor answer. > > > > Is there any a priori NACK or exceptional challenges w.r.t implementing > > upgrade of xfs to reflink support? > > No, just lack of immediate user demand + time to develop and merge code > + time to QA the whole mess to make sure it doesn't introduce any > messes. > I can certainly help with QA the upgrade scenarios. > > We have several customers with xfs formatted pre reflink that we would > > like to consider > > upgrading. > > > > Back in the time of reflink circa v4.9 there were few xfs features > > that could be > > upgraded, but nowadays, there are several features that could be upgraded. > > > > If I am not mistaken, the target audience for this upgrade would be > > xfs formatted > > with xfsprogs 4.17 (defaults). > > I realize that journal size may have been smaller at that time (I need to check) > > which may be a source of additional problems, > > Yes. We've found in practice that logsize < 100MB produce serious > scalability problems and increase deadlock opportunities on such old > kernels. The 64MB floor we just put in for xfsprogs 5.15 was a good > enough downwards estimate assuming that most people will end up on 5.19+ > kernels in the (very) long run. > > > but hopefully, some of your work > > to do a diet for journal credits for reflink could perhaps mitigate > > that issue(?). > > That work reduces the internal transaction size but leaves the existing > minimum log size standards intact. > > > Shall I take a swing at it? > > It's already written: > https://git.kernel.org/pub/scm/linux/kernel/git/djwong/xfsprogs-dev.git/log/?h=upgrade-older-features > How convenient :) I can start testing already. > I think the upcoming nrext64 xfsprogs patches took in the first patch in > that series. > > Question: Now that mkfs has a min logsize of 64MB, should we refuse > upgrades for any filesystem with logsize < 64MB? I think that would make a lot of sense. We do need to reduce the upgrade test matrix as much as we can, at least as a starting point. Our customers would have started with at least 1TB fs, so should not have a problem with minimum logsize on upgrade. BTW, in LSFMM, Ted had a session about "Resize patterns" regarding the practice of users to start with a small fs and grow it, which is encouraged by Cloud providers pricing model. I had asked Ted about the option to resize the ext4 journal and he replied that in theory it could be done, because the ext4 journal does not need to be contiguous. He thought that it was not the case for XFS though. Thanks, Amir.
