Messages in this thread | | | Subject | Re: PROBLEM: Reiser4 hard lockup | From | Edward Shishkin <> | Date | Wed, 28 Oct 2020 02:04:08 +0100 |
| |
On 10/27/2020 08:36 PM, Theodore Y. Ts'o wrote: > On Tue, Oct 27, 2020 at 01:53:31AM +0100, Edward Shishkin wrote: >>>> reiser4progs 1.1.x Software Framework Release Number (SFRN) 4.0.1 file >>>> system utilities should not be used to check/fix media formatted 'a >>>> priori' in SFRN 4.0.2 and vice-versa. >>> >>> Honestly, this is the first time I've heard about a Linux FS having >>> versioning other than a major one >> >> This is because, unlike other Linux file systems, reiser4 is a >> framework. >> >> In vanilla kernel having a filesystem-as-framework is discouraged for >> ideological reasons. As they explained: "nobody's interested in >> plugins". A huge monolithic mess without any internal structure - >> welcome :) > > I wouldn't call it an ideological problem, but more about wanting to > assure interoperability issues and wanting to reduce confusion on the > part of users, especially if images get moved between systems. There > is also plenty of way of introducing internal structure and code > cleanliness without going completely undisciplined with respect to > on-disk format extensions. :-)
Have you made this up right now? I remember very well all the requests for merging reiser4 to upstream (in 2004, 2005 and 2006 years) - compatibility claims had never been raised. Especially, it is not a problem to add mechanisms for keeping track of compatibility at any time.
> > Finally, I'll note that ext 2/3/4 does have a rather fine-grained set > of feature flags, with specific rules about what the kernel --- and > e2fsck --- should do if it finds a feature bit it doesn't understand > in the incompat, ro_compat, and compat feature flags set. This is > especially helpful since we have multiple implementations of ext 2/3/4 > out there (in FreeBSD, the GRUB bootloader, GNU HURD, Fuchsia, etc.) > and so using feature bits allow for safe and reliable interoperability > with the user being warned if they can safely only mount the file > system read-only, or not at all, if the file system has some new > feature that their current OS version does not support. We can also > give appropriate warnings if they are using an insufficiently recent > version of the userspace tools.
"Fine-grained" means per-volume decisions mount/not mount/read-only mount? It is even not yesterday technique. It is an ice age...
Edward.
| |