On 3/19/21 4:57 PM, Carlos E. R. wrote:
On 19/03/2021 17.00, Jeff Mahoney wrote:
Hi all -
I'm technically the maintainer for the libreiserfs package. Outside of a minor build fix years ago, I've had nothing to do with it. Best I can tell, it was originally brought in for parted in 2005 and then used by the 'testdisk' and 'partclone' pacakges in Factory (but never SLE). The official reiserfsprogs are maintained by me upstream (handwavy, they don't take much maintenance), and are available on kernel.org. Libreiserfs hasn't been touched by its author since 2004 and has no official location for download. We have a copy cached. Other distros have a copy cached. That's it.
Parted stopped using file system libraries for any file system in 2011 and the dependencies are obsolete. I've filed submit requests for SLE and the Base:System project to remove them.
Testdisk uses it to recover reiserfs file systems, but it's clear it hasn't seen real usage or even testing. The libreiserfs API to iterate over file contents is restricted to blocks, which means that any file tails would be skipped entirely. Digging through the code, it also shows that even if that functionality was to be used, it requires patches be applied to libreiserfs which we are not applying. It can't work.
Partclone uses the library to iterate over the block-in-use bitmap to copy only the parts of the file system in use. That's simple to switch over to libreiserfscore but I'm not volunteering to do it. Practically, as these would be old file systems and on relatively small devices compared to today's devices. Reiserfs has an official file system size limit of 16 TB but a practical limit of 8 TB. Outside of a very specific customer request a long time ago, I've never seen anyone trying to use it on devices that large. It's also pretty unlikely that anyone with file systems that old that they are using and don't want to migrate are using Tumbleweed or, really, any recent release. dd will work just fine.
Both of these packages reference that libreiserfs is optional and give no hint as to where to locate it. Outside of our own enabling that support, I doubt it's used anywhere.
So, we have a situation where we have a library that has been abandoned by its author and two relatively simple dependencies for a file system that may still be in use for very old file systems (which also means relatively small file systems compared to today's device sizes), and for very limited use cases. In some cases those are broken as well.
Someone else is welcome to step up to maintain this library and keep those packages working with reiserfs (and fix those bugs) and I'm happy to turn it over, but the real question is: do we really need to keep this functionality around?
So, my proposal is: - Remove libreiserfs as a dependency for parted (already submitted, not much to discuss here) - Remove libreiserfs as a dependency for partclone and testdisk. - Remove libreiserfs entirely.
I understand from what you say that this does not affect people using (or even creating) reiserfs filesystems, but only those tools you mention (parted, testdisk, partclone), which any way may be broken in this respect currently.
Yep, except it doesn't actually affect parted. Parted stopped using libreiserfs ten years ago.
I use reiserfs in some of my systems (Leap), but given what you say it doesn't seem I or others would be affected, so, yes, go ahead :-)
(if I wanted to convert a reiserfs to btrfs I would use rsync, not convert in place)
And in either case, btrfs-convert reiserfs support is unaffected by this. It uses the libreiserfscore0 libary.
I suppose it doesn't have any effect on reiserfs4 :-?
Nope. The only thing shared in reiserfs and reiser4 is the name. -Jeff -- Jeff Mahoney Director, SUSE Labs Data & Performance