This is a suggestion for a Google Summer of Code project.

Build a pilot implementation of subfiles in FFS patterned
after Solaris.

Subfiles are looming as an important issue within three
years. NTFS has them (named streams) and NFSv4 contemplates
them (OPENATTR). Extended attributes and subfiles are often
confused, but the momentum is behind subfile largely due to
NTFS. NTFS, Solaris, and NetApp all have subfile
capabilities. Linux and BSD do not, and I suspect their is a
prevailing misperception that extended attributes suffice.

There are four major steps:

1) Implement attropen() which implies
   many other things. This could be done
   as a compatability library (that would
   be helpful) but the final implementation
   should be built on openat().
   * Add two new inode types (subfile directory,
     subfile proper) FFS and stat.h.
   * Add new vnode operations (about 4?)
   * Add new system calls (openat(), et al).

2) Adapt primary file utilities
   * ls (of course)
   * tar (add Solaris 'X' extension, see star also).

3) Adapt Samba. This is the big, cool step.
   NT folders can be viewed as thumbnails.
   What NT does to make that fast is attach
   as a subfile a thumbnail to each image file.
   This is why viewing folders with thumbnails
   is so fast on NTFS and on a Windows file server,
   and why it is so slow on everything else
   where the thumbnails have to be generated
   every time.

4) Unlikely but: Adapt NFSv4 to use the subfiles.

Victory for this project is identifying and raising the
second and third level questions that usually don't present
themselves until an implementation is attempted.

Two months may not be enough time for all four steps, but it
is enough time to make many helpful discoveries.

I believe it is extremely important to follow Solaris lead
on subfiles for a whole pile of good reasons.

More details and refrences here (don't worry about extended
attributes):

    http://www.nasconf.com/pres04/waidhofer.pdf

Regards,
        -gww