Bug 164699 - Fedora Core is ReiserFS Hostile
Fedora Core is ReiserFS Hostile
Product: Fedora
Classification: Fedora
Component: kernel (Show other bugs)
All Linux
medium Severity medium
: ---
: ---
Assigned To: Kernel Maintainer List
Brian Brock
Depends On:
  Show dependency treegraph
Reported: 2005-07-30 11:44 EDT by Marc Perkel
Modified: 2007-11-30 17:11 EST (History)
1 user (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 2005-08-02 19:48:17 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)

  None (edit)
Description Marc Perkel 2005-07-30 11:44:22 EDT
From Bugzilla Helper:
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.10) Gecko/20050716

Description of problem:
Isn't it time that Fedora stop treating the Reiser Filesystem like a bastard step child? Reiser has been out for 5 years, solid as a rock, and is the default installation in other Linux disributions. Yet RedHat is openly hostile to this file system making you type in special startup command to attempt to install it and then Fedora has many bugs related to ReiserFS that are caused, I believe, through poor Reiser testing. None of the Reiser related bugs are the fault of the Reiser Filesystem.

In actively excluding Reiser you send a message to the Linux community that RedHat is out of touch with reality and it calls into question if clear thinking is involved in the design process. 

I am an old time RedHat user whoused to actually pay for it when it was reasonably priced. I find the attitude to Reiser offensive and it makes me feel like I can't fully embrace Fedora as a community member. It reduces community support from people like me who would otherwise put more effort into Fedora specifically.

Version-Release number of selected component (if applicable):

How reproducible:

Steps to Reproduce:
1. Install Fedora

Additional info:
Comment 1 Jef Spaleta 2005-08-01 19:34:04 EDT
Are you volunteering to maintain the needed reiser patches to the kernel and
associated tools? RedHat doesn't have infinite engineering resources and they
must prioritize how they allocate the resources.  While you may disagree with
how RedHat is choosing to prioritize resource you have to come to terms with the
fact that resources are limited and RedHat has chosen to support ext3 primarily.
Demanding RedHat re-prioritize resources is not going to get you very far. 

What wlll get you further, is stepping up and proving that community
contributors, like yourself, are able to make the commitment to maintain
alternative filesystems. Please read:

Yes reiser on Fedora could use much more testing.. but there must be manpower to
do that testing and more importantly more manpower to maintaining rieser
specific patches and driving patches back upstream.  The only way reiser is
going to see better support is if a strong community supporter of rieser steps
forward and shows fedora core developers they are dedicated to bringing reiser
inline with the other distribution features. Are you that person?

Comment 2 Marc Perkel 2005-08-01 19:39:01 EDT
If I say yes will you change your position on ReiserFS?
Comment 3 Jef Spaleta 2005-08-01 20:07:22 EDT
I have a position?  You can say whatever you like... the important thing is
showing through action that someone in the community is committed to fixing the
bugs and make reiser work correftly with things such as selinux.  Everyone knows
that there is a segment of the community that desires better reiser support...
but until people come forward and show they are committed to making it work
better the situation isn't going to change.  It takes more than desire.. it
takes someone who can make the commitment and can deal with the software
problems.  People in the community worked to get ppc and x86_64 releases out by
showing they were committed to fixing problems over the long term... its a
matter of showing up and starting to work on the problems instead of demanding
others work on it.

Comment 4 Marc Perkel 2005-08-02 13:03:10 EDT
We aren't going to come forward if we are wasting our time. We would rather work
with other Linux distros that are not Reiser hostile like Novell. All I'm
getting from Fedora/Redhat are lame excuses about why not.

So - I want to hear YES to this question:

If we can provide the community support, will you embrace Reiser? 

I want you to commit to not wasting people's time if we do the work and you have
no intention of including it. What I'm hearing and seeing is that Redhat is
pushing Ext3 and is hostile to other file systems. I want you to confirm that is
not the case.
Comment 5 Dan Carpenter 2005-08-02 13:39:34 EDT
I have some ideas about this.  Let's move this discussion to a mailing list.

Bugzilla is not an appropriate forum.

Comment 6 Dave Jones 2005-08-02 19:48:17 EDT
the kernel has it built, this isn't a kernel issue.

"community support" isn't the answer. The problem is that even its upstream
maintainers don't spend a great deal of time on v3 issues, devoting their time
to their v4 efforts instead.

As a result of this, it lacked things like SELinux support for a long time after
ext3 had support for EA's.  Community support isn't going to fix that. It needs
people familiar with the code, and as its a complicated filesystem, there aren't
a lot of those about.

For reasons like this, I can completely understand why the installer team don't
offer installation on that media by default. Because when it breaks, people
won't take "Tell upstream to implement functionality y" kindly, it's percieved
as a Fedora problem, and frankly, we have more important issues to worry about.

Finally, maintaining reiserfs patches in the Fedora kernel is the wrong way to
go, if it needs fixing, fix it upstream.
Comment 7 Marc Perkel 2005-08-02 19:51:49 EDT
So - why is this a problem for redhat and not a problem for other distributions
that embrace reiser?

Note You need to log in before you can comment on or make changes to this bug.