Re: DiskDevice API v2.1

"Ingo Weinhold" <bonefish-CFLBMwTPW48UNGrzBIF7/[email protected]>
Newsgroups gmane.os.openbeos.storage
Message-ID <26257583762-BeMail@graete>
Tyler Dauwalder <tyler-cyCl/[email protected]> wrote:
> On 2003-04-08 at 12:01:21 [-0700], Ingo Weinhold wrote:
> > Tyler Dauwalder <tyler-cyCl/[email protected]> wrote:
[...]
> > > > To store the data on the boot partition is an option, I think. 
> > > > I
> > > > wouldn't use a file, but leave some room for the meta data at 
> > > > the
> > > > beginning. ReiserFS for instance skips the first 64 KB. That 
> > > > would
> > > > be
> > > > space enough for quite a bunch of RAID settings and a small job
> > > > journal. But even 1 MB or so wouldn't hurt. Perfect would be to
> > > > make
> > > > this an option when initializing the volume. Be's BFS add-on
> > > > wouldn't
> > > > be able to read such a volume, but I think, that doesn't matter
> > > > much.
> > > 
> > > 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. 
> 
> Doesn't hurt compatibility w/ BFS.

Ah, right.

> > 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.
> 
> That could be handled gracefully (and contiguously) as well, though.

Sounds more complicated though. In particular because the interaction 
between the system (kernel, disk device manager -- whoever is 
responsible for partitioning) and the FS will be more complex, since 
the FS would move the log file, which itself is a transaction that 
needs to be logged, and while the system is responsible for logging. I 
guess, we need to work on the details before being able to do further 
evaluation. It may be worthwhile to pursue, though.

[...]

CU, Ingo

PS: It looks like I won't finish writing up the kernel ideas today 
either. I had less time, than I was hoping. *sigh*
lmpx.com only provides a reader for public news (NNTP) servers. It is not affiliated with the servers or forums shown here and is not responsible for the content of articles, which is written by their respective authors.