Re[4]: Intercepting file system calls (read, write, open, close, etc)
Re[4]: Intercepting file system calls (read, write, open, close, etc)
- Subject: Re[4]: Intercepting file system calls (read, write, open, close, etc)
- From: Igor Shmukler <email@hidden>
- Date: Fri, 19 Nov 2004 10:36:58 +0300
Make,
I want to point out following: this discussion is simlar to "is it possible to develop a high-performance OS in C++"
I do not think it's relevant to darwin-dev any longer.
Stacking is a very powerful obstraction. It enables a more flexible construction of a data flow. In some instances this comes in very handy. If a cost can be kept under 1-2% per layer for a random access, it is usually worth it. However to take advantage of a stackable design one has to explicitly exploit its benefits.
I have some data to support my opinions. Please contact me directly if you would like to talk about this.
Igor.
-----Original Message-----
From: Mike Smith <email@hidden>
To: Igor Shmukler <email@hidden>
Date: Thu, 18 Nov 2004 21:42:49 -0800
Subject: Re: Re[2]: Intercepting file system calls (read, write, open, close, etc)
>
>
> On Nov 18, 2004, at 6:28 PM, Igor Shmukler wrote:
>
> >>>> 1. Try VFS Stacking ? Or over-riding V-node ops ?
> >>>
> >>> Was support for VFS stacking removed? I was warned of such a year or
> >>> two ago, and stopped my VFS efforts at that point (also trying to
> >>> intercept file system calls).
> >>
> >> Stacking filesystems in the BSD model doesn't work very well. It gets
> >> expensive very quickly, and locking can become a nightmare. It's also
> >> often not really what you want; the above is a good example of that.
> >
> > The above being - ?
>
> "also trying to intercept file system calls"
>
> > SunOS is a proof that BSD model and stackable VFS do work well
> > together.
>
> Opinions on that differ to a considerable degree.
>
> > The reason locking in an operating system such as a BSD would
> > problematic is because VFS is very complex.
> > It needed flattening back in 1998 right after VM became stable. Now to
> > support MP kernel locking is more complex than ever. That does not
> > mean that things ought to be this way. Implementing a stackable FS is
> > relatively straightforward if you start from the right place - vnode
> > interface. If done correctly stackable does not create any problems
> > with locking that would not be present in a leaf design.
>
> These are interesting assertions, but without any real application in
> the current
> context. I would caution anyone else reading this that your opinions
> are certainly
> not widely held.
>
> In particular, fan-in, fan-out and partial unwinds are all necessary
> for stacking
> filesystems (if you don't want unwinds, you need reservations which are
> arguably
> worse). Locking these is painful at best, and nesting vnodes is never
> not expensive.
>
> = Mike
>
>
http://Mail.Ru - лучшая почта с неограниченным объемом почтового ящика!
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Darwin-dev mailing list (email@hidden)
Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden