Re: DiskDevice API v2.1

"Axel Dörfler"  <[email protected]> wrote:
> "Ingo Weinhold" <bonefish-CFLBMwTPW48UNGrzBIF7/[email protected]> wrote:
[...]
> > > That seems like a good idea. Though why not in a file: the access 
> > > overhead, or contiguity, or...? If it were a setting at 
> > > initialize 
> > > time, you could certainly guarantee a contiguous chunk.
> > Firstly, I wouldn't see the benefit of a file, if you have to 
> > create 
> > it 
> > at initialize time and can't change its size later on. Secondly, 
> > there 
> > is a good chance, that you have to move that file, when you're 
> > resizing 
> > the partition. If you place it at the beginning of the data space, 
> > you 
> > might have to move it, when the partition is enlarged (the bitmap 
> > will 
> > grow). And otherwise you might have to move it, when the partition 
> > is 
> > shrunk.
> 
> A file wouldn't work - for example, in case of a sudden system death, 
> you would still need to be able to load that data. And a file or any 
> data on that partition might have been cut in half at that moment.
> You wouldn't be able to load the boot loader, nor to extract the data 
> about how the partition structure currently looks.

I think, it should be possible to ensure, that at no point in time, the 
meta data are not available as a contiguous chunk. E.g. if the data 
have to be moved (due to moving the partition or resizing it), I would 
first establish the data in the new place, then change the pointer from 
the old to the new location, and then do whatever else needs to be done 
(logging to the new location from that time on).

BTW, the same problem occures, when you have a meta partition and move 
it.

CU, Ingo