Re: [PATCH] cowlinks v2

Davide Libenzi
2004-03-21T20:27:08Z

On Sun, 21 Mar 2004, Jörn Engel wrote:

> On Sun, 21 March 2004 09:59:39 -0800, Davide Libenzi wrote:
> >
> > When I did that, fumes of an in-kernel implementation invaded my head for
> > a little while. Then you start thinking that you have to teach apps of new
> > open(2) semantics, you have to bloat kernel code a little bit and you have
> > to deal with a new set of errors cases that open(2) is not expected to
> > deal with. A fully userspace implementation did fit my needs at that time,
> > even if the LD_PRELOAD trick might break if weak aliases setup for open
> > functions change inside glibc.
>
> 209 fairly simple lines definitely have more appear than a full
> in-kernel implementation with many new corner-cases, yes. But it
> looks as if you ignore the -ENOSPC case, so you cheated a little. ;)

Yes, at that time I preferred to fall back to the caller open(2) if any
error happened during the COW (a more picky implementation would simply
bounce an error to the application). Look BTW that there is a difference
between the error handling when you have an in-kernel solution or a
completely userspace solution. If you push this inside the kernel you have
at least to define a new open(2) flag and a new set of errors that might
arise when doing the COW. You are basically changing the open(2) API. You
have also to "teach" apps to use the new flag, since obviously you cannot
make COW a default behavior. The fl-cow approach let you define a set of
paths where you want COW to happen (in my case typically /usr/src/lk), and
only apps writing to hard-linked files inside such path gets COWed. The
open(2) API does not change. OTOH there is the LD_PRELOAD trick that is
weak alias dependent.

- Davide