u-codalist-9wcu_at_aetey.se writes:

> On Mon, Mar 11, 2013 at 10:11:46AM -0400, Greg Troxel wrote:
>> It still doesn't work for static binaries, and it doesn't make system
>> calls work correctly.
>
> This works well for static binaries, as long as you build them against
> right library :) About the correctness of the system calls, what do you
> have in mind? I am happy being non-Posix-ly-correct in many cases
> when Posix is inadequate.

I meant binaries not built against the library.

What I really meant is that there is an existing design, where library
routines are thin wrappers on system calls.  The library intercept
scheme changes that design, and I'm concerned about unintended
consequences (in general, not that I'm articulating them).

>> I would just as soon have a reasonably-efficient FUSE method and drop
>> the native kernel module, and then work to add to FUSE whatever is
>> missing to make it as efficient as the native interface.  There is
>
> Is it possible to skip FUSE overhead of intercepting read/write syscalls?

Not presently.  But the idea of the kernel minicache to have direct
access to a container file is useful for a large class of distributed
filesystems, not just coda, and fuse could be (optionally) enhanced to
support that.

People have been running gluster on NetBSD with GbE and getting
near-wire-speed performance.  So I am not sure the container file
concept is as important as it used to be, at least on fast machines.

Does the library scheme end up with direct access to container files
From the process?

> For me this is a very practical annoyance, as our Coda installer
> weighs about 1.5M, including _all_ dependencies of course.
> Adding python and its dependencies would grow the size several
> times even with a thorough effort to skip as much as possible.

I think what is bothersome is very individual.

>> So one produces a variant of the system libc that intercepts open() and
>> also operations that take a fd?  And either install that, or LD_PRELOAD
>
> Not necessarily. You do not ever install anything which is available in Dapty,
> you just use the stuff available there, including the standard libraries.

"dapty"?

>> it into some programs?  Does open have a step-by-step implementation of
>> namei() that's normally in-kernel?
>
> I am not convinced that namei() has to be reimplemented step by step,
> as it is just a certain kernel's approach to how to implement the semantics.

What I meant is that given "open" and e.g. an absolute path, one has to
be able to traverse the name and know when one is crossing from the
regular vfs system to the intercepted-coda system (and possibly back,
via symlinks).  Normally (on BSD) this traversal is done by namei inside
of the open system call.  So it seems obvious that the open() library
routine (wrapping open(2)) has to do this kind of processing without
just passing the path to the kernel.

>> Have you benchmarked impacts to the system performance when *not* using coda?
>
> You mean how much the interception itself costs for accessing files
> not under /coda ? I have not. I guess this will have to wait until I
> get it working on Linux.

Yes.  That is typically a concern for any system change.

>> > By the way, Ulocoda ported to Linux should be very much usable on NetBSD
>> > too, thanks to LinuxABI. (Even for native NetBSD applications, given
>> > mere a NetBSD library layer to talk to the daemons).
>> 
>> I don't follow this.  How is a regular NetBSD program going to link with
>> a linux libc and run in linux mode?
>
> I meant that the terra and venus daemons and the Linux ABI interception
> layer can be (bit for bit) the same as for Linux. Linux-ABI programs would
> just work, too. NetBSD-ABI programs would have to link to a NetBSD-ABI
> interception layer, otherwise remaning agnostic about the ABI which the
> daemons use.

Thanks - now I see what you mean.

> (I prefer Linux-ABI when possible as it is stable over different Linux and
> *BSD kernels, while a certain *BSD ABI is not guaranteed to be supported
> on a newer *BSD kernel, depending on the actual host setup).

True and I see your point in general.  (But if you include the kernel
compat options, NetBSD does very well at running old binaries.)


I haven't tried to look at the code yet, but I'm hopeful that the
mechanisms to do fileops from the library to a venus can be reused to
have a simple FUSE daemon that uses the same library-like calls to
venus.