[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[Dazuko-devel] Re: DazukoFS
From: |
tvrtko . ursulin |
Subject: |
[Dazuko-devel] Re: DazukoFS |
Date: |
Fri, 23 Feb 2007 17:01:24 +0000 |
John Ogness <address@hidden> wrote on 23/02/2007 16:27:29:
> Tvrtko Ursulin wrote:
> > [another resend to you John privately - any idea why my messages are
not
> > appearing on the mailing list while I receive ML traffic OK?]
>
> Your email address is listed as subscribed to dazuko-devel. Do you get a
> bounce message? If yes, could you send it to me?
Didn't get it. And this only came directly and hasn't showed up in the
mailing list. Maybe the server is down, I don't know how reliable savannah
is except that I was unable to access the CVS server a few weeks ago.
> > After all, data is available in the dazukofs_open call,
> > no? So I quickly started experimenting and cooked a patch (attached)
which
> > tries to do exactly that. It looks like it works, you tell me if
> something is
> > wrong with that approach.
>
> Well, yes, it does work. However, it uses the d_path() function. One of
> the advantages of DazukoFS is that we can get away from the d_path()
> function. The problem with this function is:
>
> 1. it is quite expensive
>
> 2. it is useless for chroot environments
>
> 3. we need to grab the root node to notice if we are in a chroot
environment
I agree with all the above points. And not to mention private
namespaces...
> 4. __d_path() would allow us to get around #2, but it is not re-entrant
> safe and it is not exported to modules
What exactly do you mean with re-entrant safe?
> By using its own pseudo names, Dazuko can allow an application to access
> file content immediately without expensive filename lookups. For
> applications such as on-access scanners, this can have significant
> performance improvements. (After all, on-access scanners rarely care how
> the file is actually named.)
Interesting approach, thanks for the explanation. Stuff below deleted -
everything does make sense so my curiousity is satisfied. :)
The only remaining problem will be hot to handle removable devices and new
mounts in general. I don't see a completely secure solution for that with
stackable filesystem only approach, right?
Tvrtko
Sophos Plc, The Pentagon, Abingdon Science Park, Abingdon,
OX14 3YP, United Kingdom.
Company Reg No 2096520. VAT Reg No GB 348 3873 20.