On Fri, 14 Nov 2014 14:18:07 Gaudenz Steinlin wrote: > I just think there is not much point in keeping a package that's not updated > and obsolete.
Who would argue with that? ;)
> It was not obvious to me that ceph-dkms is intended to always stay in
> experimental. If it's not intended to ever go into
> unstable/testing/stable I see no problem with the current state.
Depending on situation I think uploading to "unstable" may be potentially
acceptable (in case of serious problem in kernel until fix is available in
mainline). If I ever upload it to "unstable" I will file a bug to prevent
migration to "testing".
> If things really fail miserably I would prefer to have the relevant
> patches in a stable kernel update though. AFAIK the Debian kernel
> maintainers are open to adding backported fixes that are included into
> the upstream kernel in later versions.
Well that's where I think DKMS package could be useful. For example before
3.16 was released I experienced a range of problems from "read errors and
corruption of data in RBD images" to "feature mismatch" with kernel 3.14.
DKMS package helped me to answer questions like
* Is this problem fixed upstream?
* Does the fix work?
* Which fix to backport?
* Is backport feasible or is upgrading to newer kernel is the only option?
Besides early versions of kernels 3.16 had regressions leading to corruption
of data on Btrfs and NFS4 so upgrading was not wise. During this transitional
period when 3.16 was stabilising I could only use RBD with DKMS modules on
3.14.
Now 3.16 is better but I gave up kernel clients (RBD, CephFS) as they are
still not up to my expectations and I have a feeling that kernel clients are
not a priority for upstream and that upstream actively works on new kernels
but not that active on backporting fixes...
--
Best wishes,
Dmitry Smirnov.
---
The more false we destroy the more room there will be for the true.
-- Robert G. Ingersoll, 1902
signature.asc
Description: This is a digitally signed message part.
