On Tue, 2004-08-24 at 10:22 -0600, Stephen J Smoogen wrote: > Naoki wrote: > > This had to be asked sooner or later. Any plans on reiser4, or do we > > wait until it's in the standard kernel? > > > > Since Fedora is trying to aim for no extra patches.. :) I think it is an > upstream issue.. > > I'm sure the ultimate question is: when/if it makes it to the stock kernel, does Fedora begin to support it? There are those camps that feel that RedHat has some agenda against reiserfs3/4 for some reason and intentionally crippled it in the past so people wouldn't use it. Myself, I doubt that. Having followed Reiser4 development for some months now (hey, the marketing makes it sound really slick!), I definitely have come to many reservations before I would go anywhere near it with important data. While I'm not trying to start any kind of flame war, things that make the hair on my neck stand up are the fact that when they tried to move their production Apache box to Reiser4 a few months back, it wouldn't go due to (IIRC) a send_file issue between Apache and reiser. For a long time, their equivalent of fsck did nothing at all (that's pretty much exactly what it said when you ran it). From what I see, fsck's aren't supposed to be as critical with reiser as some other filesystems, but they could certainly have had it do some basic checks or something instead of failing all of the time (which naturally borked initscripts....). Anyway, everyones mileage may very but I would advise not considering 1.0 to be 1.0. Consider it much more of a "ok, it's out there and seems to work for certain people in certain situations...." Let it simmer for a bit and follow it's progress through the -mm kernels before you put it in a test environment. Wait even longer before going production. This may sound like I'm rather negative on it, which I'm not. If it works as well as it is advertised, it's some seriously cool s&*t and I'd love to be a major user of it. I just prefer to let the core kernel guys muck through it and poke out the holes in it before I come to rely on it. Hopefully for all the ensuing traffic will be productive on not become useless bickering. -- David T Hollis <dhollis@xxxxxxxxxxxxxx>
Attachment:
signature.asc
Description: This is a digitally signed message part
