Re: DiskDevice API v2.1

"Ingo Weinhold" <bonefish-CFLBMwTPW48UNGrzBIF7/[email protected]> wrote:
> > 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).

If it's the boot partition, there are some more issues, like the 
bootloader, and the whole file system at this point.
But in some point your right, since even with a spare partition, the 
boot loader would have to be able to locate drivers from that 
partition, and thus needs a basic understanding of the data in that 
partition.
Hm, perhaps we can make it a requirement only for the RAID case, but 
it's more work for sure (and might need more file system functions). 
We'll see.
I will first have a look how the file system API should look like to 
support all of this functionality, then it'll probably be clearer.

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

Yes, and that's why the meta partition isn't intended to move ever. It 
would rather be recreated at a new location (say, another disk), than 
moved.
I don't exactly see the need to move that partition around, though. It 
should always be located at the end or beginning of a disk.

Adios...
   Axel.