Bruce FieldsThis is not the world's ugliest web page; honest, there's worse out there.
The easiest way to reach me is by email to bfields at fieldses.org.
I maintain the Linux kernel's NFS server, and work on NFS problems, at Red Hat.
Before mid-July 2010, I worked at the University of Michigan's Center for Information Technology Integration (CITI), on a variety of projects, mainly having to do with NFS version 4.
I have some notes on the linux kernel (work in progress).
My dissertation was written under the direction of Mel Hochster, and is a study of the lengths of modules determined by killing powers of several ideals of a local ring, as a function of the exponents; download a copy of my thesis here.
Also available is a pdf of a Journal of Algebra article based on the thesis, which covers the same material but with some improved proofs.
I've served on the board of the Washtenaw Bicycling and Walking Coalition.
I used to help out a little with Arbor Update.
Other Bruce Fieldses:
I am, however, the only Bruce Fields with a Teeter Talk interview.
Miscellaneous stuff that doesn't belong here:
Various linux/nfs/etc todo's:
- big rpcsec_gss init upcalls
- nfsd4 state problems:
- various callback problems
- In setclientid, allow client to blow away old state (even if credentials conflict) if old state has no open state associated with it?
- Fix open on the server; problems:
- Truncate is handled strangely: we don't set op_truncate at all in the non-create case, and in the create case we only set it if the call sets the size to exactly zero. What happens otherwise? Also, what does MAY_TRUNC really mean?
- Atomicity? What happens if we fail partway through an open? Are their races between concurrent (local and remote) openers?
- Server handles open-upgrades in a weird way, by hanging on to the same struct file and doing a get_write_access if necessary. This causes bugs e.g. when read-open is upgraded to write-open, followed by write-lock.
- krb5p implemntation is ugly; it has unclear requirements from client and
server code, and does a lot of complicated an inefficient things for
obscure reasons. To do:
- summarize client- and server- side requirements, make sure we've accounted for the obvious nits in the current code
- attempt pencil-and-paper design of simpler krb5p API.
- implement incrementally....
- Low priority: at some point, audit mountd for how it handles errors from the filehandle nfsctl(s)--I'm not sure it takes into account the fact that exp_parent can fail?