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
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 the above
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
that I added
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 is
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
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 case. To
Andrey V. Elsukov bu7c...@yandex.ru 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 OK with
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 size
isn't
Dimitry Andric d...@freebsd.org 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
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
is lower than it
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 read one
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
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
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)
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
partition
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 FreeBSD
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
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 consequently
On Thu, 28 Jun 2012 08:33:17 -0700 Marcel Moolenaar mar...@xcllnt.net
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
On Thu, 28 Jun 2012 14:49:02 -0500, Alexander Leidinger
alexan...@leidinger.net 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
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 partition of its
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
On Jun 28, 2012, at 12:49 PM, Alexander Leidinger wrote:
On Thu, 28 Jun 2012 08:33:17 -0700 Marcel Moolenaar mar...@xcllnt.net
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
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 doesn't
Pawel Jakub Dawidek p...@freebsd.org 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
pjagree that it does and I'm happy with gpart(8) growing a warning.
I
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 to do the
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:
• Check the
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 partitions.
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 RAIDs being
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 Partition Entry Array
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
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 statement is
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.
So,
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
not. It
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 want to
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
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 to use
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 as a way to
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 header is OK,
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 for
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 you may
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 know it's
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 previous sector
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 |
On Wed, Jun 27, 2012 at 2:39 PM, Poul-Henning Kamp p...@phk.freebsd.dk 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
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
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
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. There are
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 interested in the
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/biosdisk.c
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
GPT really
On Tue, Jun 26, 2012 at 2:23 PM, Pawel Jakub Dawidek p...@freebsd.org 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 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 the
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 backup header
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
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
___
63 matches
Mail list logo
