<commit_before>.\"
.\" Copyright (c) 2002 <NAME>
.\" Copyright (c) 2002 Networks Associates Technology, Inc.
.\" All rights reserved.
.\"
.\" This software was developed for the FreeBSD Project by <NAME>
.\" and NAI Labs, the Security Research Division of Network Associates, Inc.
.\" under DARPA/SPAWAR contract N66001-01-C-8035 ("CBOSS"), as part of the
.\" DARPA CHATS research program.
.\"
.\" Redistribution and use in source and binary forms, with or without
.\" modification, are permitted provided that the following conditions
.\" are met:
.\" 1. Redistributions of source code must retain the above copyright
.\"    notice, this list of conditions and the following disclaimer.
.\" 2. Redistributions in binary form must reproduce the above copyright
.\"    notice, this list of conditions and the following disclaimer in the
.\"    documentation and/or other materials provided with the distribution.
.\" 3. The names of the authors may not be used to endorse or promote
.\"    products derived from this software without specific prior written
.\"    permission.
.\"
.\" THIS SOFTWARE IS PROVIDED BY THE AUTHOR AND CONTRIBUTORS ``AS IS'' AND
.\" ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE
.\" IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE
.\" ARE DISCLAIMED.  IN NO EVENT SHALL THE AUTHOR OR CONTRIBUTORS BE LIABLE
.\" FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL
.\" DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS
.\" OR SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION)
.\" HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT
.\" LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY
.\" OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF
.\" SUCH DAMAGE.
.\"
.\" $FreeBSD$
.\"
.Dd March 27, 2002
.Os
.Dt GEOM 4
.Sh NAME
.Nm GEOM
.Nd modular disk I/O request transformation framework.
.Sh DESCRIPTION
The GEOM framework provides an infrastructure in which "classes"
can perform transformations on disk I/O requests on their path from
the upper kernel to the device drivers and back.
.Pp
Transformations in a GEOM context range from the simple geometric
displacement performed in typical disk partitioning modules over RAID
algorithms and device multipath resolution to full blown cryptographic
protection of the stored data.
.Pp
Compared to traditional "volume management", GEOM differs from most
and in some cases all previous implementations in the following ways:
.Bl -bullet
.It
GEOM is extensible.  It is trivially simple to write a new class
of transformation and it will not be given stepchild treatment.  If
someone for some reason wanted to mount IBM MVS diskpacks, a class
recognizing and configuring their VTOC information would be a trivial
matter.
.It
GEOM is topologically agnostic.  Most volume management implementations
have very strict notions of how classes can fit together, very often
one fixed hierarchy is provided for instance  subdisk - plex -
volume.
.El
.Pp
Being extensible means that new transformations are treated no differently
than existing transformations.
.Pp
Fixed hierarchies are bad because they make it impossible to express
the intent efficiently.
In the fixed hierarchy above it is not possible to mirror two
physical disks and then partition the mirror into subdisks, instead
one is forced to make subdisks on the physical volumes and to mirror
these two and two resulting in a much more complex configuration.
GEOM on the other hand does not care in which order things are done,
the only restriction is that cycles in the graph will not be allowed.
.Pp
.Sh "TERMINOLOGY and TOPOLOGY"
Geom is quite object oriented and consequently the terminology
borrows a lot of context and semantics from the OO vocabulary:
.Pp
A "class", represented by the data structure g_class implements one
particular kind of transformation.  Typical examples are MBR disk
partition, BSD disklabel, and RAID5 classes.
.Pp
An instance of a class is called a "geom" and represented by the
data structure "g_geom".  In a typical i386 FreeBSD system, there
will be one geom of class MBR for each disk.
.Pp
A "provider", represented by the data structure "g_provider", is
the front gate at which a geom offers service.
A provider is "a disk-like thing which appears in /dev" - a logical<commit_msg>Don't confuse "GEOM" with "geom".<commit_after>.\"
.\" Copyright (c) 2002 <NAME>
.\" Copyright (c) 2002 Networks Associates Technology, Inc.
.\" All rights reserved.
.\"
.\" This software was developed for the FreeBSD Project by <NAME>
.\" and NAI Labs, the Security Research Division of Network Associates, Inc.
.\" under DARPA/SPAWAR contract N66001-01-C-8035 ("CBOSS"), as part of the
.\" DARPA CHATS research program.
.\"
.\" Redistribution and use in source and binary forms, with or without
.\" modification, are permitted provided that the following conditions
.\" are met:
.\" 1. Redistributions of source code must retain the above copyright
.\"    notice, this list of conditions and the following disclaimer.
.\" 2. Redistributions in binary form must reproduce the above copyright
.\"    notice, this list of conditions and the following disclaimer in the
.\"    documentation and/or other materials provided with the distribution.
.\" 3. The names of the authors may not be used to endorse or promote
.\"    products derived from this software without specific prior written
.\"    permission.
.\"
.\" THIS SOFTWARE IS PROVIDED BY THE AUTHOR AND CONTRIBUTORS ``AS IS'' AND
.\" ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE
.\" IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE
.\" ARE DISCLAIMED.  IN NO EVENT SHALL THE AUTHOR OR CONTRIBUTORS BE LIABLE
.\" FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL
.\" DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS
.\" OR SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION)
.\" HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT
.\" LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY
.\" OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF
.\" SUCH DAMAGE.
.\"
.\" $FreeBSD$
.\"
.Dd March 27, 2002
.Os
.Dt GEOM 4
.Sh NAME
.Nm GEOM
.Nd modular disk I/O request transformation framework.
.Sh DESCRIPTION
The GEOM framework provides an infrastructure in which "classes"
can perform transformations on disk I/O requests on their path from
the upper kernel to the device drivers and back.
.Pp
Transformations in a GEOM context range from the simple geometric
displacement performed in typical disk partitioning modules over RAID
algorithms and device multipath resolution to full blown cryptographic
protection of the stored data.
.Pp
Compared to traditional "volume management", GEOM differs from most
and in some cases all previous implementations in the following ways:
.Bl -bullet
.It
GEOM is extensible.  It is trivially simple to write a new class
of transformation and it will not be given stepchild treatment.  If
someone for some reason wanted to mount IBM MVS diskpacks, a class
recognizing and configuring their VTOC information would be a trivial
matter.
.It
GEOM is topologically agnostic.  Most volume management implementations
have very strict notions of how classes can fit together, very often
one fixed hierarchy is provided for instance  subdisk - plex -
volume.
.El
.Pp
Being extensible means that new transformations are treated no differently
than existing transformations.
.Pp
Fixed hierarchies are bad because they make it impossible to express
the intent efficiently.
In the fixed hierarchy above it is not possible to mirror two
physical disks and then partition the mirror into subdisks, instead
one is forced to make subdisks on the physical volumes and to mirror
these two and two resulting in a much more complex configuration.
GEOM on the other hand does not care in which order things are done,
the only restriction is that cycles in the graph will not be allowed.
.Pp
.Sh "TERMINOLOGY and TOPOLOGY"
GEOM is quite object oriented and consequently the terminology
borrows a lot of context and semantics from the OO vocabulary:
.Pp
A "class", represented by the data structure g_class implements one
particular kind of transformation.  Typical examples are MBR disk
partition, BSD disklabel, and RAID5 classes.
.Pp
An instance of a class is called a "geom" and represented by the
data structure "g_geom".  In a typical i386 FreeBSD system, there
will be one geom of class MBR for each disk.
.Pp
A "provider", represented by the data structure "g_provider", is
the front gate at which a geom offers service.
A provider is "a disk-like thing which appears in /dev" - a logical
{'fraction_non_alphanumeric': 0.05806597379123362, 'fraction_numerical': 0.00745594215996385, 'mean_word_length': 4.165110851808635, 'pattern_counts': {'":': 0, '<': 7, '<?xml version=': 0, '>': 7, 'https://': 0, 'lorem ipsum': 0, 'www.': 0, 'xml': 0}, 'pii_count': 0, 'substrings_counts': 0, 'word_list_counts': {'cursed_substrings.json': 0, 'profanity_word_list.json': 0, 'sexual_word_list.json': 0, 'zh_pornsignals.json': 0}}
{'dir': 'git-commits-cleaned', 'id': '7182234', 'n_tokens_mistral': 2430, 'n_tokens_neox': 2107, 'n_words': 1325}