On Wednesday, 20 September 2017 16:09:56 ACST Richard Brown wrote:
[...] If you store a ReiserFS v3 disk image (VM, container, etc) on a ReiserFS v3 filesystem, fsck WILL confuse your the disk image for another partition and 'restore' files from the image, corrupting the filesystem and losing data in the process.
Straw man argument. The majority of the discussion has been around ReiserV4, not V3.
This is even possible if you do not totally wipe (not just format, but totally overwrite) a previous ReiserFS v3 partition on the same disk - Reisers' fsck otherwise will try and 'restore' data from the previous partition, overwriting the current one.
This is behaviour that's abhorrent and remains unfixed.
Even with V4?
There is no sane person with any understanding of filesystems who could possibly argue that ReiserFS v3 'needs no maintenance' ; even Reiser himself felt the problems were unresolvable, which is why Reiser v4 was started to fundamentally rewrite most of the filesystem to workaround that issue.
I don’t recall anyone arguing that V3 needed no maintenance. Besides, I could be equally critical of btrfs, having had a system end up unbootable, and unrecoverable without a complete repartition/reformat/ reinstall, not once but twice, because btrfs’s default installation parameters (as configured by the openSuSE installer) enabled snapshots to use up all available disk space, and there were no (working) tools available to fix it. THAT is ridiculous and abhorrent behaviour and anyone who entrusts their data to a filesystem that does that is equally insane (IMHO). There should at least be a warning if btrfs is installed during installation, stating, “Warning - you’ve selected btrfs which will eat up all usable space on your root partition if you don’t fix the settings, because our installation defaults are broken by design.”
[...] And sure, some die-hard volunteers are maintaining Reiser v4, but it has not been merged into the mainline Linux kernel. And it is unlikely to ever do so, because Reiser4 does not follow Linux coding standards.
That is a totally different issue.
Do you really want to trust your data to a filesystem who's code quality is so poor there is no likelihood of it ever being merged into the Linux kernel?
Falsely affirming the consequent. Not meeting one particular set of coding standards does not necessarily imply poor quality coding. -- ============================================================== Rodney Baker VK5ZTV rodney.baker@iinet.net.au CCNA #CSCO12880208 ============================================================== -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org