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*