On Wed, Jan 01, 2003 at 05:30:56PM -0500, Jan Harkes wrote:
>
> Cool, you found it. CODA_STATFS is actually a relatively recent
> addition.
Sweet.
> Hmm, I should look at the source again, why 'coda_nb_statfs'... would
> the 'nb' stand for 'non-blocking?'
I took the 'nb' to be a NetBSD specific
Why can't we just refrain from doing the stat at mount time, and do it
on demand when it is actually needed, with a variable to record
whether the stat info is valid (or time of last stat, if we want to
avoid calling more than once a second and get fancier).
I can't explain why, but it strikes me
On Fri, Jan 03, 2003 at 10:04:13AM -0500, Greg Troxel wrote:
> I can't explain why, but it strikes me that having to fork for the
> mount call is at least somewhat bletcherous. Other processes blocking
Now if venus was just handling upcalls coming in on /dev/cfs0, and mount
was the normal mount(8
Good point. I had forgotten that it was odd not to have an fstab
entry in the first place. Looking at the arla startup script, it
loads kernel modules (coda is static in the kernel, so that's not
needed), mounts /afs with 'mount_xfs', and then starts arlad.
Two points arise: mount_xfs is called
