- 1 Google Summer of Code: Suggested Project ideas
Google Summer of Code: Suggested Project ideas
The following are the Samba project ideas for Summer of Code. Of course you are free to come up with ideas not listed here. Please discuss the your planned project by either joining us on irc://irc.freenode.net/#samba-technical or by sending email to email@example.com
Some additional possible GSoC topics can be found in Bugzilla in the form of bugs which are marked as "Feature request": here. Questions regarding complexity and requirements should be directed to the technical mailing list.
dbwrap back-end for Ceph RADOS key-value storage
Ceph offers a highly scalable and fault-tolerant storage system. Samba is already capable of sharing data located on the Ceph Filesystem, however scale-out sharing (the same data exposed by multiple Samba nodes) currently requires the use of CTDB for consistent and coherent state across Samba cluster nodes. In such a setup CTDB provides a clustered database with persistent key-value data storage and locking. Database usage is abstracted out via a generic dbwrap interface.
Ceph's librados library provides an API for the storage and retrieval of arbitrary key-value data via the omap functions. A watch/notify protocol is also provided as a mechanism for synchronising client state (locking). Key-value data stored in the RADOS back-end inherits the same redundancy features as regular objects, making it a potentially good candidate as a replacement for CTDB in scale-out Samba clusters.
Alternatively, the RocksDB key-value store includes a Ceph librados back-end, which could perhaps also be plumbed into dbwrap. Doing so would however require architectural changes, to ensure that the RocksDB database is only consumed by a single process on each node.
This task involves the implementation and testing of a new dbwrap back-end that uses librados for the storage, retrieval and locking of Samba key-value state. Ideally, the candidate would also allow time for benchmarking, and an investigation of scalability bottlenecks.
- Difficulty: Medium, Hard
- Language(s): C
- Possible Mentors: David Disseldorp
Linux Kernel CIFS/SMB2/SMB3 client improvements
Interested students should contact Steve French (or Jeff Layton) and discuss possible improvements to the Linux Kernel CIFS VFS client. Here are some ideas to get you started:
Add machine-readable debug & stats /proc file
- Stop outputing free format text that breaks all parsers out there everytime we add things to it. Clean up the cifsdebug.c file (its kind of messy). Possibly generate a hierarchy of files (e.g. a dir per tcp connection, subdirs for session, files for tcons). Make a nice native/console/web UI for it.
- Language: C
- Difficulty: Low
Write the One-True-Tool to unify probe/setup/configuration cifs.ko properly
- Too many knobs in different places at the moment: request-keys, idmap, cifscreds, /proc stuff
- Would handle ACL stuff as well (nice gui to get/set)
Improve smbcmp, the capture diff tool
- Use or combine current tshark output with the XML output to do better diffs
- Better UI?
- Language: Python (rewrite in something else is OK)