> About a year ago I attended a Linux Expo where the XFS filesystem was
> demonstrated (and it was impressive). At the time it was still being
> "unencumbered", so I was unable to do anything with it. I'm now in the
> process of trying to load a new machine, but find the patches haven't
> kept up with newer kernel releases. I'm using SMP x86 which has had a
> number of kernel changes which fix problems which were serious enough
> that I can't see using the 2.4.2 or 2.4.3 kernel with, and want to
> instead use the 2.4.5 kernel. Of the available patches, 2.4.5 works
> completely with the patch "linux-2.4-xfs-1.0.patch", but the 2nd patch,
> "linux-2.4.3-core-xfs-1.0.patch", fails in several places on 2.4.5
> source (regardless of whether linux-2.4-xfs-1.0.patch is applied first
> or 2nd). Normally I would be willing to test something like this out to
> see if the failed chunks will cause failure, but with a filesystem, this
> leaves me nervous.
There should be a later set of patches for populating a cvs tree, then
you can get our changes faster. I would tell you where, but various
parts of oss seem to be out to lunch this weekend.
>
> My hopes are that XFS can make its way directly into the kernel source,
> even if it is marked as "experimental". Until then, the next best thing
> would be new patches becoming available very quickly after a new kernel
> is announced. Can anyone give me an estimate on when a patch suitable
> for 2.4.5 kernel will be available? Is there any kind of announcement or
> devel email list I can join to track XFS development?
The reason we do not have instant patches available after a release comes
out is that we have about 40 files in that core patch, which touch things
like the VM in minor ways. Sure I could put out a patch in about 2 hours
from downloading Linus's latest version, but it would come with zero
testing, and would end up generating more work for us than doing some
testing before we put out a new version. Since you are nervous about
fixing diff conflicts yourself, consider yourself multiplied several
thousand times complaining that we got something wrong in the latest
version of the code.
>
> Thanks,
> D. Stimits, stimits@xxxxxxxxxx
Steve
|