Re: Info needed for File System Development
Re: Info needed for File System Development
- Subject: Re: Info needed for File System Development
- From: Terry Lambert <email@hidden>
- Date: Tue, 1 May 2007 10:41:20 -0700
On May 1, 2007, at 7:30 AM, Andreas Fink wrote:
On 01.05.2007, at 10:18, Anton Altaparmakov wrote:
Hi,
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.
This is a hard nut to crack on UNIX-style systems.
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".
Here's the documentation he probably wants:
<http://developer.apple.com/documentation/DeviceDrivers/Conceptual/MassStorage/08_Media_Example/chapter_8_section_1.html#//apple_ref/doc/uid/TP30000739-SW1
>
And here's sample code for one:
<http://developer.apple.com/samplecode/SampleFilterScheme/index.html#//apple_ref/doc/uid/DTS10000432
>
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.
-- Terry
_______________________________________________
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