We welcome involvement from new people. If you're interested in becoming involved in XFS development we recommend joining the mailing list, and the #xfs IRC channel on irc.freenode.net.
There are always more things we could do to enhance XFS in new and interesting ways. Here's a few ideas for people interested in contributing development time. Feel free to contact the XFS maintainers for further details on any of these items (or any of your own ideas, of course).
The XFS commands packages (acl, attr, xfsdump and xfsprogs) have all been internationalised. A number of translations (localisations) have been provided on the messages produced by these packages and translations of the message catalogues to additional languages (e.g. attr/po/attr.pot) are welcome.
The Linux 2.6 block layer rework has opened the door for us to implement an even more efficient regular file I/O path in XFS. In particular if we rewrote parts of the XFS file I/O path to go "direct-to-bio" using interfaces like mpage_readpages and mpage_writepages we could issue the I/O more efficiently. The mpage interfaces are not quite usable for XFS at the moment, they are missing a mechanism for notifying the filesystem on I/O completion, and a get_blocks_t (extent) based interface - like the generic direct I/O code now uses - instead of the current (single block based) interface.
The core of XFS supports this already (since XFS originally came from a platform which supports this, as many do), the missing pieces here are changes to the generic Linux infrastructure code and changes to the Linux XFS I/O path to enable this. The first item above would probably be the first step towards implementing this.
The Linux software RAID5 implementation performs poorly when different sized (and unaligned) I/O requests are issued by a filesystem. The default XFS mkfs geometry uses 512 byte sectors, a 4 kilobyte blocksize, and a version 1 log format. A much more appropriate default would have the sector size matching the block size. When that equates to a filesystem blocksize greater than 512 bytes, a suitably aligned version 2 log should also be selected automatically. The libdisk library which the XFS mkfs utility uses knows when its operating on software RAID5 already...
The code is complete and rudimentary testing passes. Needs more extensive stress and performance testing though.
The initial XFS kernel code exists to support quotas on realtime subvolumes, but further debugging and testing of the kernel code is necessary.
Userspace support is now complete in the form of xfs_quota(8).
The XFS kernel code supports enforcement of quota after a number of warnings have been issued (in addition to the usual "time limit" model that all quota systems implement). Further testing and possibly debugging of the kernel code is required.
Userspace support is now complete in the form of xfs_quota(8).
For historical reasons, XFS has its own implementation of ACLs which is separate to the generic Linux kernel implementation. It would be good to unify these (basically, make XFS work using the generic ACL code). A paper was published awhile back suggesting that we may get slightly better performance in XFS from the additional caching which the generic code provides too.
Some NAS vendors have extended the XFS ACL code to introduce new additional ACL permissions (delete, chmod, and chown permissions, in addition to read, write and execute). This allows XFS semantics to match more closely with those that Samba can make available to CIFS clients.
We could add this feature via a kernel option (configurable, defaulting to off probably, since this is above and beyond the POSIX draft specification for ACLs). The right way to implement it is on top of the generic ACL code though, and convert XFS to use that. This will also require extensions to the userspace (acl) tools. If we also used a superblock feature flag for this feature, it would give us an opportunity to increase the maximum number of ACL entries supported beyond 25 as well (if that flag is set) - which is occasionaly requested - without breaking backward compatibility with existing filesystems.
Be prepared for alot of work! The FreeBSD port has come a long way though, their progress can be tracked via the independent XFS for FreeBSD website.
The userspace tools are relatively straightforward, the kernel code (buffer and page cache interfaces, vfs and vnode interfaces, etc) are where things get difficult, especially when contemplating support for the more unique XFS features (delayed allocation, etc). But, its all good clean fun!