On Thu, Feb 02, 2006 at 02:30:07PM +0200, Silviu Marin-Caea wrote:

On Thursday 02 February 2006 12:38, Marcel Hilzinger wrote:

...

According to https://bugzilla.novell.com/show_bug.cgi?id=140935 reiser4 has been dropped for 10.1.

I can understand, that you drop unmaintained code from the kernel, but I can not understand, why you drop new features.

Hmm, this is regretable, my intention was to use reiser4 with 10.1.

From what I've seen in the bugreport, it doesn't look like it's going to be in 10.2 either, not before it's in the vanilla kernel.

Olaf Kirch:

...

We have no intention of adding reiser4 at this time. We are seriously cutting down on the number of out of tree kernel code we include in our product.

I guess that not having Hubert Mantel around kind of SUCKS HARD DOESN'T IT??

Congratulations to the select Novell management Gnome-pushing-morons that drove him away.

And now I'm gonna stick my head out the window to chill.

I am really wondering why you think it will make things work better for you. Just because it is new and shiny? We will alos be offering a nice and easy method of adding external kernel modules. Perhaps this is an option for reiser4 for someone else to step up ;) Ciao, Marcus

Am Donnerstag, 2. Februar 2006 13:33 schrieb Marcus Meissner: [...]

I am really wondering why you think it will make things work better for you. Just because it is new and shiny? Yes. And because it's fast, with small files it's much faster than any other filesystem.

We will alos be offering a nice and easy method of adding external kernel modules.

Perhaps this is an option for reiser4 for someone else to step up ;) Sounds interesting. Any details? -- Mit freundlichen Grüßen, Marcel Hilzinger

Linux New Media AG Süskindstr. 4 D-81929 München Tel: +49 (89) 99 34 11 0 Fax: +49 (89) 99 34 11 99

On Thursday 02 February 2006 15:39, Marcus Meissner wrote:

http://www.suse.de/~agruen/KMPM/

(CODE 9 refers to SLES 9 , CODE 10 to 10.1 / SLES 10).

While a third party kernel module with reiser4 can work, it's not quite the same as if it were in the SUSE kernel. Whenever SUSE will update the kernel (YOU), there's a chance that the third party module will no longer work and the reiser4 filesystem will not be mountable. Suppose the root filesystem is reiser4, that will result in kernel panic "cannot mount rootfs". And since the CD1 from SUSE in rescue mode will not support reiser4, you'd need a driver diskette. I don't have a floppy anymore, can't remember if driver images can be read from usb sticks. Quite a lot of trouble. Enough to drive a good number of people away from testing reiser4. I'll still put up the effort, if there's a rpm with the module.

Hi Robert, On Thursday 02 February 2006 20:09, Robert Schiele wrote:

On Thu, Feb 02, 2006 at 04:58:21PM +0200, Silviu Marin-Caea wrote:

...

On Thursday 02 February 2006 15:39, Marcus Meissner wrote:

...

http://www.suse.de/~agruen/KMPM/

(CODE 9 refers to SLES 9 , CODE 10 to 10.1 / SLES 10).

While a third party kernel module with reiser4 can work, it's not quite the same as if it were in the SUSE kernel.

Whenever SUSE will update the kernel (YOU), there's a chance that the third party module will no longer work and the reiser4 filesystem will not be mountable.

Please read the mentioned paper before pointing to problems that are handled in the paper.

The important mechanisms to ensure, that esp. reiser4 (fs module) will survive a kernel update, are -- according to the paper for CODE10 -- still not finished. Sure, "The dependencies between those packages will ensure that the installed kernel packages math the installed kernel module packages." tells me, that (and please correct me, if I am wrong!) kernel modules, which depend to an kernel package version prior the updated one will be deleted. Will then a system running on reiser4 restart with the new kernel? To my understanding there should be a mechanism to recompile the kernel module package automatically during YOU (or the respective update mechanism).

Robert

Stefan -- Stefan Schmidt Network Manager International University Bremen From RFC 1925: "Good, Fast, Cheap: Pick any two (you can't have all three)."

On 2 Feb 2006 at 14:23, Marcel Hilzinger wrote:

Am Donnerstag, 2. Februar 2006 13:33 schrieb Marcus Meissner: [...]

...

I am really wondering why you think it will make things work better for you. Just because it is new and shiny? Yes. And because it's fast, with small files it's much faster than any other filesystem.

Hi! Because the CPU does the main work. For moderate CPUs and fast I/O systems it's likely to be slower than other systems (from what I've heard). Regards, Ulrich