Hi Martin, Dirk, Paolo, (and Leituviu?) - I wasn't thinking and didn't include recent committers to the testdisk and partclone packages in my initial post. Neither has a listed maintainer for the openSUSE packages. I'd like feedback on whether libreiserfs support can be dropped from these packages. The TL;DR version of the below is that I inherited libreiserfs at some point. I haven't maintained it except for a small build fix years ago and will not maintain it. libreiserfs is only used as a direct dependency by these two packages. It was a transitive dependency via parted, but that dependency has been obsolete since 2011 and I've pushed an SR to fix that. Reiserfs support for the dozen or so other packages that require it is provided by the libreiserfscore0 library from the 'reiserfs' package that I do maintain. The libreiserfs package is an abandoned project that has no official location from which to download it and hasn't been updated since 2004 except when people notice the build has broken and fix it. The alternatives to dropping support for libreiserfs is that someone else steps up to maintain it or someone steps up to port the reiserfs functionality to libreiserfscore0. The functionality in partclone is pretty trivial but the functionality in testdisk is more involved (and has to be buggy already, based on the interfaces). Thanks, -Jeff On 3/19/21 12:25 PM, Jeff Mahoney wrote:

On 3/19/21 12:09 PM, Neal Gompa wrote:

...

On Fri, Mar 19, 2021 at 12:01 PM Jeff Mahoney <jeffm@suse.com> 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.

Isn't this used by btrfs-progs to support reiserfs->btrfs conversions? Do we care that would be broken going forward?

No. libreiserfs was a separate implementation that was never officially adopted as part of the reiserfs project. btrfsprogs and a little over a dozen other package use libreiserfscore0 from reiserfsprogs (our 'reiserfs' package) for reiserfs support.

-Jeff

-- Jeff Mahoney Director, SUSE Labs Data & Performance

Hello Jeff, Thanks for including me, even though my contrib was really small :) I'm fine with dropping support though. Thanks, BR On March 19, 2021 21:10:35 Jeff Mahoney <jeffm@suse.com> wrote:

Hi Martin, Dirk, Paolo, (and Leituviu?) -

I wasn't thinking and didn't include recent committers to the testdisk and partclone packages in my initial post. Neither has a listed maintainer for the openSUSE packages. I'd like feedback on whether libreiserfs support can be dropped from these packages.

The TL;DR version of the below is that I inherited libreiserfs at some point. I haven't maintained it except for a small build fix years ago and will not maintain it. libreiserfs is only used as a direct dependency by these two packages. It was a transitive dependency via parted, but that dependency has been obsolete since 2011 and I've pushed an SR to fix that. Reiserfs support for the dozen or so other packages that require it is provided by the libreiserfscore0 library from the 'reiserfs' package that I do maintain. The libreiserfs package is an abandoned project that has no official location from which to download it and hasn't been updated since 2004 except when people notice the build has broken and fix it.

The alternatives to dropping support for libreiserfs is that someone else steps up to maintain it or someone steps up to port the reiserfs functionality to libreiserfscore0. The functionality in partclone is pretty trivial but the functionality in testdisk is more involved (and has to be buggy already, based on the interfaces).

Thanks,

-Jeff

On 3/19/21 12:25 PM, Jeff Mahoney wrote:

...

On 3/19/21 12:09 PM, Neal Gompa wrote:

...

On Fri, Mar 19, 2021 at 12:01 PM Jeff Mahoney <jeffm@suse.com> 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.

Isn't this used by btrfs-progs to support reiserfs->btrfs conversions? Do we care that would be broken going forward?

No. libreiserfs was a separate implementation that was never officially adopted as part of the reiserfs project. btrfsprogs and a little over a dozen other package use libreiserfscore0 from reiserfsprogs (our 'reiserfs' package) for reiserfs support.

-Jeff

-- Jeff Mahoney Director, SUSE Labs Data & Performance

On 22/03/2021 02.04, Jeff Mahoney wrote:

On 3/19/21 4:57 PM, Carlos E. R. wrote:

...

On 19/03/2021 17.00, Jeff Mahoney wrote:

...

Hi all -

...

...

...

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.

Thank you for the information :-) As I said, no objection from a reiserfs user point of view. -- Cheers / Saludos, Carlos E. R. (from 15.2 x86_64 at Telcontar)

On Monday 2021-03-22 09:04, Mathias Homann wrote:

Am Freitag, 19. März 2021, 17:00:42 CET schrieb Jeff Mahoney:

...

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.

Fine with me - I haven't used reiserfs at all since around 2002 when a hard crash actually wiped out the whole filesystem, and not just a few files like it would have been in ext2...

This has little to do with ext2 vs reiserfs. If you trash the root node, you are losing references to other files, such is the nature of top-down hierarchial datasets, irrespective of fs. No backup -> no pity. What recovery tools make or can make out of the remaining pieces is a different topic, and filesystems do well when they have certain placement strategies and/or signatures (hi XFS) that work in favor of extraction tools' heuristics.