site_archiver@lists.apple.com Delivered-To: darwin-kernel@lists.apple.com On Apr 30, 2007, at 10:41 PM, Shailesh Parulekar wrote: = Mike _______________________________________________ Do not post admin requests to the list. They will be ignored. Darwin-kernel mailing list (Darwin-kernel@lists.apple.com) Help/Unsubscribe/Update your Subscription: http://lists.apple.com/mailman/options/darwin-kernel/site_archiver%40lists.a... About, need of our product:: At a very high level, I wish to intercept the I/Os (essentially Writes) made to a set of files and store the changes in my secondary storage so that in the event of machine crash user should be able to reconstruct his/her files with the help of the product. In general terminology it is Continuous Data Protection (C.D.P.) My intention is to track the block changes that happen to the files and have my meta data pointing to the old (changed) blocks so that I get to construct various versions of the files from my meta data. Are these files specifically managed by applications that are aware of the presence of your product, or is it your intention that the product work with data files maintained by any application? If the former, this sounds like something best handled with a framework or plugin in user space. Otherwise, how do you intend to determine when a file is in a consistent state? If you were to make the simplistic assumption that all file write operations are transactions bracketed by open/close pairs, then the easiest approach is just to catch the last close on a file using the kauth FILEOP scope and replicate it wholesale. If you are trying to provide CDP in the case of files that are open for long periods of time by applications that are not transactional and assume a reliable filesystem, then you are already in an impossible situation; there is no way for you to determine when a file is in a consistent state. Data is not necessarily retired to files in program order. Sensible applications that hold files open for long periods of time tend to enforce some degree of transactionality by the use of the F_FULLFSYNC fcntl. You may have to do some work to detect this at the vnode layer. As and when plans are crystallized I will have more concrete questions to chalk down. For now I just need to get started with the Mac OS X Internals and think of possible avenues to meet my requirements. Definitely start with Amit's book. There is not a supported mechanism for filtering vnode operations to filesystems, so your approach may have to vary depending on which filesystem(s) you plan to support. Patching the vnode table is not viable. This email sent to site_archiver@lists.apple.com