linux-kernel - Re: the " 'official' point of view" expressed by kernelnewbies.org regarding reiser4 inclusion

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <20060727172852.GA11321@merlin.emma.line.org>
Date:	Thu, 27 Jul 2006 19:28:52 +0200
From:	Matthias Andree <matthias.andree@....de>
To:	Grzegorz Kulewski <kangur@...com.net>
Cc:	LKML <linux-kernel@...r.kernel.org>,
	ReiserFS List <reiserfs-list@...esys.com>
Subject: Re: the " 'official' point of view" expressed by kernelnewbies.org regarding reiser4 inclusion

On Thu, 27 Jul 2006, Grzegorz Kulewski wrote:

> Sorry for my stupid question, but could you tell me why starting to make 
> incompatible changes to reiserfs3 now (when reiserfs3 "technology" is 
> rather old) and making reiserfs3 unstable (again), possibly for several 
> months or even years is better than fixing big issues with reiser4 (if 
> there are any really big left) merging it and trying to stabilize it?
> 
> For end user both ways will result in mkfs so...

ext2fs and ext3fs, without "plugins", added dir_index as a compatible
upgrade, with an e2fsck option (that implies optional) to build indices
for directories without them.

ext3fs is a compatible upgrade from ext2fs, it's as simple as unmount,
tune2fs -j, mount.

reiserfs 3.6 could deal with 3.5 file systems, and "mount -o conv" with
a 3.6 driver would convert a 3.5 file system to 3.6 level
(ISTR it had to do with large file support and perhaps NFS
exportability, but don't quote me on that).

I wonder what makes the hash overflow issue so complicated (other than
differing business plans, that is) that upgrading in place isn't
possible. Changes introduce instability, but namesys were proud of their
regression testing - so how sustainable is their internal test suite?

Instead, we're told reiser4 would fix this (quite likely) and we should
wait until it's ready (OK, we shouldn't be using experimental stuff for
production but rather for /tmp, but the file system will take many
months to mature after integration) and it will be "mkfs" time - so
reiser4 better be mature before we go that way if there's no way back
short of "amrecover", "restore" or "tar -x".

Smashing out most of the Cc:s in order not to bore people.

-- 
Matthias Andree
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/