Re: Info needed for File System Development
Re: Info needed for File System Development
- Subject: Re: Info needed for File System Development
- From: Michael Smith <email@hidden>
- Date: Tue, 1 May 2007 00:42:06 +1000
On Apr 30, 2007, at 10:41 PM, Shailesh Parulekar wrote:
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.
= Mike
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Darwin-kernel mailing list (email@hidden)
Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden