Message ID | 163492911924.1038219.13107463173777870713.stgit@warthog.procyon.org.uk (mailing list archive) |
---|---|
Headers | show |
Series | fscache: Rewrite index API and management system | expand |
On Fri, Oct 22, 2021 at 8:58 AM David Howells <dhowells@redhat.com> wrote: > > David Howells (52): > fscache_old: Move the old fscache driver to one side > fscache_old: Rename CONFIG_FSCACHE* to CONFIG_FSCACHE_OLD* > cachefiles_old: Move the old cachefiles driver to one side Honestly, I don't see the point of this when it ends up just being dead code basically immediately. You don't actually support picking one or the other at build time, just a hard switch-over. That makes the old fscache driver useless. You can't say "use the old one because I don't trust the new". You just have a legacy implementation with no users. Linus
Linus Torvalds <torvalds@linux-foundation.org> wrote: > Honestly, I don't see the point of this when it ends up just being > dead code basically immediately. > > You don't actually support picking one or the other at build time, > just a hard switch-over. > > That makes the old fscache driver useless. You can't say "use the old > one because I don't trust the new". You just have a legacy > implementation with no users. What's the best way to do this? Is it fine to disable caching in all the network filesystems and then directly remove the fscache and cachefiles drivers and replace them? It won't stop the network filesystems actually working - it'll just mean that they don't do any caching until converted and have caching reenabled. David
On Fri, Oct 22, 2021 at 9:40 AM David Howells <dhowells@redhat.com> wrote: > > What's the best way to do this? Is it fine to disable caching in all the > network filesystems and then directly remove the fscache and cachefiles > drivers and replace them? So the basic issue with this whole "total rewrite" is that there's no way to bisect anything. And there's no way for people to say "I don't trust the rewrite, I want to keep using the old tested model". Which makes this all painful and generally the wrong way to do anything like this, and there's fundamentally no "best way". The real best way would be if the conversion could be done truly incrementally. Flag-days simply aren't good for development, because even if the patch to enable the new code might be some trivial one-liner, that doesn't _help_ anything. The switch-over switches from one code-base to another, with no help from "this is where the problem started". So in order of preference: (a) actual incremental changes where the code keeps working all the time, and no flag days (b) same interfaces, so at least you can do A/B testing and people can choose one or the other (c) total rewrite and if (c) is the thing that all the network filesystem people want, then what the heck is the point in keeping dead code around? At that point, all the rename crap is just extra work, extra noise, and only a distraction. There's no upside that I can see. Linus
On Fri, Oct 22, 2021 at 9:58 AM Linus Torvalds <torvalds@linux-foundation.org> wrote: > > and if (c) is the thing that all the network filesystem people want, > then what the heck is the point in keeping dead code around? At that > point, all the rename crap is just extra work, extra noise, and only a > distraction. There's no upside that I can see. Again, I'm not a fan of (c) as an option, but if done, then the simplest model would appear to be: - remove the old fscache code, obviously disabling the Kconfig for it for each filesystem, all in one fell swoop. - add the new fscache code (possibly preferably in sane chunks that explains the parts). - then do a "convert to new world order and enable" commit individually for each filesystem but as mentioned, there's no sane way to bisect things, or have a sane development history in this kind of situation. Linus