Re: Geom disklabel/fdisk issues?
In message <[EMAIL PROTECTED]>, walt writes: >[EMAIL PROTECTED] wrote: >> Julian Elischer writes: >> >>>I think that one of the things we need to do is declare a new flag in >>>disklabel that declares that the disklabel has been converted to use >>>relative offsets... > >> Better plan: Abandon BSD labels before disks outgrow them. > >To be replaced bywhat? Probably EFI/GPT labels -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 [EMAIL PROTECTED] | TCP/IP since RFC 956 FreeBSD committer | BSD since 4.3-tahoe Never attribute to malice what can adequately be explained by incompetence. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Geom disklabel/fdisk issues?
Julian Elischer wrote: > > > On Mon, 13 Jan 2003, walt wrote: > > > [EMAIL PROTECTED] wrote: > > > Julian Elischer writes: > > > > > >>I think that one of the things we need to do is declare a new flag in > > >>disklabel that declares that the disklabel has been converted to use > > >>relative offsets... > > > > > Better plan: Abandon BSD labels before disks outgrow them. > > > > To be replaced bywhat? > > gpt > I don't know where it comes from but I believe it's the native partition > format for ia64 architecture machines. Pros: - fully 64 bit clean - maximum of 16384 partitions - unique id's for disks, partitions and OS types. - we already have the basic code support for it in the tree. - its on intel's roadmap for future i386 servers (for what thats worth) along with EFI. - it is possible to boot from, but needs new boot code written(*). Cons: - If you follow the spec strictly, it will not share disks with another fdisk-using OS. If strictly implemented according to the specs, it replaces the fdisk MBR and owns the entire disk. Our code however isn't that strict and will accept a GPT inside an MBR slice, meaning for i386 we can use GPT as a replacement for disklabel. - Booting is "interesting"(*). * - When GPT is used with EFI, the firmware has got a mini OS in rom which has native FAT32 file system support, which means we can just mount the boot partition and copy "loader.efi" in there and there are *no* bootblocks.. However, if we were to use it standalone we would not have this and would have to boot ourselves. The way this would be done is to put real boot code in the MBR, which would scan the gpt table to find a boot "partition" that contained the equivalent of what is now boot2. We could make this as big as we liked, but I'd imagine it would be 64K by default. That boot2 code would then be able to read UFS natively, just like now. In other words, it wouldn't be all that different to now except that somebody has to write it. Alternatively, we could deviate a bit from the "strict" specs and reserve the entire first track for boot code and avoid the problem that way. This would be easier and less likely to run into major code space pressure problems as it wouldn't have to parse GPT tables. Personally, unless EFI on i386 actually gets off the ground, if somebody is seriously considering this, I'd be inclined to suggest using a fairly loose gpt interpretation and using gpt as a replacement for disklabel inside a freebsd slice. That way it is easy to "play nice" with other OS's and less pain to deal with for booting. Cheers, -Peter -- Peter Wemm - [EMAIL PROTECTED]; [EMAIL PROTECTED]; [EMAIL PROTECTED] "All of this is for nothing if we don't go to the stars" - JMS/B5 To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Geom disklabel/fdisk issues?
On Mon, 13 Jan 2003, walt wrote: > [EMAIL PROTECTED] wrote: > > Julian Elischer writes: > > > >>I think that one of the things we need to do is declare a new flag in > >>disklabel that declares that the disklabel has been converted to use > >>relative offsets... > > > Better plan: Abandon BSD labels before disks outgrow them. > > To be replaced bywhat? gpt I don't know where it comes from but I believe it's the native partition format for ia64 architecture machines. > > > > > To Unsubscribe: send mail to [EMAIL PROTECTED] > with "unsubscribe freebsd-current" in the body of the message > To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Geom disklabel/fdisk issues?
[EMAIL PROTECTED] wrote: Julian Elischer writes: I think that one of the things we need to do is declare a new flag in disklabel that declares that the disklabel has been converted to use relative offsets... Better plan: Abandon BSD labels before disks outgrow them. To be replaced bywhat? To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Geom disklabel/fdisk issues?
I agree with that too. On Mon, 13 Jan 2003 [EMAIL PROTECTED] wrote: > In message <[EMAIL PROTECTED]>, Ju > lian Elischer writes: > > > >I think that one of the things we need to do is declare a new flag in > >disklabel that declares that the disklabel has been converted to use > >relative offsets. if the flag is not set then absolute offsets are > >expected.. That would give a way for us to move forward while still > >allowing partitions to co-exist with 4.x systems. > >in -current, geom just has to 'work with it' if the bit is not set. > >New systems would automatically set the bit. > > Better plan: Abandon BSD labels before disks outgrow them. > > -- > Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 > [EMAIL PROTECTED] | TCP/IP since RFC 956 > FreeBSD committer | BSD since 4.3-tahoe > Never attribute to malice what can adequately be explained by incompetence. > To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Geom disklabel/fdisk issues?
In message <[EMAIL PROTECTED]>, Ju lian Elischer writes: > >I think that one of the things we need to do is declare a new flag in >disklabel that declares that the disklabel has been converted to use >relative offsets. if the flag is not set then absolute offsets are >expected.. That would give a way for us to move forward while still >allowing partitions to co-exist with 4.x systems. >in -current, geom just has to 'work with it' if the bit is not set. >New systems would automatically set the bit. Better plan: Abandon BSD labels before disks outgrow them. -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 [EMAIL PROTECTED] | TCP/IP since RFC 956 FreeBSD committer | BSD since 4.3-tahoe Never attribute to malice what can adequately be explained by incompetence. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Geom disklabel/fdisk issues?
I think that one of the things we need to do is declare a new flag in disklabel that declares that the disklabel has been converted to use relative offsets. if the flag is not set then absolute offsets are expected.. That would give a way for us to move forward while still allowing partitions to co-exist with 4.x systems. in -current, geom just has to 'work with it' if the bit is not set. New systems would automatically set the bit. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message