Hi All,
Some time ago i have started reading the code in the sys/boot.
Especially i'm interested in the partition tables handling.
I found several problems:
1. There are several copies of the same code in the libi386/biosdisk.c
and common/disk.c, and partially libpc98/biosdisk.c.
2. ZFS probing is
On Tue, Jun 26, 2012 at 04:50:36PM +0400, Andrey V. Elsukov wrote:
> Hi All,
>
> Some time ago i have started reading the code in the sys/boot.
> Especially i'm interested in the partition tables handling.
> I found several problems:
> 1. There are several copies of the same code in the libi386/bi
On 26.06.2012 16:57, Pawel Jakub Dawidek wrote:
> On Tue, Jun 26, 2012 at 04:50:36PM +0400, Andrey V. Elsukov wrote:
>> Hi All,
>>
>> Some time ago i have started reading the code in the sys/boot.
>> Especially i'm interested in the partition tables handling.
>> I found several problems:
>> 1. Ther
On Tue, Jun 26, 2012 at 06:01:26PM +0400, Andrey V. Elsukov wrote:
> On 26.06.2012 16:57, Pawel Jakub Dawidek wrote:
> > On Tue, Jun 26, 2012 at 04:50:36PM +0400, Andrey V. Elsukov wrote:
> >> Hi All,
> >>
> >> Some time ago i have started reading the code in the sys/boot.
> >> Especially i'm inter
On Tuesday, June 26, 2012 8:50:36 am Andrey V. Elsukov wrote:
> Hi All,
>
> Some time ago i have started reading the code in the sys/boot.
> Especially i'm interested in the partition tables handling.
> I found several problems:
> 1. There are several copies of the same code in the libi386/biosdis
On Tue, Jun 26, 2012 at 01:37:11PM -0400, John Baldwin wrote:
> > 4. The gptboot now searches the backup GPT header in the previous sectors,
> > when it finds the "GEOM::" signature in the last sector. PMBR code also
> > tries to do the same:
> > common/gpt.c
> > i386/pmbr/pmbr.s
>
On Tue, Jun 26, 2012 at 2:23 PM, Pawel Jakub Dawidek wrote:
> On Tue, Jun 26, 2012 at 01:37:11PM -0400, John Baldwin wrote:
>> > 4. The gptboot now searches the backup GPT header in the previous sectors,
>> > when it finds the "GEOM::" signature in the last sector. PMBR code also
>> > tries to do
On Tue, Jun 26, 2012 at 02:41:31PM -0700, Kevin Oberman wrote:
> Long ago I saw a proposal to create a dedicated partition on GPT to
> hold the metadata. With the large number of partitions available on
> GPT, tying up one just for GEOM seems like a low price and it moves
> the device GEOM out of t
On 26.06.2012 21:37, John Baldwin wrote:
>> 4. The gptboot now searches the backup GPT header in the previous sectors,
>> when it finds the "GEOM::" signature in the last sector. PMBR code also
>> tries to do the same:
>> common/gpt.c
>> i386/pmbr/pmbr.s
>
> GPT really wants the ba
On 27.06.2012 1:41, Kevin Oberman wrote:
> Long ago I saw a proposal to create a dedicated partition on GPT to
> hold the metadata. With the large number of partitions available on
> GPT, tying up one just for GEOM seems like a low price and it moves
> the device GEOM out of the realm of FreeBSD un
on 27/06/2012 07:50 Andrey V. Elsukov said the following:
> Also we still haven't any tool to install zfsboot.
Yeah, I think it would be nice if ZFS provided some interface (ioctl?) to
properly write stuff to its special areas.
--
Andriy Gapon
___
free
On Wednesday, June 27, 2012 12:50:20 am Andrey V. Elsukov wrote:
> On 26.06.2012 21:37, John Baldwin wrote:
> >> 4. The gptboot now searches the backup GPT header in the previous sectors,
> >> when it finds the "GEOM::" signature in the last sector. PMBR code also
> >> tries to do the same:
> >>
On Tuesday, June 26, 2012 5:23:08 pm Pawel Jakub Dawidek wrote:
> On Tue, Jun 26, 2012 at 01:37:11PM -0400, John Baldwin wrote:
> > > 4. The gptboot now searches the backup GPT header in the previous sectors,
> > > when it finds the "GEOM::" signature in the last sector. PMBR code also
> > > tries
On 27.06.2012 16:07, John Baldwin wrote:
>> • Check the Signature
>> • Check the Header CRC
>> • Check that the MyLBA entry points to the LBA that contains the GUID
>> Partition Table
>> • Check the CRC of the GUID Partition Entry Array
>> If the GPT is the primary table, stored at LBA 1:
>> • Che
On Wed, Jun 27, 2012 at 08:22:25AM -0400, John Baldwin wrote:
> > I don't think so. Most common case is to configure partitions on top of
> > a mirror. Mirroring partitions is less common. Mostly because of
> > hardware RAIDs being popular. You don't expect hardware RAID vendor to
> > mirror partit
On Wednesday, June 27, 2012 10:08:17 am Pawel Jakub Dawidek wrote:
> On Wed, Jun 27, 2012 at 08:22:25AM -0400, John Baldwin wrote:
> > > I don't think so. Most common case is to configure partitions on top of
> > > a mirror. Mirroring partitions is less common. Mostly because of
> > > hardware RAID
On Wednesday, June 27, 2012 8:45:45 am Andrey V. Elsukov wrote:
> On 27.06.2012 16:07, John Baldwin wrote:
> >> • Check the Signature
> >> • Check the Header CRC
> >> • Check that the MyLBA entry points to the LBA that contains the GUID
> >> Partition Table
> >> • Check the CRC of the GUID Partiti
On Jun 26, 2012, at 10:37 AM, John Baldwin wrote:
>
> GPT really wants the backup header at the last LBA. I know you can set it,
> but I've interpreted that as a way to see if the primary header is correct or
> not. It seems to me that GPT tables created in this fashion (inside a GEOM
> prov
On Jun 26, 2012, at 2:43 PM, Pawel Jakub Dawidek wrote:
>
> As for sharing disk with other OS. If you share the disk with OS that
> doesn't support gmirror, you shouldn't use gmirror in the first place.
> You probably want to use only formats that are recognized by all your
> OSes.
This statemen
On Jun 26, 2012, at 9:50 PM, Andrey V. Elsukov wrote:
> If the primary GPT is corrupt, software must check the last LBA of the device
> to see if it has a
> valid GPT Header and point to a valid GPT Partition Entry Array."
>
> For the FreeBSD an each GEOM provider can be treated as disk device.
On Wed, Jun 27, 2012 at 10:37:11AM -0700, Marcel Moolenaar wrote:
>
> On Jun 26, 2012, at 10:37 AM, John Baldwin wrote:
> >
> > GPT really wants the backup header at the last LBA. I know you can set it,
> > but I've interpreted that as a way to see if the primary header is correct
> > or
> >
On Wed, Jun 27, 2012 at 10:45:35AM -0700, Marcel Moolenaar wrote:
>
> On Jun 26, 2012, at 2:43 PM, Pawel Jakub Dawidek wrote:
> >
> > As for sharing disk with other OS. If you share the disk with OS that
> > doesn't support gmirror, you shouldn't use gmirror in the first place.
> > You probably w
On Jun 27, 2012, at 11:34 AM, Pawel Jakub Dawidek wrote:
>
> I'm sorry, Marcel, but what you describe here has nothing to do with
> reality. To be able to implement realiable mirroring you have to use
> on-disk metadata. There is no way around that. You can implement
> non-redundant GEOM classes
On 06/27/12 16:28, John Baldwin wrote:
On Wednesday, June 27, 2012 8:45:45 am Andrey V. Elsukov wrote:
When we are in the FreeBSD, our loader can detect that device size
is lower than it see and it will work. When primary header is OK, then
other OSes should work with this GPT. When it isn't OK
On 2012-06-26 14:50, Andrey V. Elsukov wrote:
> Some time ago i have started reading the code in the sys/boot.
> Especially i'm interested in the partition tables handling.
> I found several problems:
> 1. There are several copies of the same code in the libi386/biosdisk.c
> and common/disk.c, and
On Wednesday, June 27, 2012 1:45:35 pm Marcel Moolenaar wrote:
>
> On Jun 26, 2012, at 2:43 PM, Pawel Jakub Dawidek wrote:
> >
> > As for sharing disk with other OS. If you share the disk with OS that
> > doesn't support gmirror, you shouldn't use gmirror in the first place.
> > You probably want
On Jun 27, 2012, at 11:20 AM, Pawel Jakub Dawidek wrote:
> On Wed, Jun 27, 2012 at 10:37:11AM -0700, Marcel Moolenaar wrote:
>>
>> On Jun 26, 2012, at 10:37 AM, John Baldwin wrote:
>>>
>>> GPT really wants the backup header at the last LBA. I know you can set it,
>>> but I've interpreted that
On Jun 27, 2012, at 12:08 PM, Christian Laursen wrote:
> On 06/27/12 16:28, John Baldwin wrote:
>> On Wednesday, June 27, 2012 8:45:45 am Andrey V. Elsukov wrote:
>>
>>> When we are in the FreeBSD, our loader can detect that device size
>>> is lower than it see and it will work. When primary hea
On 27.06.2012 21:55, Marcel Moolenaar wrote:
> You can't just re-interpret standards to match a context you know very well
> isn't applicable and consequently redefine what the word "device" means.
> You're on a slippery slope and while you may not see it as a problem, you
> do make it a problem fo
On Jun 27, 2012, at 12:27 PM, Andrey V. Elsukov wrote:
> On 27.06.2012 21:55, Marcel Moolenaar wrote:
>> You can't just re-interpret standards to match a context you know very well
>> isn't applicable and consequently redefine what the word "device" means.
>> You're on a slippery slope and while
On 28.06.2012 00:14, Marcel Moolenaar wrote:
>> Our loader detects that primary GPT header is damaged. It tries to read
>> backup GPT header from the last LBA and it detects that there is
>> "GEOM::" signature. It tries to read one previous sector and there is
>> *valid* GPT header.
>
> How do you
On Jun 27, 2012, at 1:48 PM, Andrey V. Elsukov wrote:
> On 28.06.2012 00:14, Marcel Moolenaar wrote:
>>> Our loader detects that primary GPT header is damaged. It tries to read
>>> backup GPT header from the last LBA and it detects that there is
>>> "GEOM::" signature. It tries to read one previo
I would like to point out that all other operating system which has
had this precise problem, have solved it by adding a bootfs partition
to hold the kernel+modules required to truly understand the disk-layout ?
--
Poul-Henning Kamp | UNIX since Zilog Zeus 3.20
p...@freebsd.org | T
On Wed, Jun 27, 2012 at 2:39 PM, Poul-Henning Kamp wrote:
>
> I would like to point out that all other operating system which has
> had this precise problem, have solved it by adding a bootfs partition
> to hold the kernel+modules required to truly understand the disk-layout ?
I have seen some fo
27.06.2012 23:27, Andrey V. Elsukov пишет:
1. You are against from:
Our loader detects that primary GPT header is damaged. It tries to read
backup GPT header from the last LBA and it detects that there is
"GEOM::" signature. It tries to read one previous sector and there is
*valid* GPT header.
Am 27.06.2012 21:14, schrieb Marcel Moolenaar:
>
> On Jun 27, 2012, at 12:08 PM, Christian Laursen wrote:
>
>> On 06/27/12 16:28, John Baldwin wrote:
>>> On Wednesday, June 27, 2012 8:45:45 am Andrey V. Elsukov wrote:
>>>
When we are in the FreeBSD, our loader can detect that device size
>>>
On 28.06.2012 13:19, Boris Samorodov wrote:
> 27.06.2012 23:27, Andrey V. Elsukov пишет:
>
>> 1. You are against from:
>> Our loader detects that primary GPT header is damaged. It tries to read
>> backup GPT header from the last LBA and it detects that there is
>> "GEOM::" signature. It tries to r
Sorry for following up to self, but ...
I just noticed somebody else suggesting the same method
(put GMIRROR configuration below Secondary GPT header),
but I think there is a problem:
If GMIRROR is used to mirror whole GPT partitioned drives,
then you want the GPT sectors to be considered part of
28.06.2012 13:41, Andrey V. Elsukov пишет:
On 28.06.2012 13:19, Boris Samorodov wrote:
27.06.2012 23:27, Andrey V. Elsukov пишет:
1. You are against from:
Our loader detects that primary GPT header is damaged. It tries to read
backup GPT header from the last LBA and it detects that there is
"G
28.06.2012 14:10, Stefan Esser пишет:
All of the above is ugly, U'm afraid :(
One more try to overcome it. :-)
We already have freebsd-boot partition at GPT scheme. Right?
Then why not use it (dedicated file/part/etc.) to store
geom FreeBSD information?
--
WBR, Boris Samorodov (bsam)
FreeBSD
On 28.06.2012 14:35, Wojciech Puchar wrote:
>> Just modify GEOM classes that keep state at the end of a partition to
>> leave some spare area *behind* the GEOM data. I.e.:
>>
>
> what is really a problem aat all?
>
> just leave as is. If someone want's use gpart and mirror then mirroring every
>
Just modify GEOM classes that keep state at the end of a partition to
leave some spare area *behind* the GEOM data. I.e.:
what is really a problem aat all?
just leave as is. If someone want's use gpart and mirror then mirroring
every partition is simpler. usually not every partition needs to
On 28.06.2012 15:36, Boris Samorodov wrote:
> 28.06.2012 14:10, Stefan Esser пишет:
>
>> All of the above is ugly, U'm afraid :(
>
> One more try to overcome it. :-)
>
> We already have freebsd-boot partition at GPT scheme. Right?
> Then why not use it (dedicated file/part/etc.) to store
> geom
On Jun 28, 2012, at 3:10 AM, Stefan Esser wrote:
>
> All of the above is ugly, U'm afraid :(
Indeed. The only sane way is to put the metadata in a partition of its own.
Every compliant OS will respect that and consequently will not scribble over
the data unintentionally. Any other scheme that pu
On Thu, Jun 28, 2012 at 08:33:17AM -0700, Marcel Moolenaar wrote:
>
> On Jun 28, 2012, at 3:10 AM, Stefan Esser wrote:
> >
> > All of the above is ugly, U'm afraid :(
>
> Indeed. The only sane way is to put the metadata in a partition of its own.
> Every compliant OS will respect that and conseq
On Thu, 28 Jun 2012 08:33:17 -0700 Marcel Moolenaar
wrote:
> My advise is to leave disk mirroring to H/W or firmware solutions and
> use FreeBSD mirroring for FreeBSD partitions only. If you want to
> mirror the whole disk, don't partition the disk with non-FreeBSD
> partitioning schemes and part
On Thu, 28 Jun 2012 14:49:02 -0500, Alexander Leidinger
wrote:
What about multipathing? In case the disk is attached via two paths but
multipath is not enabled, the OS sees the same disk (and the same
identical unique disk identifier) multiple times. Is this a violation
of the spec too?
Goo
On Jun 28, 2012, at 10:25 AM, Pawel Jakub Dawidek wrote:
> On Thu, Jun 28, 2012 at 08:33:17AM -0700, Marcel Moolenaar wrote:
>>
>> On Jun 28, 2012, at 3:10 AM, Stefan Esser wrote:
>>>
>>> All of the above is ugly, U'm afraid :(
>>
>> Indeed. The only sane way is to put the metadata in a partit
Pawel Jakub Dawidek wrote:
On Thu, Jun 28, 2012 at 08:33:17AM -0700, Marcel Moolenaar wrote:
On Jun 28, 2012, at 3:10 AM, Stefan Esser wrote:
All of the above is ugly, U'm afraid :(
Indeed. The only sane way is to put the metadata in a partition of its own.
Every compliant OS will respect t
On Jun 28, 2012, at 12:49 PM, Alexander Leidinger wrote:
> On Thu, 28 Jun 2012 08:33:17 -0700 Marcel Moolenaar
> wrote:
>
>> My advise is to leave disk mirroring to H/W or firmware solutions and
>> use FreeBSD mirroring for FreeBSD partitions only. If you want to
>> mirror the whole disk, don't
On Thu, Jun 28, 2012 at 02:54:43PM -0700, Marcel Moolenaar wrote:
> On Jun 28, 2012, at 12:49 PM, Alexander Leidinger wrote:
> > Or are you suggesting to
> > convince all BIOS vendors to include the ability to boot from some kind
> > of FreeBSD private partitioning scheme (not MBR as it is not
> >
On Jun 28, 2012, at 4:07 PM, Pawel Jakub Dawidek wrote:
>>
>> I would be having less problems if the mirroring didn't force the backup
>> GPT header in anything but the last sector. [...]
>
> GPT backup header is placed in the last sector of the mirror device,
> just like the user asked. Gmirror
Pawel Jakub Dawidek wrote
in <20120628230725.gb1...@garage.freebsd.pl>:
pj> PS. We are discussing two totally different things here:
pj> 1. Is placing GPT on anything but raw disk violates the spec? I can
pj>agree that it does and I'm happy with gpart(8) growing a warning.
I agree that th
Dimitry Andric writes:
> On 2012-06-26 14:50, Andrey V. Elsukov wrote:
>
>> Some time ago i have started reading the code in the sys/boot.
>> Especially i'm interested in the partition tables handling.
>> I found several problems:
>> 1. There are several copies of the same code in the libi386/bio
On 29.06.2012 15:01, Jan Beich wrote:
>>> So, i have created the branch and committed the changes:
>>> http://svnweb.freebsd.org/base/user/ae/bootcode/
>>> The patch is here:
>>> http://people.freebsd.org/~ae/boot.diff
>>
>> FWIW, I verified it compiles OK with clang, and especially boot2's
"Andrey V. Elsukov" writes:
> On 29.06.2012 15:01, Jan Beich wrote:
>
So, i have created the branch and committed the changes:
http://svnweb.freebsd.org/base/user/ae/bootcode/
The patch is here:
http://people.freebsd.org/~ae/boot.diff
>>>
>>> FWIW, I verified it compiles
on 26/06/2012 15:50 Andrey V. Elsukov said the following:
> 3. ZFS code now uses new API and probing on the systems with many disks
> should be greatly increased:
> zfs/zfs.c
> i386/loader/main.c
First of all, it's hard to parse the above sentence. "probing ... should be
greatly in
On 16.07.2012 14:23, Andriy Gapon wrote:
> on 26/06/2012 15:50 Andrey V. Elsukov said the following:
>> 3. ZFS code now uses new API and probing on the systems with many disks
>> should be greatly increased:
>> zfs/zfs.c
>> i386/loader/main.c
>
> First of all, it's hard to parse th
on 16/07/2012 13:57 Andrey V. Elsukov said the following:
> On 16.07.2012 14:23, Andriy Gapon wrote:
>> on 26/06/2012 15:50 Andrey V. Elsukov said the following:
>>> 3. ZFS code now uses new API and probing on the systems with many disks
>>> should be greatly increased:
>>> zfs/zfs.c
>>>
On 16.07.2012 15:05, Andriy Gapon wrote:
>>> 2. I am not sure if I like the approach of moving partition tasting code
>>> into
>>> common ZFS code (zfs.c). On one hand, it now makes sense because the new
>>> partition iteration code is machine-independent. On the other hand, the
>>> reason
>>>
on 16/07/2012 14:14 Andrey V. Elsukov said the following:
> On 16.07.2012 15:05, Andriy Gapon wrote:
2. I am not sure if I like the approach of moving partition tasting code
into
common ZFS code (zfs.c). On one hand, it now makes sense because the new
partition iteration code
On 16.07.2012 15:31, Andriy Gapon wrote:
>> Yes. It should work as before.
>
> Well, but it's obvious that zfs_probe_dev would be attempting to do some
> unneeded
> stuff (trying to treat partitions as disks) for that case. To me this is a
> clear
> indication zfs_probe_dev is not optimal for a
On Mon, Jul 16, 2012 at 04:00:49PM +0400, Andrey V. Elsukov wrote:
> On 16.07.2012 15:31, Andriy Gapon wrote:
> >> Yes. It should work as before.
> >
> > Well, but it's obvious that zfs_probe_dev would be attempting to do some
> > unneeded
> > stuff (trying to treat partitions as disks) for that
63 matches
Mail list logo
