Removal of Giant from the VFS layer for 10.0

[ Sorry for cross-posting, but I included -arch_at_ for technical
discussion, -current_at_ for reaching the wider audience and -fs_at_ for the
relevance of the matter.]

During the last years a lot of effort by several developers happened
in order to reduce Giant influence over the entire kernel.
The VFS layer didn't make an exception, as many several tasks have
been completed along the years, including fine-grained locking for
vnodes lifecycle, fine-grained locking of the VFS structure (mount),
fine-grained locking of specific filesystems (UFS, NFS, etc.) and
several locking improvements to surrounding subsystem (buffer cache,
filedesc objects, VM layer, etc.).

While FreeBSD did pretty well so far, a major push is still needed in
order to completely remove Giant from our VFS and buffer cache
subsystems.
At the present time, the biggest problem is that there are still
filesystems which are not properly fine-grained locked, relying on
Giant for assuring atomicity. It is time to make an decision for them,
in order to aim for a Giant-less VFS in our next release.

With the aid of kib and rwatson I made a roughly outlined plan about
what is left to do in order to have all the filesystems locked (or
eventually dropped) before 10.0) and is summarized here:
http://wiki.freebsd.org/NONMPSAFE_DEORBIT_VFS

As you can note from the page, the plan is thought to be 18 months
long, including time for developers to convert all our filesystems and
let thirdy-party producers do the same with their proprietary
filesystems. Also the introduction (and later on removal) of
VFS_GIANT_COMPATIBILITY is thought to stress-out the presence of
not-yet MPSAFE filesystems used by consumers and force a proactive
action.

As you can note from the page, the list of filesystems to be converted
is small and well contained, but there are some edge cases that really
concerns me, like ntfs and smbfs. I took over leadership of ntfs, but
if someone is willing to override myself, please just drop an e-mail
and I'll happilly hand over someone else. About smbfs, I really think
this is really the key filesystem we should fix in the list and it is
time for someone to step up and do the job (including also locking and
reworking netsmb). I knew there was a Google SoC going on this topic,
but didn't have further updates to the matter in weeks.

Ideally, after all the filesystems are locked, what should happen is
to remove all Giant reference from the VFS, as kib's patch present in
the wiki page. If some filesystem is still left for the 1st Semptember
of next year, it is going to be disconnected from the tree along with
Giant axing.

As the locking of filesystems progresses, we can create subsections
for each filesystems including technical notes on the matter. So fare
there is none because the effort is still not started.

The page is also thought to contain technical notes on how to operate
the locking of filesystems, in more general way. I added the msdosfs
example as a reference but other cases may have different problems.
However, as the state of all the filesystems listed in the black page
is a bit unknown, I'd suggest you to first make it work stable and
just in the end work on locking. Also, please remind that locking
doesn't need to be perfect at the first time, it is enough to bring
the filesystem out of the Giant influence intially. Of course, for key
filesystems (smbfs in primis) I'd expect to have full fine-grained
locking support at some point.

During the 18 months timeframe I'll send some reminder and status
updates to these lists (monthly or bi-monthly).
If there is anything else you want to discuss about this plan, don't
hesitate to contact me.

There is one last thing I want to stress out: this type of activities
rely a lot on the audience to step up and make the job. Please don't
expect someone else to fix the filesystem for you, but be proactive as
much as you can, offering quality time for development, testing and
reviews.

Thanks,
Attilio


-- 
Peace can only be achieved by understanding - A. Einstein