> >> In my opinion the non-inclosure in the mainline kernel is the most
> >> important reason not to use XFS (or any other FS). Which in turn
> >> massively reduces the tester base. It is a shame, because for some
> type
> >> of applications it performs great, or better than anything else.
> >
> >
> >On the other hand, filesystem corruption bugs are one of the worst type
> >to suffer from. We absolutely don't want to include filesystems
> >without at least a reasonable proven track record in the mainline
> >kernel, and therefore encourage the various distributions to use them,
> >incase any bugs do show up. Look how long a buffer overflow existed in
> >Zlib unnoticed.
>
> If enclosure in "major" distribuitons defines mainline for you, I have
> to agree. Otherwise, how do you get "a proven track record in
> mainline" without having it in the mainline kernel ? :-)
Sorry, I meant we should be wary about what is moved from being development code to non-development code in the stable kernel.
> In any case, one could always mark XFS as "experimental" for some time.
Exactly, I think we should.
The distributions will 'mirror' that, by including support, but not making it obvious unless you poke around looking for it - so it gets the new feature out to the more users, but doesn't present it as just another option for newbies to select without realising what they are doing.
> >EXT2 is a very capable filesystem, and has *years* of proven
> >reliability. That's why I'm not going to switch away from it for
> >critical work any time soon.
>
> sure, if you can live with the fsck time on your 200 GB (or bigger)
> filesystem after the occasional crash.
But Linux doesn't crash... :-)
John.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
This archive was generated by hypermail 2b29 : Sun Sep 15 2002 - 22:00:29 EST