d/freebsd-skq
1
0
Fork 0
Code Issues Pull Requests Packages Projects Releases Wiki Activity

Rework parts of this man page to improve grammar.

Browse Source 
Inspired by, and parts submitted by...
PR:		docs/157467
Submitted by:	Ben Kaduk <kaduk mit.edu>
MFC after:	2 weeks
This commit is contained in:
Gavin Atkinson 2011-06-06 21:02:26 +00:00
parent 48a16a34d8
commit 8a7fca58aa
1 changed files with 37 additions and 37 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

74
sbin/geom/class/part/gpart.8
View File

@ -24,7 +24,7 @@
.\"
.\" $FreeBSD$
.\"
.Dd May 30, 2011
.Dd June 6, 2011
.Dt GPART 8
.Os
.Sh NAME
@ -530,16 +530,17 @@ about its use.
.El
.\"
.Sh PARTITION TYPES
Partition types are identified on disk by particular strings or magic
values.
The
.Nm
utility uses symbolic names for common partition types to avoid that the
user needs to know what the partitioning scheme in question is and what
the actual number or identification needs to be used for a particular
type.
utility uses symbolic names for common partition types to avoid the
user needing to know these values or other details of the partitioning
scheme in question.
The
.Nm
utility also allows the user to specify scheme-specific partition types
for partition types that do not have symbol names.
for partition types that do not have symbolic names.
The symbolic names currently understood are:
.Bl -tag -width ".Cm freebsd-vinum"
.It Cm bios-boot
@ -740,30 +741,30 @@ action or reverted with the
.Cm undo
action.
.Sh RECOVERING
The GEOM class PART supports recovering of partition tables only for GPT.
The GEOM PART class supports recovering of partition tables only for GPT.
The GUID partition table has a primary and secondary (backup) copy of
metadata for redundance.
They are stored in the begining and in the end of device respectively.
Therefore it is acceptable to have some corruptions in the metadata that
are not fatal to work with GPT.
When kernel detects corrupt metadata it marks this table as corrupt and
reports about corruption.
Any changes in corrupt table are prohibited except
metadata for redundance, these are stored at the begining and the end
of the device respectively.
As a result of having two copies, it is acceptable to have some corruption
within the metadata that is not fatal to the working of GPT.
When the kernel detects corrupt metadata it marks this table as corrupt and
reports the corruption.
Any operations on corrupt tables are prohibited except for
.Cm destroy
and
.Cm recover .
.Pp
In case when only first sector is corrupt kernel can not detect GPT even
if partition table is not corrupt.
You can write protective MBR with
If the first sector of a provider is corrupt, the kernel can not detect GPT
even if partition table itself is not corrupt.
You can rewrite the protective MBR using the
.Xr dd 1
command to restore ability of GPT detection.
The copy of protective MBR is usually located in the
command, to restore the ability to detect the GPT.
The copy of the protective MBR is usually located in the
.Pa /boot/pmbr
file.
.Pp
In case when some of metadata is corrupt you will get to know about this
from kernel's messages like these:
If one GPT header appears to be corrupt but the other copy remains intact,
the kernel will log the following:
.Bd -literal -offset indent
GEOM: provider: the primary GPT table is corrupt or invalid.
GEOM: provider: using the secondary instead -- recovery strongly advised.
@ -777,32 +778,31 @@ GEOM: provider: using the primary only -- recovery suggested.
.Pp
Also
.Nm
commands like
commands such as
.Cm show , status
and
.Cm list
will report about corrupt table.
will report about corrupt tables.
.Pp
In case when the size of device has changed (e.g.\& volume expansion) the
secondary GPT header will become located not in the last sector.
If the size of the device has changed (e.g.\& volume expansion) the
secondary GPT header will no longer be located in the last sector.
This is not a metadata corruption, but it is dangerous because any
corruption of the primary GPT will lead to lost of partition table.
Kernel reports about this problem with message:
corruption of the primary GPT will lead to loss of partition table.
This problem is reported by the kernel with the message:
.Bd -literal -offset indent
GEOM: provider: the secondary GPT header is not in the last LBA.
.Ed
.Pp
A corrupt table can be recovered with
This situation can be recovered with the
.Cm recover
command.
This command does reconstruction of corrupt metadata using
known valid metadata.
Also it can relocate secondary GPT to the end of device.
This command reconstructs the corrupt metadata using known valid
metadata and relocates the secondary GPT to the end of the device.
.Pp
.Em NOTE :
The GEOM class PART can detect the same partition table on different GEOM
providers and some of them will be marked as corrupt.
Be careful when choosing a provider for recovering.
The GEOM PART class can detect the same partition table visible through
different GEOM providers, and some of them will be marked as corrupt.
Be careful when choosing a provider for recovery.
If you choose incorrectly you can destroy the metadata of another GEOM class,
e.g.\& GEOM MIRROR or GEOM LABEL.
.Sh SYSCTL VARIABLES
@ -815,11 +815,11 @@ The default value is shown next to each variable.
.Bl -tag -width indent
.It Va kern.geom.part.check_integrity : No 1
This variable controls the behaviour of metadata integrity checks.
When integrity checks are enabled
When integrity checks are enabled, the
.Nm PART
GEOM class verifies all generic partition parameters that it gets from the
GEOM class verifies all generic partition parameters obtained from the
disk metadata.
If some inconsistency is detected, partition table will be
If some inconsistency is detected, the partition table will be
rejected with a diagnostic message:
.Sy "GEOM_PART: Integrity check failed (provider, scheme)" .
.El