On Fri 25-03-22 17:44:11, Linus Torvalds wrote: > On Wed, Mar 23, 2022 at 8:37 AM Jan Kara <jack@xxxxxxx> wrote: > > > > The biggest change in this pull is the addition of a deprecation message > > about reiserfs with the outlook that we'd eventually be able to remove it > > from the kernel. Because it is practically unmaintained and untested and > > odd enough that people don't want to bother with it anymore... > > Pulled. > > I have this memory of seeing somebody suggest the eventual removal be > a bit more gradual with a "turn it read-only" first, as perhaps a > slightly less drastic "remove entirely" maintainability option. Someone was suggesting we could keep reiserfs read-only. I didn't understand it as a "stronger variant" of deprecation message but maybe that was my lack of understanding. It is true we might switch reiserfs mounts to read-only say year before the planned removal, possibly allow overriding read-only mount with a special mount option, to force remaining users to pay attention. The warning on mount may be too easy to ignore. > But maybe I'm just confused and mis-remember - and maybe nobody is > willing to maintain even just a read-only form. But being at least > able to read old filesystem images might help *some* people if they > notice much too late that "oh, it's gone". Hmm, so you probably do mean: "keep read-only version around for a bit longer". The concern I have there is that to simplify life of people doing treewide changes (which was one of the motivations for scheduling reiserfs removal), we'd probably need to rip out the write support code from the kernel and I'm not sure how difficult is it going to be to carve out those bits of code. I'm not sure whether taking say grub2 reiserfs support code and making a fullblown fuse module with read-only support out of it isn't going to be simpler task. Honza -- Jan Kara <jack@xxxxxxxx> SUSE Labs, CR
