On 2017-09-20 08:59, Dave Plater wrote:
On 20/09/2017 08:50, Per Jessen wrote:
Dave Plater wrote:
I think all that is happening is openSUSE is dropping support for reiserfs (Which I fondly remember running SUSE 6.4 on recycled hard drives, even one that was clunking, using reiserfs) but I don't think that it will be maliciously removed from the kernel.
Agree completely. There is simply no reason.
That would prevent yast from converting the partitions in the first place. If you can't read a partition you can't convert it.
This conversion idea seems a pretty odd and risky thing to attempt - fiddling people's data, needing extra space, backup etc.
It sounds like a lot of work for the yast/installation team as well, as you said it's risky, I don't know the structure of the reiser file system but it would need to be converted into a similar structured file system or it would require a lot of spare space to backup the system and then copy over to a new partition. This would be a show stopper for users without enough space if a reliable partition converter hasn't been created.
Converting live, no, I mean, on site, a reiserfs partition to... what? Reiserfs structure is a nightmare to understand and code, IMHO because it is brilliant. Write a migration tool in-house? Wow. Small files it stores where a normal filesystem stores the file name, without reserving data sectors to it. If I recall correctly, as the data sector block is not determined, it might store two files to the same sector.[1] How can you code conversion of that? Only by copying the files elsewhere. Creating a small filesystem then grow it. [1] Wikipedia explains it better. «ReiserFS stores file metadata ("stat items"), directory entries ("directory items"), inode block lists ("indirect items"), and tails of files ("direct items") in a single, combined B+ tree keyed by a universal object ID. Disk blocks allocated to nodes of the tree are "formatted internal blocks". Blocks for leaf nodes (in which items are packed end-to-end) are "formatted leaf blocks". All other blocks are "unformatted blocks" containing file contents. Directory items with too many entries or indirect items which are too long to fit into a node spill over into the right leaf neighbour. Block allocation is tracked by free space bitmaps in fixed locations.» «By contrast, ext2 and other Berkeley FFS-like file systems of that time simply used a fixed formula for computing inode locations, hence limiting the number of files they may contain.[21] Most such file systems also store directories as simple lists of entries, which makes directory lookups and updates linear time operations and degrades performance on very large directories. The single B+ tree design in ReiserFS avoids both of these problems due to better scalability properties.» https://en.wikipedia.org/wiki/ReiserFS -- Cheers / Saludos, Carlos E. R. (from 42.2 x86_64 "Malachite" at Telcontar)