Return to contribute.html CVS log

Up to [Development] / xfs-website

Update some docs to reflect current XFS capabilities.

<& xfsTemplate,top=>1,side=>1 &>

<h2><b><FONT FACE="ARIAL NARROW, HELVETICA" SIZE="5">How to contribute</FONT></b></h2>

<p>
We welcome involvement from new people.
If you're interested in becoming involved in XFS development
we recommend joining the <a href="mail.html">mailing list</a>,
and the <b>#xfs</b> IRC channel on <i>irc.freenode.net</i>.
</p>

<p>
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).
</p>

<ul>
<li>
<b>Address the 16 Terabyte Filesystem Limitation</b>
<p>
Filesystems have a 16 terabyte size limitation on Linux 2.6 for
32 bit platforms.  There is no such limit for 64 bit platforms,
but there are a couple of ways we could lift this restriction for
32 bit platforms as well.
</p>
</li>

<li>
<b>Additional Performance Tuning</b>
<p>
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
&quot;direct-to-bio&quot; using interfaces like <i>mpage_readpages</i>
and <i>mpage_writepages</i> 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.
</p>
</li>

<li>
<b>Block Sizes Larger than the Page Size</b>
</li>
<p>
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.
</p>
</li>

<li>
<b>Default <i>mkfs</i> Geometry for Software RAID5</b>
<p>
The Linux software RAID5 implementation performs poorly
when different sized (and unaligned) I/O requests are issued
by a filesystem.
The default XFS <i>mkfs</i> 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 <i>libdisk</i> library which the XFS <i>mkfs</i> utility uses
knows when its operating on software RAID5 already...
</p>
</li>

<li>
<b>Realtime Subvolumes</b>
<p>
The code is complete and rudimentary testing passes.
Needs more extensive stress and performance testing though.
</p>
</li>

<li>
<b>Quotas on Realtime</b>
<p>
The initial XFS kernel code exists to support quotas on realtime
subvolumes, but further debugging and testing of the kernel code
is necessary.
<b>
Userspace support is now complete in the form of <i>xfs_quota(8)</i>.
</p>
</li>

<li>
<b>Quota Warning System</b>
<p>
The XFS kernel code supports enforcement of quota after a number of
warnings have been issued (in addition to the usual &quot;time limit&quot;
model that all quota systems implement).  Further testing and
possibly debugging of the kernel code is required.
<b>
Userspace support is now complete in the form of <i>xfs_quota(8)</i>.
</p>
</li>

<li>
<b>Generic ACL Implementation</b>
<p>
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.
</p>
</li>

<li>
<b>Extended ACL Permissions</b>
<p>
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.
</p>
<p>
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.
</p>
</li>

<li>
<b>Ports to Other Platforms</b>
<p>
Be prepared for alot of work!
The FreeBSD port has come a long way though, their progress can be
tracked via the independent
<A HREF="http://people.freebsd.org/~rodrigc/xfs/">XFS for FreeBSD</A>
website.
</p>
<p>
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!
</p>
</li>

</ul>

<br>
<br>

<& xfsTemplate,bottom=>1 &>