Ceph distributed file system client for 2.6.33
in [Kernel]
|
Prev: perf record: We should fork only if a program was specified to run
Next: build issue #36 for v2.6.33-rc1 for drivers/char/ipmi/ipmi_si_intf.c
From: Sage Weil on 21 Dec 2009 11:50 On Sat, 19 Dec 2009, Valdis.Kletnieks(a)vt.edu wrote: > On Fri, 18 Dec 2009 12:54:02 PST, Sage Weil said: > > I would still like to see ceph merged for 2.6.33. It's certainly not > > production ready, but it would be greatly beneficial to be in mainline for > > the same reasons other file systems like btrfs and exofs were merged > > early. > > Is the on-the-wire protocol believed to be correct, complete, and stable? How > about any userspace APIs and on-disk formats? In other words.. > > > > The git tree includes the full patchset posted in October and incremental > > > changes since then. I've tried to cram in all the anticipated protocol > > > changes, but the file system is still strictly EXPERIMENTAL and is marked > > Anything left dangling on the changes? The wire protocol is close. There is a corner cases with MDS failure recovery that need attention, but it can be resolved in a backward compatible way. I think a compat/incompat flags mechanism during the initial handshake might be appropriate to make changes easier going forward. I don't anticipate any other changes there. There are some as-yet unresolved interface and performance issues with the way the storage nodes interact with btrfs that have on disk format implications. I hope to resolve those shortly. Those of course do not impact the client code. sage -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo(a)vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
From: Andreas Dilger on 21 Dec 2009 13:10 On 2009-12-21, at 09:42, Sage Weil wrote: > I think a compat/incompat flags mechanism during the > initial handshake might be appropriate to make changes easier going > forward. Having compat/incompat flags for the network protocol, implemented correctly, is really critical for long term maintenance. For Lustre, we ended up using a single set of compatibility flags: - client sends full set of features that it understands - server replies with strict subset of flags that it also understands (i.e. client_features & server_supported_features) - if client doesn't have required support for a feature needed by the server, server refuses to allow client to mount - if server doesn't have feature required by client (e.g. understands only some older implementation no longer supported by client), client refuses to mount filesystem We've been able to use this mechanism for the past 5 years to maintain protocol interoperability for Lustre, though we don't promise perpetual interoperability, only for about 3 years or so before users have to upgrade to a newer release. That allows us to drop support for ancient code instead of having to carry around baggage for every possible combination of old features. Using simple version numbers for the protocol means you have to carry the baggage of every single previous version, and it isn't possible to have "experimental" features that are out in the wild, but eventually don't make sense to keep around forever. Cheers, Andreas -- Andreas Dilger Sr. Staff Engineer, Lustre Group Sun Microsystems of Canada, Inc. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo(a)vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
From: Craig Dunwoody on 27 Dec 2009 19:20
sage weil writes (2009/12/21): >If you want stability, then it's probably too early to merge. If you >want active users, that essentially hinges on stability too. But if >it's interest in/demand for an alternative distributed fs, then the >sooner it's merged the better. I understand there are many considerations about when to merge something new, but in general would like to see the Ceph client merged sometime soon. In my view, there is a wide range of applications for which Ceph has the potential to be significantly more efficient than the other distributed file systems that I know about. Ceph has a solid architecture and a small but strong dev team. I believe that the project is now at a point where wider-scale testing can greatly accelerate progress toward production-level usability. Having the client in mainline will help reduce barriers to such testing. Craig Dunwoody GraphStream Incorporated -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo(a)vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/ |