dazuko-devel
[Top][All Lists]
Advanced

[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.





reply via email to

[Prev in Thread] Current Thread [Next in Thread]