Re: fixing the vnode lifecycle

2013-09-25 Thread J. Hannken-Illjes
On Sep 22, 2013, at 5:28 AM, David Holland dholland-t...@netbsd.org wrote: snip First, obviously the vfs-level vnode cache code should provide vnode lookup so file systems don't need to maintain their own vnode tables. Killing off the fs-level vnode tables not only simplifies the world but

Re: fixing the vnode lifecycle

2013-09-25 Thread Brett Lymn
On Wed, Sep 25, 2013 at 02:33:43PM +0200, J. Hannken-Illjes wrote: On Sep 22, 2013, at 5:28 AM, David Holland dholland-t...@netbsd.org wrote: snip First, obviously the vfs-level vnode cache code should provide vnode lookup so file systems don't need to maintain their own vnode tables.

Re: fixing the vnode lifecycle

2013-09-25 Thread Mouse
Expect some file systems to use a key size != sizeof(ino_t) -- nfs for example uses file handles up to 64 bytes. IIRC all file systems provide a filehandle generation routine, There was a time when fh generation was needed only for the filesystem to be NFS-exportable. Is it now actually

Re: high load, no bottleneck

2013-09-25 Thread Emmanuel Dreyfus
Emmanuel Dreyfus m...@netbsd.org wrote: async Assume that unstable write requests have actually been committed to stable storage on the server, and thus will not require resending in the event that the server crashes. Use of this option may

Re: high load, no bottleneck

2013-09-25 Thread Paul Goyette
On Thu, 26 Sep 2013, Emmanuel Dreyfus wrote: Emmanuel Dreyfus m...@netbsd.org wrote: async Assume that unstable write requests have actually been committed to stable storage on the server, and thus will not require resending in the event that the server