!http://www.sun.com/bigadmin/home/images/bigadminHeaderWikiThumb.jpg!
{section:border=false}
{column:width=20%}
{include:TOC for Tech Tips - by Task}
{column}
{column:width=55%}
h5. Note:
Please add your comments/corrections to this page. It is an excerpt of the EIS Boot Disk Standard. It is being placed here so that it can be discussed/amended/ratified by a wider community.
If you have any comments about this page, you can either leave comments directly on this page, or you can discuss on sysadmin-discuss@opensolaris.org
For more information about adding comments, pages, or sections, go back to the BigAdmin wiki [home|Home] page.
h1. Excerpts of the EIS Bootdisk Standard
h3. Introduction
This EIS standard is intended to help installers (and those who prepare planning documentation for installations) to layout their system disks in a consistent manner.
h4. Scope
This standard is designed to cover installations on SPARC servers from Solaris 8 upwards. It also covers x86/x64 servers from Solaris 10 update 1 onwards.
The following are assumed/covered:
* It is assumed that the system disk is of reasonable size (36 Gbytes or greater).
* We cover non-clustered and clustered systems (SunCluster 3.1/3.2)
* We cover Solstice Disc Suite (SDS) / Solaris Volume Manager (SVM).
* We do not recommend the use of VxVM for root disks. VxVM 4.x onwards can be used to manage mass storage without the need to encapsulate the boot disk.
This standard provides general guidelines for an installation by Sun Support Services (e.g. standard EIS installation delivery) and Sun Professional Services. It acts as a base for customer-specific layouts that may result from a PS engagement. The layouts and guidelines in this standard are preferred and will maintain consistency of support procedures.
h4. General Notes
The following are assumed to be common knowledge (ie accepted):
* This statements made in this document should be regarded as being a strong recommendation but not gospel!
* The customer should be strongly discouraged from placing applications or user data on the system disk of a server.
* We do not recommend separate slices for /var, /usr, /opt or even /usr/openwin!
(yes I know the 3rd is controversial, but if you look at the historical reasons for multiple slices, the reasons no longer exist!)
h4. Hardware RAID Controllers
A number of the current servers supplied by Sun have H/W-based raid controllers which enable the boot disk to be mirrored to a second disc. EIS recommends that H/W RAID 1 be used to mirror the boot disk wherever it is available.
h4. Live Upgrade
Live Upgrade is facility that provides 1 or more alternative boot slices for the purposes of reducing the downtime during patching, upgrades and providing a quick rollback mechanism. The use of Live Upgrade requires that partitions be left aside to support this. We recommend the provision of a Live Upgrade partition at initial install time.
To simplify the use of Live Upgrade, we have recommended the use of a SINGLE partition for the complete O/S. Should you choose to have multiple partitions you will also need to create additional partitions for Live Upgrade use. (This pertains only to filesystems that contain O/S files such as /usr, /var, /opt etc.).
Be aware that currently there are significant complexities to using Live Upgrade if the boot disk is encapsulated with VxVM.
Refer to [Patching Mirrored Systems with the Solaris Live Upgrade Software|http://www.sun.com/blueprints/0607/820-2188.html] for guidance on planning & performing Solaris upgrades and patch management using the Live Upgrade partition.
h4. Dedicated Dump Device
Solaris allows a Dedicated Dump Device to be defined. This allows crash dumps to be collected without writing into the swap partition. The advantage for this is twofold. Firstly, it allows dumps to be taken of a running system. Secondly it means that the primary swap partition does not need to be sized to accommodate the size of a dump. The DDD has to be a raw device, and should NOT be mirrored.
h3. Disk Sizing
h4. Sizing for Solaris
Given that boot disks are currently much larger than required for the O/S, we have recommended a conservative upper limit for the size of the root partition. The choice of this size is a balance between the actual space requirements, and the desire to reduce resyncing time between the root disk and its mirror in the event of a failure.
The amount of disk space required for slices (assuming "FULL + OEM") are:
* root - assuming that /var is included: 15GB.
* root - assuming that /var is excluded: 13GB
* /var - assuming on a separate slice including /var/crash: 4 Gbytes.
The remaining space on the disk may be simply left unused, or allocated to an otherwise usable partition. e.g. /export, /data, /apps etc.
h4. Sizing SWAP
It is not strictly necessary to have a swap partition (although there should be one for crash dumps unless there is a separate dump device). Clearly if a server starts to swap then the performance as seen by the clients will be degraded.
* The primary swap partition should default to 4 Gb unless otherwise deemed necessary. (In the case of a desktop system with limited memory, 2Gb swap is also OK).
* We have defined a recommended primary swap partition size, which should reside on the boot disk. Additional swap space can (and probably will) be configured by adding additional swap devices to meet the TOTAL swap space requirements. This will increase the performance of the swap system.
* These additional swap devices can be either raw partitions, or filesystem based.
* It is not desirable to place additional swap devices on the primary system disk!
The following may help to define the TOTAL swap space requirements especially for SunFire domains:
* If DR will not be used, then the total swap space allocation should be the same as the amount of memory on the SB with the most memory (16Gb with 512Mb DIMMs; 32Gb with 1Gb DIMMs).
* If DR is going to be used in the domain, then the total swap space allocation should be two times the amount of memory on the SB with the most memory (double the above sizes).
h4. Sizing the Dedicated Dump Device
The maximum theoretical size of a crash dump is the total of physical and virtual memory. However, this assumes that ALL the memory space was used for the kernel, which is highly unlikely. In general, a DDD size equal to physical memory should be sufficient.
h3. Boot Disk Layout
Based on the above rules, here are a sample of root disk layouts:
h4. Solaris Desktop
It is assumed that the disk of a desktop is not mirrored. The following layout os for disks with a capacity >=36Gb
||Slice||Name||Start Cyl||Size||
|0|/| |15 Gb|
|1|swap|0|2 Gb|
|2|backup|0| Whole Disk|
|3|liveupgrade| |15Gb|
|4|user defined| |free|
The slices showed above are the EIS-recommended standard. If required, and the disk has a higher capacity, you may increase the size of root and/or swap; however slices 0 and 3 must be identical in size.
h4. Boot Disk Layout for a Solaris Server (Not SW Mirrored)
It is expected that most servers will have a redundant boot device. In many cases this will be using host based mirroring and these layouts are discussed in the next section. For the cases where there is no redundancy, or it is being provided by a hardware based RAID device, the following layout is an example. The following layout is for disks with capacity ≥36Gb.
||Slice||Name||Start Cyl||Size||
|0|/| |15 Gb|
|1|swap|0|4 Gb|
|2|backup|0| Whole Disk|
|3|liveupgrade| |15Gb|
|4|user defined| |free|
The slices showed above are the EIS-recommended standard. If required, and the disk has a higher capacity you may increase the size of root and/or swap; however slices 0 and 3 must be identical in size.
Slices 5 or 6 may be used to created a DDD if required.
To maintain consistency with the layouts of the mirrored boot disks, use of slice 7 should be avoided.
N.B. If the root disk is >36Gb, then we recommend a / filesystem size of 18Gb.
h4. Mirrored Disk Layouts on Solaris Systems
Depending on the class of server, a variety of different system disk hardware tends to be available.
On the smaller servers, the system disks tend to be internal, often on the same controller and limited to two disks. On the larger servers, boot storage tends to be external and split between devices, such as multiple S1s, D130s, or split D240s, and the number of disks available as "system" storage range from four to six. (2-disk mirrored, 3-disk mirrored).
However, some of these disks may be earmarked for customer system data such as application binaries, and user data, and therefore it cannot be assumed that all the disks can be used for the system layout.
We will focus on the worst case (but most common) scenario of a pair of mirrored disks (1-disk mirrored) being dedicated to the boot environment, but will provide guidelines for making use of additional disks if they are available.
The root disk and its mirror should be on separate controllers and housed in separate devices if possible. Normally you should only mirror the boot disk to a "similar" disk. For configurations with boot disks on a single controller and external storage (SE33x0, SE35x0, SE6900 etc.) on another controller, the latter should probably not be used for mirroring.
h4. Mirroring using SVM
In the following layouts we have left slice 7 free for the metaDBs on each disk. Just as with the boot disks themselves, these metaDBs should be spread across at least two controllers if at all possible. We recommend 32MB1 for the disk slice size; each slice to hold 3 metaDBs.
When using SVM, if you have metaDBs on ONLY the root disk and its mirror, the system will fail to boot if one of the disks is failed due to it not having access to a "majority" of metaDB replicas. For this reason it is highly recommended to create a 3rd metaDB location on a 3rd disk, preferably on a different controller.
If there are only 2 disks in the system, the following line can be added to the file /etc/system which allows the system to boot if 1 drive fails in a 2 drive (mirrored) scenario:
set md:mirrored_root_flag=1
However, this method COULD cause data corruption if multiple reboots occur and the "failed" disk "unfails" itself resulting in inconsistent mirrors. In many cases it may be preferable to not boot, and force user intervention. See InfoDocs 18280 & 70946 for more details.
h4. Mirrored Boot Disk Layout
Is basically identical to the server layout above with the additional of a 32Mb metadb partition on slice 7.
||Slice||Name||Start Cyl||Size||
|0|/| |15 Gb|
|1|swap|0|4 Gb|
|2|backup|0| Whole Disk|
|3|liveupgrade| |15Gb|
|7|metadb| |32 Mb|
(The above is mirrored to a second, preferably identical, disk)
The free space can be allocated to any of slices 4,5 or 6 and used for customer data, or an (unmirrored) Dedicated Dump Device. (although it is preferred that this be on additional disks)
h4. Factory Boot Disk Layout
There is an increasing trend towards pre-loading Solaris at the factory. The intention is to reduce the time between delivery and production start. We assume a minimum boot disk size of 36Gb for current systems (September 2007: most but not all systems have larger disks).
Since one usually does not know the final configuration (even more so with volume products) the following disk layout has been chosen:
||Slice||Name||Start Cyl||Size||
|0|/| |15 Gb|
|1|swap|0|4 Gb|
|2|backup|0| Whole Disk|
|3|liveupgrade| |15Gb|
Slices 4, 5, 6 & 7 remain unallocated as does the remaining space on the disk. This allows the customer to easily add additional slices and allocate space as required (e.g. /globaldevices and metadb). (Or even remove the liveupgrade partition if he really does no want it.
This layout means that Solaris can be installed at the factory, together with the Solaris patches, the SunVTS packages and its patch. Testing using SunVTS can take place. Once at the customer site mirroring can be set up using SDS/SVM or VxVM as appropriate and the rest of the disk can be allocated as determined by the required configuration.
Whilst realising that this layout will not fit all installations, it is believed that it has a reasonable chance of being useful, especially with volume products.
{column}
{column:width=25%}
!http://www.sun.com/bigadmin/home/images/logoSmall.gif|width=115,height=27!
h5. Most Popular Collections
* [Solaris x86 Topics | http://www.sun.com/bigadmin/collections/solarisx86.html]
* [Community-Submitted BigAdmin Content | http://www.sun.com/bigadmin/collections/community_submitted.html]
* [What's New and Recently Updated|http://www.sun.com/bigadmin/collections/recently_updated.html]
h5. All Collections
* [Configuration|http://www.sun.com/bigadmin/collections/configuration.html]
* [Database|http://www.sun.com/bigadmin/collections/database.html]
* [Developer|http://www.sun.com/bigadmin/collections/developer.html]
* [General Unix|http://www.sun.com/bigadmin/collections/gen_unix.html]
* [Hardware|http://www.sun.com/bigadmin/collections/hardware.html]
* [Installation|http://www.sun.com/bigadmin/collections/installation.html]
* [Java Deployment| http://www.sun.com/bigadmin/collections/java_deployment.html]
* [Linux |http://www.sun.com/bigadmin/collections/linux.html]
* [Migration|http://www.sun.com/bigadmin/collections/migration.html]
* [Networking|http://www.sun.com/bigadmin/collections/networking.html]
* [Performance|http://www.sun.com/bigadmin/collections/performance.html]
* [Security|http://www.sun.com/bigadmin/collections/security.html]
* [Solaris|http://www.sun.com/bigadmin/collections/solaris.html]
* [Solaris on x86|http://www.sun.com/bigadmin/collections/solarisx86.html]
* [New and Recently Updated|http://www.sun.com/bigadmin/collections/recently_updated.html]
h5. View Related Links
* [Solaris Bootdisk Layout discussion|http://blogs.sun.com/mramcha/entry/solaris_bootdisk_layout_discussion]
* [How to Lay Out a Boot Disk: Help Document the Best Way|http://blogs.sun.com/bigadmin/entry/join_discussion_and_review_docs]
{column}
{section}
{section:border=false}
{column:width=20%}
{include:TOC for Tech Tips - by Task}
{column}
{column:width=55%}
h5. Note:
Please add your comments/corrections to this page. It is an excerpt of the EIS Boot Disk Standard. It is being placed here so that it can be discussed/amended/ratified by a wider community.
If you have any comments about this page, you can either leave comments directly on this page, or you can discuss on sysadmin-discuss@opensolaris.org
For more information about adding comments, pages, or sections, go back to the BigAdmin wiki [home|Home] page.
h1. Excerpts of the EIS Bootdisk Standard
h3. Introduction
This EIS standard is intended to help installers (and those who prepare planning documentation for installations) to layout their system disks in a consistent manner.
h4. Scope
This standard is designed to cover installations on SPARC servers from Solaris 8 upwards. It also covers x86/x64 servers from Solaris 10 update 1 onwards.
The following are assumed/covered:
* It is assumed that the system disk is of reasonable size (36 Gbytes or greater).
* We cover non-clustered and clustered systems (SunCluster 3.1/3.2)
* We cover Solstice Disc Suite (SDS) / Solaris Volume Manager (SVM).
* We do not recommend the use of VxVM for root disks. VxVM 4.x onwards can be used to manage mass storage without the need to encapsulate the boot disk.
This standard provides general guidelines for an installation by Sun Support Services (e.g. standard EIS installation delivery) and Sun Professional Services. It acts as a base for customer-specific layouts that may result from a PS engagement. The layouts and guidelines in this standard are preferred and will maintain consistency of support procedures.
h4. General Notes
The following are assumed to be common knowledge (ie accepted):
* This statements made in this document should be regarded as being a strong recommendation but not gospel!
* The customer should be strongly discouraged from placing applications or user data on the system disk of a server.
* We do not recommend separate slices for /var, /usr, /opt or even /usr/openwin!
(yes I know the 3rd is controversial, but if you look at the historical reasons for multiple slices, the reasons no longer exist!)
h4. Hardware RAID Controllers
A number of the current servers supplied by Sun have H/W-based raid controllers which enable the boot disk to be mirrored to a second disc. EIS recommends that H/W RAID 1 be used to mirror the boot disk wherever it is available.
h4. Live Upgrade
Live Upgrade is facility that provides 1 or more alternative boot slices for the purposes of reducing the downtime during patching, upgrades and providing a quick rollback mechanism. The use of Live Upgrade requires that partitions be left aside to support this. We recommend the provision of a Live Upgrade partition at initial install time.
To simplify the use of Live Upgrade, we have recommended the use of a SINGLE partition for the complete O/S. Should you choose to have multiple partitions you will also need to create additional partitions for Live Upgrade use. (This pertains only to filesystems that contain O/S files such as /usr, /var, /opt etc.).
Be aware that currently there are significant complexities to using Live Upgrade if the boot disk is encapsulated with VxVM.
Refer to [Patching Mirrored Systems with the Solaris Live Upgrade Software|http://www.sun.com/blueprints/0607/820-2188.html] for guidance on planning & performing Solaris upgrades and patch management using the Live Upgrade partition.
h4. Dedicated Dump Device
Solaris allows a Dedicated Dump Device to be defined. This allows crash dumps to be collected without writing into the swap partition. The advantage for this is twofold. Firstly, it allows dumps to be taken of a running system. Secondly it means that the primary swap partition does not need to be sized to accommodate the size of a dump. The DDD has to be a raw device, and should NOT be mirrored.
h3. Disk Sizing
h4. Sizing for Solaris
Given that boot disks are currently much larger than required for the O/S, we have recommended a conservative upper limit for the size of the root partition. The choice of this size is a balance between the actual space requirements, and the desire to reduce resyncing time between the root disk and its mirror in the event of a failure.
The amount of disk space required for slices (assuming "FULL + OEM") are:
* root - assuming that /var is included: 15GB.
* root - assuming that /var is excluded: 13GB
* /var - assuming on a separate slice including /var/crash: 4 Gbytes.
The remaining space on the disk may be simply left unused, or allocated to an otherwise usable partition. e.g. /export, /data, /apps etc.
h4. Sizing SWAP
It is not strictly necessary to have a swap partition (although there should be one for crash dumps unless there is a separate dump device). Clearly if a server starts to swap then the performance as seen by the clients will be degraded.
* The primary swap partition should default to 4 Gb unless otherwise deemed necessary. (In the case of a desktop system with limited memory, 2Gb swap is also OK).
* We have defined a recommended primary swap partition size, which should reside on the boot disk. Additional swap space can (and probably will) be configured by adding additional swap devices to meet the TOTAL swap space requirements. This will increase the performance of the swap system.
* These additional swap devices can be either raw partitions, or filesystem based.
* It is not desirable to place additional swap devices on the primary system disk!
The following may help to define the TOTAL swap space requirements especially for SunFire domains:
* If DR will not be used, then the total swap space allocation should be the same as the amount of memory on the SB with the most memory (16Gb with 512Mb DIMMs; 32Gb with 1Gb DIMMs).
* If DR is going to be used in the domain, then the total swap space allocation should be two times the amount of memory on the SB with the most memory (double the above sizes).
h4. Sizing the Dedicated Dump Device
The maximum theoretical size of a crash dump is the total of physical and virtual memory. However, this assumes that ALL the memory space was used for the kernel, which is highly unlikely. In general, a DDD size equal to physical memory should be sufficient.
h3. Boot Disk Layout
Based on the above rules, here are a sample of root disk layouts:
h4. Solaris Desktop
It is assumed that the disk of a desktop is not mirrored. The following layout os for disks with a capacity >=36Gb
||Slice||Name||Start Cyl||Size||
|0|/| |15 Gb|
|1|swap|0|2 Gb|
|2|backup|0| Whole Disk|
|3|liveupgrade| |15Gb|
|4|user defined| |free|
The slices showed above are the EIS-recommended standard. If required, and the disk has a higher capacity, you may increase the size of root and/or swap; however slices 0 and 3 must be identical in size.
h4. Boot Disk Layout for a Solaris Server (Not SW Mirrored)
It is expected that most servers will have a redundant boot device. In many cases this will be using host based mirroring and these layouts are discussed in the next section. For the cases where there is no redundancy, or it is being provided by a hardware based RAID device, the following layout is an example. The following layout is for disks with capacity ≥36Gb.
||Slice||Name||Start Cyl||Size||
|0|/| |15 Gb|
|1|swap|0|4 Gb|
|2|backup|0| Whole Disk|
|3|liveupgrade| |15Gb|
|4|user defined| |free|
The slices showed above are the EIS-recommended standard. If required, and the disk has a higher capacity you may increase the size of root and/or swap; however slices 0 and 3 must be identical in size.
Slices 5 or 6 may be used to created a DDD if required.
To maintain consistency with the layouts of the mirrored boot disks, use of slice 7 should be avoided.
N.B. If the root disk is >36Gb, then we recommend a / filesystem size of 18Gb.
h4. Mirrored Disk Layouts on Solaris Systems
Depending on the class of server, a variety of different system disk hardware tends to be available.
On the smaller servers, the system disks tend to be internal, often on the same controller and limited to two disks. On the larger servers, boot storage tends to be external and split between devices, such as multiple S1s, D130s, or split D240s, and the number of disks available as "system" storage range from four to six. (2-disk mirrored, 3-disk mirrored).
However, some of these disks may be earmarked for customer system data such as application binaries, and user data, and therefore it cannot be assumed that all the disks can be used for the system layout.
We will focus on the worst case (but most common) scenario of a pair of mirrored disks (1-disk mirrored) being dedicated to the boot environment, but will provide guidelines for making use of additional disks if they are available.
The root disk and its mirror should be on separate controllers and housed in separate devices if possible. Normally you should only mirror the boot disk to a "similar" disk. For configurations with boot disks on a single controller and external storage (SE33x0, SE35x0, SE6900 etc.) on another controller, the latter should probably not be used for mirroring.
h4. Mirroring using SVM
In the following layouts we have left slice 7 free for the metaDBs on each disk. Just as with the boot disks themselves, these metaDBs should be spread across at least two controllers if at all possible. We recommend 32MB1 for the disk slice size; each slice to hold 3 metaDBs.
When using SVM, if you have metaDBs on ONLY the root disk and its mirror, the system will fail to boot if one of the disks is failed due to it not having access to a "majority" of metaDB replicas. For this reason it is highly recommended to create a 3rd metaDB location on a 3rd disk, preferably on a different controller.
If there are only 2 disks in the system, the following line can be added to the file /etc/system which allows the system to boot if 1 drive fails in a 2 drive (mirrored) scenario:
set md:mirrored_root_flag=1
However, this method COULD cause data corruption if multiple reboots occur and the "failed" disk "unfails" itself resulting in inconsistent mirrors. In many cases it may be preferable to not boot, and force user intervention. See InfoDocs 18280 & 70946 for more details.
h4. Mirrored Boot Disk Layout
Is basically identical to the server layout above with the additional of a 32Mb metadb partition on slice 7.
||Slice||Name||Start Cyl||Size||
|0|/| |15 Gb|
|1|swap|0|4 Gb|
|2|backup|0| Whole Disk|
|3|liveupgrade| |15Gb|
|7|metadb| |32 Mb|
(The above is mirrored to a second, preferably identical, disk)
The free space can be allocated to any of slices 4,5 or 6 and used for customer data, or an (unmirrored) Dedicated Dump Device. (although it is preferred that this be on additional disks)
h4. Factory Boot Disk Layout
There is an increasing trend towards pre-loading Solaris at the factory. The intention is to reduce the time between delivery and production start. We assume a minimum boot disk size of 36Gb for current systems (September 2007: most but not all systems have larger disks).
Since one usually does not know the final configuration (even more so with volume products) the following disk layout has been chosen:
||Slice||Name||Start Cyl||Size||
|0|/| |15 Gb|
|1|swap|0|4 Gb|
|2|backup|0| Whole Disk|
|3|liveupgrade| |15Gb|
Slices 4, 5, 6 & 7 remain unallocated as does the remaining space on the disk. This allows the customer to easily add additional slices and allocate space as required (e.g. /globaldevices and metadb). (Or even remove the liveupgrade partition if he really does no want it.
This layout means that Solaris can be installed at the factory, together with the Solaris patches, the SunVTS packages and its patch. Testing using SunVTS can take place. Once at the customer site mirroring can be set up using SDS/SVM or VxVM as appropriate and the rest of the disk can be allocated as determined by the required configuration.
Whilst realising that this layout will not fit all installations, it is believed that it has a reasonable chance of being useful, especially with volume products.
{column}
{column:width=25%}
!http://www.sun.com/bigadmin/home/images/logoSmall.gif|width=115,height=27!
h5. Most Popular Collections
* [Solaris x86 Topics | http://www.sun.com/bigadmin/collections/solarisx86.html]
* [Community-Submitted BigAdmin Content | http://www.sun.com/bigadmin/collections/community_submitted.html]
* [What's New and Recently Updated|http://www.sun.com/bigadmin/collections/recently_updated.html]
h5. All Collections
* [Configuration|http://www.sun.com/bigadmin/collections/configuration.html]
* [Database|http://www.sun.com/bigadmin/collections/database.html]
* [Developer|http://www.sun.com/bigadmin/collections/developer.html]
* [General Unix|http://www.sun.com/bigadmin/collections/gen_unix.html]
* [Hardware|http://www.sun.com/bigadmin/collections/hardware.html]
* [Installation|http://www.sun.com/bigadmin/collections/installation.html]
* [Java Deployment| http://www.sun.com/bigadmin/collections/java_deployment.html]
* [Linux |http://www.sun.com/bigadmin/collections/linux.html]
* [Migration|http://www.sun.com/bigadmin/collections/migration.html]
* [Networking|http://www.sun.com/bigadmin/collections/networking.html]
* [Performance|http://www.sun.com/bigadmin/collections/performance.html]
* [Security|http://www.sun.com/bigadmin/collections/security.html]
* [Solaris|http://www.sun.com/bigadmin/collections/solaris.html]
* [Solaris on x86|http://www.sun.com/bigadmin/collections/solarisx86.html]
* [New and Recently Updated|http://www.sun.com/bigadmin/collections/recently_updated.html]
h5. View Related Links
* [Solaris Bootdisk Layout discussion|http://blogs.sun.com/mramcha/entry/solaris_bootdisk_layout_discussion]
* [How to Lay Out a Boot Disk: Help Document the Best Way|http://blogs.sun.com/bigadmin/entry/join_discussion_and_review_docs]
{column}
{section}