[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. > 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 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? --D > Thanks, > Amir.
