Mailing Lists: Apple Mailing Lists

Image of Mac OS face in stamp
 
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re[4]: Intercepting file system calls (read, write, open, close, etc)



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:
http://lists.apple.com/mailman/options/darwin-dev/email@hidden

This email sent to email@hidden

References: 
 >Re: Re[2]: Intercepting file system calls (read, write, open, close, etc) (From: Mike Smith <email@hidden>)



Visit the Apple Store online or at retail locations.
1-800-MY-APPLE

Contact Apple | Terms of Use | Privacy Policy

Copyright © 2007 Apple Inc. All rights reserved.