Re: XFS

Hi,


On Mon, Oct 25, 2004 at 08:01:16PM +0200, Bogdan Costescu wrote:
> On Mon, 25 Oct 2004, Pasi Pirhonen wrote:
> 
> > I a not trying to hide anything. It's just that David said that he
> > weill collect 'one unified set of SRPMS of U3 arches' to same some
> > space for mirrors. U3 is not released, so there is no SRPMS still.
> 
> OK, my point was about having a unique kernel package (be it for
> x86_64 only if you decide so) that more people can use and therefore
> increase trust in its functionality. I am able to rebuild packages
> myself and I've done some kernel hacking in the past, so I can produce
> such a kernel package. But from this to actually putting it on a
> production machine is a long way, especially with such a complex
> change as XFS. However, if several people use the exact same package
> _and_ share their experience, one can be confident enough at some
> point to put this package on a production machine.

I don't restrict the enhancement 'x86-64 unique only'. David has stated
that he 'don't feel like merging in anything that touches core
codepaths'. XFS does that so it rules it out. I, personally, don't have
such restrictions. That must stay 'case by case'. I won't blindly patch
in 'anything that is just floating around'.

I am actually _very happy_ if you 'start beating' the XFS. More people
willing to do so, more like it can be said to be stable. 

I have been very moderate with this and only XFS itself is enabled as in

CONFIG_XFS_FS=m
# CONFIG_XFS_QUOTA is not set
# CONFIG_XFS_RT is not set
# CONFIG_XFS_TRACE is not set
# CONFIG_XFS_DEBUG is not set

This has been working very well. There is that one liner for dcache.
Before that i did have some missbehaviour thru NFS. Since then i have
not seen any problems. I must have trasferred at lest 100TB worth of
traffic over that driver now.

Initially i took the XFS in to make comparisation about ext3 vs. XFS.
As there IS very easil triggered problem with ext3 (applies to vanilla
2.4-series too tho).

I am not in progress of converting the / or /usr or /var to XFS, but i
really like having my NFS-exports as XFS for just pure performance and
no problems with 'sudden I/O stalls'.



> 
> Maybe my initial message was not clear on this point, so I'll try to
> make it now: I'm not asking for [insert favourite kernel module] to be
> present in the official Tao kernel. I'm only asking if your extra
> kernel (that you said you already made for your own purposes) could be
> made available.

It was clear enought. I made the SRPM available. I have not
intentionally hide this, but as i said, this whole thing is 'in
progress', so there has not been demand for the extra SRPMS still.

> 
> And a question for David: could this list be used also for discussions 
> about these "non-official" kernels (or maybe other packages) ?
> 

The problem being that some of these 'extra features' would likely to be
needed as in 'installation media'. That efectively makes it impossible
to keep those as in /contrib/

It's touch call. Personally past year has opened my eyes more about
this 'Enterprise Linux and it's support'. My goal is more like to make
it more usable for the new hardware redhat won't support. Many people
does want to run this Enterprise Linux on dekstop like systems and
really pay for redhat from big production boxes.

The other packages are like  modified anaconda + hwdata making the clue
for new drivers. adding xfsprogs to distribution etc. needed for the
enhancements.

So basically it being 'all or nothing'. 



-- 
Pasi Pirhonen - [email protected] - http://iki.fi/upi/