Re: DiskDevice API v2.1
"Ingo Weinhold" <bonefish-CFLBMwTPW48UNGrzBIF7/[email protected]>
| Newsgroups | gmane.os.openbeos.storage |
|---|---|
| Message-ID | <20572586265-BeMail@graete> |
Tyler Dauwalder <tyler-cyCl/[email protected]> wrote: > On 2003-04-05 at 08:00:25 [-0800], Axel D=3DF6rfler wrote: > >=3D20 > > Tyler Dauwalder <tyler-cyCl/[email protected]> wrote: > > > > > We will also need some kind of overhead or better a spare > > > > > partition > > > > > for > > > > > the partition meta data in R2. That includes things like how > > > > > the > > > > > partitions have to be mapped during a move operation, but > > > > > also > > > > > informations about the RAID setup or similar things. > > > > I like that idea. > > > Initially, I'd say I don't like the idea. However, I mostly just > > > don't > > > like the messiness of having an extra partition floating around. > > > For > > > example, I hate having to make separate linux swap partitions. > > > But > > > that's just a personal dislike. That being said, I recognize the > > > advantages it could bring. > >=3D20 > > Yes, I have the same problems with it - especially because there > > are > > only 4 primary partitions on the PC. > > But the advantages it bring cannot be achieved otherwise (at least > > I > > don't see a way). > > We should all think very hard about it and maybe we'll come up with=3D > 20 > something. ;-)=3D20 We could simply use disk space not assigned to any partition, but I don't think, that's a good idea. Furthermore, there is the possibility to use a logical partition instead of a primary one. This might restrict the options a bit, but at least no primary partition is wasted. > > > > > It probably won't be possible to write this information down > > > > > to > > > > > an > > > > > existing file system. > > > > Right. > > > My one question is, couldn't a special file referenced from the > > > BFS > > > superblock be used=3D3D3F Or is that too much overhead to get at > > > the > > > necessary data=3D3D3F I guess that also wouldn't allowing booting a > > > RAID > > > partition, but... > >=3D20 > > If that data would lie on the boot partition, you would not be able > > to > > resize or move that partition as well. And yes, RAID wouldn't be > > possible as well. Well, for software RAID you'll never get a around using a partition on a non-RAID disk (unless the BIOS supports it ;-). 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. What's the benefit=3F I believe, then resizing and moving the boot partition is possible, too. Resizing should be no problem at all, moving is a bit more difficult, but managable, I think. > >=3D20 > > Without an extra partition, the boot partition could only be > > resized/ > > moved off-line, as with Windows :-) > > Actually, PartitionMagic allows online enlarging now of the boot=3D20 > partition. :-) Journalled=3F Could you please try and turn off power while resizing. ;- )) > > > > would > > > > need to > > > > be extended vastly. It would incorporate the functionality > > > > currently > > > > implemented in the registrar, plus support for locking, > > > > managing > > > > jobs > > > > and the like. > > > >=3D20 > > > > I'd like to write up a design draft for that part, so that we > > > > have > > > > something more concrete to discuss about. > > > Great! I was about to bring that up, but now I can sit back and > > > relax. > > > :-) Damn, I should have waited till you propose to do it. ;-) Anyway, I'm afraid, I won't be able to finish it today. Especially not, if this email `battle' continues. ;-) CU, Ingo