Stuff_Itinme

Stuff_Itinme
Taken from http://sysunconfig.net/unixtips/soft-partitions.html
Look up any hostnames in the site1 and site2.example.com zones. Look up any hostnames in the site1.internal and site2.internal domains. Look up any hostnames on the Internet. Exchange mail with internal AND external people.
Look up any hostnames in the site1 and site2.example.com zones. Exchange mail with anyone in the site1 and site2.example.com zones.
The intent of this document is to describe Soft Partitioning within Solstice DiskSuite (soon-to-be-renamed Solaris Volume Manager), and offer a short primer/tutorial on how to create, use, and delete them.
Until now, Solaris, without any volume management software, has only ever allowed a fixed number of partitions on a physical disk (seven (7) on SPARC platforms). With the increase in capacity of disks, this limitation has become a severe restriction.
SDS/SVM uses these slices for its metadevices (sub-mirrors, trans, stripes, and RAID5) and hence is faced with the same limitation, whereas Veritas Volume Manager (VxVM) allows for the logical partitioning of disks into a virtually unlimited number of subdisks.
Soft Partitioning allows for a disk to be subdivided into many partitions which are controlled and maintained by software, thereby removing the limitation of the number of partitions on a disk. A soft partition is made up of one or more " extents ". An extent describes the parts of the physical disk that make up the soft partition. While the maximum number of extents per soft partition is 2147483647, the majority of soft partitions will use only one (1) extent.
Soft Partitioning was not in the original Solstice DiskSuite 4.2.1 Release, which coincided with the release of Solaris 8. However, the soft partitioning functionality was released in patch 108693-06 for SDS 4.2.1.
When Solaris 9 gets released, the "Solstice DiskSuite" name will change to "Solaris Volume Manager" ("SVM") and it will be bundled in with Solaris 9. Soft Partitioning will, of course, be part of the base functionality of that release.
Soft Partitions are implemented by new kernel driver: md_sp .
NOTE : the -p option means that the command refers to soft partitions.
The -e option requires that the name of the disk supplied be in the form c#t#d# .
The last parameter (200m) specifies the initial size of the soft partition. The sizes can be specified in blocks, kilobytes, megabytes, gigabytes, and terabytes.
The -e option causes the disk to be repartitioned such that slice 7 has enough space to hold a replica (although no replica is actually created on this disk) and slice 0 contains the rest of the space. Slice 2 is removed from the disk. The soft partition that is being created is put into slice 0. Further soft partitions can be created on slice 0 by the next method of creating a soft partition.
After this command is run, the layout of the disk would like similar to this example:
This command (with the -e ) can only be run on an empty disk (one that is not used in any other metadevice). If another metadevice or replica already exists on this disk, one of the following messages will be printed, and no soft partition will be created.
This will create a soft partition on the specified slice. No repartitioning of the disk is done. Provided there is space on the slice, additional soft partitions could be created as required. The device name must include the slice number (c#t#d#s#).
If another soft partition already exists in this slice, this one will be created immediately after the existing one. Therefore, no overlap of soft partitions can occur by accident.
An offset of 0 is not valid, as the first block on a slice containing a soft partition contains the initial extent header. Each extent header consumes 1 block of disk and each soft partition will have an extent header placed at the end of each extent. Extent headers are explained in more detail in the next section.
NOTE: This method is not documented in the man page for metainit and is not recommended for manual use. It is here because a subsequent metastat -p command will output information in this format.
Whenever a soft partiton is created in a disk slice, an "extent header" is written to disk. Internally to Sun, these are sometimes referred to as "watermarks".
An extent header is a consistency record and contains such information as the metadevice (soft partition) name, it's status, it's size, and a checksum. Each extent header 1 block (512 bytes) in size.
The following diagram shows an example 100MB slice (c1t0d0s0) and the extent headers (watermarks) that have been created on it. The command to make the soft partition shown was
There is always an extent header on the first and last blocks in the slice. Note that the 80MB of space left over from the creation of the soft partition can be used to make one or more additional soft partitions. Each additional soft partition will create an additional extent header to be created as well.
Once done, the resulting metastat output of the mirror will look like this:
RAID5 devices can be made up of soft partitions directly. This example shows 4 soft partitions (from 4 separate slices) striped together to make a RAID5 device:
Once done, the resulting metastat output of the RAID5 device will look like this:
Once done, the resulting metastat output of the metatrans device will look like this:
Most of the time, soft partitions are made on a disk slice. However, there are certain situations where it can be beneficial to make a soft partition on top of an existing metadevice. This is referred to as layering .
For example, say you have a 90GB RAID5 device made up of 6 18GB disks. You can then take that 90GB device and "split it up" into many soft partitions. These many soft partitions then can be accessed as separate simple metadevices, although the data in them is protected by the RAID5 parity in the underlying device.
Soft partitions can be layered only on top of concat/stripes, mirrors, and RAID5 devices. Soft partitions cannot be layered on top of a metatrans device or directly on top of another soft partition.
Here is an example of layering soft partitions on top of an existing RAID5 metadevice. First, we create the RAID5 device, then soft partition that device into 3 100MB partitions (obviously, we could create more than just 3 soft partitions).
Each of the resulting soft partitions ( d1 , d2 , and d3 ) can be accessed individually (i.e., newfs and mount ).
Soft partitions can be built on top of an existing mirror device as well, just like we did above on the RAID5 device. In the following example, the mirror device ( d0 ) is "carved up" into 3 smaller soft partitions.
Soft partitions are not allowed to be parented by other soft partitions directly. For example:
A soft partition can be grown by the use of the metattach command. There is no mechanism to shrink a soft partition.
When additional space is added to an existing soft partition, the additional space is taken from any available space on the same device and might not be contiguous with the existing soft partition. Growing soft partitions must be done with free space in the same device as the current soft partition.
The following example shows how growing a soft partition will increase the size of the current extent:
Note how after the metattach is run, there is still only one extent, but the (block count) has grown from 204800 (100MB) to 307200 (150MB).
In the following example, the extent cannot be grown, as it was above, because another soft partition is "in the way". Therefore, a second extent is created in the same slice.
Note how d1 now has two non-contiguous extents that together make up the 307200 (150MB) blocks.
NOTE : Growing the metadevice does not modify the data or the filesystem inside the metadevice. If the metadevice contains a filesystem, you must use the appropriate command(s) to grow that filesystem after the metadevice has been grown.
There are no differences with soft partitioning in a diskset, other than having to specify the -s option on the commandline to specify the diskset name.
The only potential problem occurs when dealing with did disk devices that are in a SunCluster configuration. Unfortunately, the naming convention of the did devices is similar to that of SDS/SVM in that the disks are referred to as d #. This means that SDS/SVM could confuse a did disk with a metadevice when creating a soft partition.
The simple workaround to this problem is to use the full path to the did device on the metainint commandline in order to prevent any confusion.
For example, the following command to create a 1GB soft partition on /dev/did/rdsk/d7s0 would be invalid:
The metarecover command, with the -n and -v options, will display information about the soft partitons existing in a given slice.
The metarecover command actually scans the given slice for extent headers and prints the information that it finds about those headers.
In each slice/device, there are also 2 additional extent headers; one which preceeds the free space in the slice, and the one on the last block of the slice. These are printed as well. This is an easy way to determine how much free space is available in a slice for additional soft partitions.
In the above example, there were 2 soft partitions (d0 and d1) found on c1t0d0s0, as well as 17613458 blocks (approx 8.4GB) of unallocated free space.
IMPORTANT NOTE: The information printed by this command is relative to the extent header, not the soft partition itself. Therefore, the 'offset' is the starting location of the extent header, not the extent itself. Also, the 'length' given is the length of the extent plus the header. Therefore, in the example above, there are only 17613458 free blocks, not 17613459 blocks.
Because soft partitions can be layered above metadevices like mirrors or RAID5 devices (see layering , above), this command can also be run on them to determine the locations and sizes of the extent headers. In the example below, d0 is a RAID5 metadevice which has 4 soft partitions in it. There is no free space left in this device.
Fragmentation of free space will occur on a slice when there has been activity in creating, deleting, and possibly growing soft partitions. At this time, there is no method to defragment a disk.
For example, the following sequence of commands can result in some amount of fragmentation. First, create 2 10MB soft partitions on a slice.
Then, remove the first 10MB soft partition and then create a 20MB soft partition.
The Filesystem Manager supports the following mount options for NFS filesystems:
Setting up different views, or visibility, of the DNS space to internal and external resolvers is usually referred to as a Split DNS setup. There are several reasons an organization would want to set up its DNS this way.
One common reason for setting up a DNS system this way is to hide "internal" DNS information from "external" clients on the Internet. There is some debate as to whether or not this is actually useful. Internal DNS information leaks out in many ways (via email headers, for example) and most savvy "attackers" can find the information they need using other means.
Another common reason for setting up a Split DNS system is to allow internal networks that are behind filters or in RFC 1918 space (reserved IP space, as documented in RFC 1918 ) to resolve DNS on the Internet. Split DNS can also be used to allow mail from outside back in to the internal network.
Here is an example of a split DNS setup:
Let's say a company named Example, Inc. ( example.com ) has several corporate sites that have an internal network with reserved Internet Protocol (IP) space and an external demilitarized zone (DMZ), or "outside" section of a network, that is available to the public.
Example, Inc. wants its internal clients to be able to resolve external hostnames and to exchange mail with people on the outside. The company also wants its internal resolvers to have access to certain internal-only zones that are not available at all outside of the internal network.
In order to accomplish this, the company will set up two sets of name servers. One set will be on the inside network (in the reserved IP space) and the other set will be on bastion hosts, which are "proxy" hosts that can talk to both sides of its network, in the DMZ.
The internal servers will be configured to forward all queries, except queries for site1.internal , site2.internal , site1.example.com , and site2.example.com , to the servers in the DMZ. These internal servers will have complete sets of information for site1.example.com , site2.example.com , site1.internal , and site2.internal .
To protect the site1.internal and site2.internal domains, the internal name servers must be configured to disallow all queries to these domains from any external hosts, including the bastion hosts.
The external servers, which are on the bastion hosts, will be configured to serve the "public" version of the site1 and site2.example.com zones. This could include things such as the host records for public servers ( www.example.com and ftp.example.com ), and mail exchange (MX) records ( a.mx.example.com and b.mx.example.com ).
In addition, the public site1 and site2.example.com zones should have special MX records that contain wildcard (`*') records pointing to the bastion hosts. This is needed because external mail servers do not have any other way of looking up how to deliver mail to those internal hosts. With the wildcard records, the mail will be delivered to the bastion host, which can then forward it on to internal hosts.
Here's an example of a wildcard MX record:
Now that they accept mail on behalf of anything in the internal network, the bastion hosts will need to know how to deliver mail to internal hosts. In order for this to work properly, the resolvers on the bastion hosts will need to be configured to point to the internal name servers for DNS resolution.
Queries for internal hostnames will be answered by the internal servers, and queries for external hostnames will be forwarded back out to the DNS servers on the bastion hosts.
In order for all this to work properly, internal clients will need to be configured to query only the internal name servers for DNS queries. This could also be enforced via selective filtering on the network.
If everything has been set properly, Example, Inc. 's internal clients will now be able to:
Hosts on the Internet will be able to:
Here is an example configuration for the setup we just described above. Note that this is only configuration information; for information on how to configure your zone files, see the section called “Sample Configurations”
External (bastion host) DNS server config:
In the resolv.conf (or equivalent) on the bastion host(s):
Part Tag Flag Cylinders Size Blocks 0 unassigned wm 5 - 2035 999.63MB (2031/0/0) 2047248 1 unassigned wm 0 0 (0/0/0) 0 2 unassigned wm 0 0 (0/0/0) 0 3 unassigned wm 0 0 (0/0/0) 0 4 unassigned wm 0 0 (0/0/0) 0 5 unassigned wm 0 0 (0/0/0) 0 6 unassigned wm 0 0 (0/0/0) 0 7 unassigned wu 0 - 4 2.46MB (5/0/0) 5040
# metainit d2 -p c1t0d0s0 -o 2048 -b 1024
# metainit d1 -p c1t0d0s0 -o 1 -b 2024 d1: Soft Partition is setup # metainit d2 -p c1t0d0s0 -o 2000 -b 2024 metainit: hostname: d2: overlapping extents specified
# metainit d10 -p c1t11d0s4 100m d10: Soft Partition is setup # metainit d20 -m d10 metainit: hostname: d10: invalid unit
# metainit d10 -p c1t0d0s0 100m d10: Soft Partition is setup # metainit d20 1 1 d10 d20: Concat/Stripe is setup # metainit d30 -m d20 d30: Mirror is setup # metainit d11 -p c2t0d0s0 100m d11: Soft Partition is setup # metainit d21 1 1 d11 d21: Concat/Stripe is setup # metattach d30 d21 d30: submirror d21 is attached
# metastat d30 d30: Mirror Submirror 0: d20 State: Okay Submirror 1: d21 State: Okay Pass: 1 Read option: roundrobin (default) Write option: parallel (default) Size: 204624 blocks d20: Submirror of d30 State: Okay Size: 204624 blocks Stripe 0: Device Start Block Dbase State Hot Spare d10 0 No Okay d10: Soft Partition Component: c1t0d0s0 State: Okay Size: 204800 blocks Extent Start Block Block count 0 1 204800 d21: Submirror of d30 State: Okay Size: 204624 blocks Stripe 0: Device Start Block Dbase State Hot Spare d11 0 No Okay d11: Soft Partition Component: c2t0d0s0 State: Okay Size: 204800 blocks Extent Start Block Block count 0 1 204800
# metainit d1 -p c1t0d0s0 10m d1: Soft Partition is setup # metainit d2 -p c2t0d0s0 10m d2: Soft Partition is setup # metainit d3 -p c3t0d0s0 10m d3: Soft Partition is setup # metainit d4 -p c4t0d0s0 10m d4: Soft Partition is setup # metainit d10 -r d1 d2 d3 d4 d10: RAID is setup
# metastat d10 d10: RAID State: Okay Interlace: 32 blocks Size: 59472 blocks Original device: Size: 60384 blocks Device Start Block Dbase State Hot Spare d1 330 No Okay d2 330 No Okay d3 330 No Okay d4 330 No Okay d1: Soft Partition Component: c1t0d2s0 State: Okay Size: 20480 blocks Extent Start Block Block count 0 1 20480 d2: Soft Partition Component: c1t0d4s0 State: Okay Size: 20480 blocks Extent Start Block Block count 0 1 20480 d3: Soft Partition Component: c1t1d1s0 State: Okay Size: 20480 blocks Extent Start Block Block count 0 1 20480 d4: Soft Partition Component: c1t1d3s0 State: Okay Size: 20480 blocks Extent Start Block Block count 0 1 20480
# metainit d1 -p c1t0d0s0 500m d1: Soft Partition is setup # metainit d2 -p c2t0d0s0 50m d2: Soft Partition is setup # metainit d10 -t d1 d2 d1: Trans is setup
# metastat d10 d10: Trans State: Okay Size: 1024000 blocks Master Device: d1 Logging Device: d2 d1: Soft Partition Component: c1t1d3s0 State: Okay Size: 1024000 blocks Extent Start Block Block count 0 1 1024000 d2: Logging device for d10 State: Okay Size: 102142 blocks d2: Soft Partition Component: c1t1d1s0 State: Okay Size: 102400 blocks Extent Start Block Block count 0 1 102400
# metain
Nightmare Express Hentai
Dsan Porn Comics
Porn Website Reviews

Stuff_Itinme

Report Page