site_archiver@lists.apple.com Delivered-To: darwin-kernel@lists.apple.com Hi, This is a hard nut to crack on UNIX-style systems. - Here's the documentation he probably wants: And here's sample code for one: -- Terry _______________________________________________ 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... On May 1, 2007, at 7:30 AM, Andreas Fink wrote: On 01.05.2007, at 10:18, Anton Altaparmakov wrote: On 30 Apr 2007, at 23:33, John Davidorff Pell wrote: This sounds much like you're trying to add full journaling to HFS +. Is this a fair characterisation? I don't think so. He is effectively describing what Leopard's Time Machine or Legato's Networker backup solution provide (implemented differently) so they seem to be reinventing the wheel somewhat... ... a wheel which was invented ages ago on Digital's VMS filesystem. File versioning. The primary problem is that this worked for VMS because VMS did globbing in the kernel, rather than in user space in the shell. Add to that that Files-11 is a record oriented rather than byte-stream oriented, so you could share records between various versions, with minimal data replication. This combination of factors is why most attempts at supporting versioning in FS's on UNIX-style systems hasn't been very satisfying; it's nearly impossible to get the implied "most recent version" version number semantic right without pushing the version suffix matching down into the kernel, and even so, you are stuck with copying around whole files. CDP is an interesting idea (even more interesting if you happen to sell storage systems that you want people to need... 8^)), though almost all implementations I'm aware of that try to implement what they call "real CDP" as opposed to snapshots or something similar ("near CDP") have application specific knowledge. This solves the data atomicity problem: all of your data is consistent across the snapshot at any given time, and as long as you use standard data integrity techniques, like two stage commits with intention logging, you can replicate and recover all of your state. General practical use is for very expensive to lose data, plus replication, either for HA, or for off-site data safety. I think for what Shailesh wants to do, he's going to be writing his own block storage driver, rather than putting in a shim; it's more akin to implementing a software RAID solution than it is snapshots or versioning. The only way that's going to work is if he owns the read disks and exports something that looks like a real disk to the OS. Basically, he's both a consumer of an IOMedia object, and a producer of IOMedia objects; on Mac OS X, this is called a "filter-scheme driver". <http://developer.apple.com/documentation/DeviceDrivers/Conceptual/MassStorag...

<http://developer.apple.com/samplecode/SampleFilterScheme/index.html#//apple_...

The downside is going to be that he's going to have a hard time slapping this on top of a running system, without effectively taking over direct management of the disk, and if he's doing this for HFS, to do something like directory folding or file hiding for his magic metadata will mean understanding a lot more about the structure of HFS than maybe he wants to. This email sent to site_archiver@lists.apple.com