免费注册 查看新帖 |

Chinaunix

  平台 论坛 博客 文库
最近访问板块 发新帖
查看: 2160 | 回复: 3

Berkeley [close] style,SysV什么意思,不知以下文档有中文否? [复制链接]

论坛徽章:
0
发表于 2004-07-15 22:14 |显示全部楼层
To view tape device files on Solaris[TM] hosts, go to the /dev/rmt directory. Herein you will find a series of files comprised of numbers and letters. They will look something like this:

root[ksh]@bulldog# ls /dev/rmt

0 0m 1cn 1ub 2lb

0b 0mb 1h 1ubn 2lbn

0bn 0mbn 1hb 1un 2ln

0c 0mn 1hbn 2 2m

0cb 0n 1hn 2b 2mb

0cbn 0u 1l 2bn 2mbn

0cn 0ub 1lb 2c 2mn

0h 0ubn 1lbn 2cb 2n

0hb 0un 1ln 2cbn 2u

0hbn 1 1m 2cn 2ub

0hn 1b 1mb 2h 2ubn

0l 1bn 1mbn 2hb 2un

0lb 1c 1mn 2hbn sg.conf.all

0lbn 1cb 1n 2hn sg.links.all

0ln 1cbn 1u 2l st.conf.all

These entries are just symbolic links to real character (device) files. They are named in this way for purely aesthetic reasons, as the actual device paths are extremely long and ugly. For example, a long listing of the device file 0mbn would show the following:

lrwxrwxrwx 1 root other 65 Jun 20 15:18 0mbn ->; ../../devices/sbus@1f,0/espdma@e,8400000/esp@e,8800000/st@1,0:mbn

If one were to do a long listing of the device path, the output would look like this:

root[ksh]@bulldog# ls -la ../../devices/sbus@1f,0/espdma@e,8400000/esp@e,8800000/st@1,0:mbn

crw-rw-rw- 1 root sys 33, 77 Jun 29 03:37 ../../devices/sbus@1f,0/espdma@e,8400000/esp@e,8800000/st@1,0:mbn

The 'c' in the permissions mask indicates that the file is a character file. The permissions are read and write for owner, read/write for the group 'sys', and read/write for all others. This file is rarely manipulated or examined directly, as the vast majority of applications and user interactions take place at the link level. Therefore, it is important to understand what the /dev/rmt entries mean instead of concentrating on the character file itself.

II. Breaking down the pieces:

The numbers in front of the series of one to three letters stands for the logical device number each tape drive holds. The first one found by the system is given the designation 0, the second is 1, the third is 2, and so forth. These numbers do NOT correspond to SCSI i.d. Numbers, as can be seen in the long listing above (the st@1,0 means it is SCSI tape device 0 at SCSI i.d. 1, LUN 0). For our example, we will use files associated with device 0.

Key terms used in forthcoming explanations:

-Rewinding: tape will be rewound after last end-of-file (EOF) mark is written to the ufsdump or other backup

-Non-rewinding: tape will be left positioned where last EOF was written. This facilitates continued archives being created on a piece of media without having to space out to the end of the previous backup first.

-Berkeley [close] style: indicates the way in which EOF spacing will be handled by Solaris. This is different from how System V (or AT&T) close style operates. Essentially, it means that when reading past an end-of-file mark, the drive returns the first record of the next file, and when closing the no rewind device, it skips a tape space forward. Device files used by Solaris will be Berkely style almost all the time. If you want more information, read SRDB 15385.

-Density: Different tape drives use different density settings. Basically, this parameter informs the system about the length of tapes being used. A particular tape drive can use different density device files; they are not limited to only one density.

-Compression: self-evident; refers to the algorithmic ratio used by the driver in compacting data for storage on removable media. There are different levels of compression in Solaris device files.

Now, on to the explanations. Beside each device file listed below is a dissection of what the letters mean. All these device files contain different attributes but refer to the same physical tape drive, 0, and can be used at will.

0 - This assumes a standard rewinding device file with no compression.

0b - Berkely style, rewinding

0bn - Berkely style, non-rewinding.

0c - SysV, compression, rewinding

0cb - Berkeley style, rewinding

0cbn - Berkely style, compression, non-rewinding

0cn - SysV, compression, non-rewinding

0h - SysV, high density, rewinding

0hb - high density, Berkeley, rewinding

0hbn - high density, Berkeley, non-rewinding

0hn - SysV, high density, non-rewinding

0l - SysV, low density, rewinding

0lb - low density, Berkeley, rewinding

0lbn - low density, Berkely, non-rewinding

0ln - SysV, low density, non-rewinding

0m - SysV, medium density, rewinding

0mb - medim density, Berkely, rewinding

0mbn - medium density, Berkely, non-rewinding. Very commonly used device.

0mn - SysV, medium density, non-rewinding

0n - SysV, no compression, non-rewinding

0u - SysV, ultra density, rewinding

0ub - ultra density, Berkeley, rewinding

0ubn - ultra density, Berkely, non-rewinding

0un - SysV, ultra density, non-rewinding

Similar entries for other logical device numbers will be found as well. Whenever the system creates tape device files, the full spectrum of possible device files is created. This can be seen above, in the first example, where entries for devices 0, 1, and 2 are found.

**NOTE: the number found in /dev/rmt is not necessarily indicative of a unique device. If a boot -r is done, device numbers in /dev/rmt may be incremented. The sure way to know is to do a long listing of the /dev/rmt device file and check the 'st @ <#>;' parameter.

III. How to create tape device files

There are two ways that tape device files are created.

-One is through the re-probing done when a boot -r is executed. The buses on a host are rescanned and the device paths compared to those already existing in the /etc/path_to_inst file. If an entry exists for particular devices, the number for that device may be incremented by one. In other words, if two new tape drives are added to a brand new system, entries 0 and 1 will exist. If a boot -r is done with only those two drives attached, /dev/rmt may now contain entries for devices 0,1,2 and 3. Device files for 0 and 1 will be unusable, almost as if they are stale.

-A second way to create device files can be done if a boot -r is not possible. It involves a sort of 'soft' probe of the SCSI buses for new hardware, and a user-supplied series of commands for building device files and symbolic links. These commands are implicitly run when a boot -r is executed, but users can run them instead of bringing a system all the way down. They should be issued in succession:

drvconfig - The default operation of drvconfig is to create the /devices directory tree that describes, in the filesystem namespace, the hardware layout of a particular machine. Hardware devices present on the machine and powered on as well as pseudo-drivers are represented under /devices. Normally this command is run automatically after a new driver has been installed and the system has been rebooted. It can also be run as a probe if the system can't go down.

tapes - tapes creates symbolic links in the /dev/rmt directory to the actual tape device special files under the /devices directory tree. 'tapes' searches the kernel device tree to see what tape devices are attached to the system. For each tape drive found, the following steps are performed:

1. The /dev/rmt directory is searched for a /dev/rmt/n entry that is a symbolic link to the /devices special node of the current tape drive. If one is found, this determines the logical controller number of the tape drive.

2. The rest of the special devices associated with the drive are checked, and incorrect symbolic links are removed and necessary ones added.

4. If none are found, a new logical controller number is assigned (the lowest-unused number), and new symbolic links are created for all the special devices associated with the drive.

5. If none are found, a new logical controller number is assigned (the lowest-unused number), and new symbolic links are created for all the special devices associated with the drive.

The tapes command does not remove links to non-existent devices; these must be removed by hand.

devlinks - devlinks creates symbolic links from the /dev directory tree to the actual block- and character-special device nodes under the /devices directory tree. The links are created according to specifications found in the table-file (by default etc/devlink.tab).

After running these commands, device files should exist in the /dev/rmt directory that reflect a new date and time stamp. This does not always work as well as an actual boot -r, as the latter forces a full probe.

论坛徽章:
0
发表于 2004-07-15 23:21 |显示全部楼层

Berkeley [close] style,SysV什么意思,不知以下文档有中文否?

能问一下这篇的出处吗?

论坛徽章:
0
发表于 2004-07-16 08:14 |显示全部楼层

Berkeley [close] style,SysV什么意思,不知以下文档有中文否?

To view tape device files on Solaris[TM] hosts, go to the /dev/rmt directory. Herein you will find a series of files comprised of numbers and letters. They will look something like this:
在solaris主机上浏览磁带驱动器上的文件,去/dev/rmt目录。在这里你找到一系列的由字母和数学组成的文件。
它们类似:

root[ksh]@bulldog# ls /dev/rmt

0 0m 1cn 1ub 2lb

0b 0mb 1h 1ubn 2lbn

0bn 0mbn 1hb 1un 2ln

0c 0mn 1hbn 2 2m

0cb 0n 1hn 2b 2mb

0cbn 0u 1l 2bn 2mbn

0cn 0ub 1lb 2c 2mn

0h 0ubn 1lbn 2cb 2n

0hb 0un 1ln 2cbn 2u

0hbn 1 1m 2cn 2ub

0hn 1b 1mb 2h 2ubn

0l 1bn 1mbn 2hb 2un

0lb 1c 1mn 2hbn sg.conf.all

0lbn 1cb 1n 2hn sg.links.all

0ln 1cbn 1u 2l st.conf.all

These entries are just symbolic links to real character (device) files. They are named in this way for purely aesthetic reasons, as the actual device paths are extremely long and ugly. For example, a long listing of the device file 0mbn would show the following:
这些整个都只是对真正的字符设备文件的符号链接。它们的命名方式纯粹是为了美观,事实上的设备路径是非常的长而且很难看。例如,一个设备文件0mbn将显示下面很长的一个列表:
lrwxrwxrwx 1 root other 65 Jun 20 15:18 0mbn ->; ../../devices/sbus@1f,0/espdma@e,8400000/esp@e,8800000/st@1,0:mbn

If one were to do a long listing of the device path, the output would look like this:
如果一个设备路径占和了很长的列表,那么输出就会像这样:

root[ksh]@bulldog# ls -la ../../devices/sbus@1f,0/espdma@e,8400000/esp@e,8800000/st@1,0:mbn

crw-rw-rw- 1 root sys 33, 77 Jun 29 03:37 ../../devices/sbus@1f,0/espdma@e,8400000/esp@e,8800000/st@1,0:mbn

The 'c' in the permissions mask indicates that the file is a character file. The permissions are read and write for owner, read/write for the group 'sys', and read/write for all others. This file is rarely manipulated or examined directly, as the vast majority of applications and user interactions take place at the link level. Therefore, it is important to understand what the /dev/rmt entries mean instead of concentrating on the character file itself.
权限掩码中的字符“c”表示该文件是一个字符设备文件。权限为拥有者为读写权限,其所在组“sys”权限也读写,所有其它用户也为读写权限。这个文件很少维护或直接进行检查,极大部分应用程序和用户只在链接层与其发生交互作用。因此,重要的是理解/dev/rmt整体的意义,而不是字符设备文件本身。
II. Breaking down the pieces:
现将信息分解如下:
The numbers in front of the series of one to three letters stands for the logical device number each tape drive holds. The first one found by the system is given the designation 0, the second is 1, the third is 2, and so forth. These numbers do NOT correspond to SCSI i.d. Numbers, as can be seen in the long listing above (the st@1,0 means it is SCSI tape device 0 at SCSI i.d. 1, LUN 0). For our example, we will use files associated with device 0.
一到三个字母前的数字代表每个磁带占用的逻辑驱动器号。系统第一个发现的设定目标为0,第二个发现的为1,第三个发现的为2等等,以此类推。这些数字并不对应上面看到的长列表中的SCSI的ID号。在我们的中,我们将使用与设备0相关联的文件。
Key terms used in forthcoming explanations:
现将即将使用的关键术语解释如下:

-Rewinding: tape will be rewound after last end-of-file (EOF) mark is written to the ufsdump or other backup
――倒带:ufsdump或其它备份工具写到最后标记(到达磁带尾)时磁带自动回卷。
-Non-rewinding: tape will be left positioned where last EOF was written. This facilitates continued archives being created on a piece of media without having to space out to the end of the previous backup first.
――不倒带:到达磁带尾也不回卷,保留在原位。这让后续的归档更容易创建在介质上,如果没有这样做则必须把前面首次备份的尾部隔开。
-Berkeley [close] style: indicates the way in which EOF spacing will be handled by Solaris. This is different from how System V (or AT&T) close style operates. Essentially, it means that when reading past an end-of-file mark, the drive returns the first record of the next file, and when closing the no rewind device, it skips a tape space forward. Device files used by Solaris will be Berkely style almost all the time. If you want more information, read SRDB 15385.
伯克利(结束)风格:表示尾部间距将由solaris处理的一种方式。这不同于贝尔实验的结束方式。基本上,它意味着当读过文件尾标记时,驱动器返回下一文件的首记录,且当没回卷的设备结束时,它路过一个磁盘空间前进。Solaris使用的设备文件几乎每次都是伯克利风格的。更多信息参见SRDB 15385。
-Density: Different tape drives use different density settings. Basically, this parameter informs the system about the length of tapes being used. A particular tape drive can use different density device files; they are not limited to only one density.
密度:不同的磁带驱动器使用不同的磁带密度。基本上,这个参数提示系统磁带将被用来使用的长度。一个特制的磁带可以应用不同密度的设备文件;他们不局限于一种密度。
-Compression: self-evident; refers to the algorithmic ratio used by the driver in compacting data for storage on removable media. There are different levels of compression in Solaris device files.
压缩:引用某种算法通过驱动器将数据压缩存储到可移动介质上。在solaris设备文件中可以使用不同级别的压缩。
Now, on to the explanations. Beside each device file listed below is a dissection of what the letters mean. All these device files contain different attributes but refer to the same physical tape drive, 0, and can be used at will.
比较每个列出的设备文件,下面是对每个字母意思的讨论。所有这些设备文件包含了不同属性,但都引用了相同的物理磁带驱动器0,且能任意使用。

论坛徽章:
0
发表于 2004-07-16 08:38 |显示全部楼层

Berkeley [close] style,SysV什么意思,不知以下文档有中文否?

感谢精灵王做的精彩翻译,看来您也是花费了很长时间。
这篇文档是我从Sun工程师那里得来的,我当时问他们这些对应同一个磁带设备的不同逻辑名怎么使用,有什么区别。
您需要登录后才可以回帖 登录 | 注册

本版积分规则 发表回复

SACC2019中国系统架构师大会

【数字转型 架构演进】SACC2019中国系统架构师大会
2019年10月31日~11月2日第11届中国系统架构师大会(SACC2019)将在北京隆重召开。四大主线并行的演讲模式,1个主会场、20个技术专场、超千人参与的会议规模,100+来自互联网、金融、制造业、电商等领域的嘉宾阵容,将为广大参会者提供一场最具价值的技术交流盛会。




----------------------------------------

大会官网>>
  

北京盛拓优讯信息技术有限公司. 版权所有 16024965号-6 北京市公安局海淀分局网监中心备案编号:11010802020122
中国互联网协会会员  联系我们:huangweiwei@it168.com
感谢所有关心和支持过ChinaUnix的朋友们 转载本站内容请注明原作者名及出处

清除 Cookies - ChinaUnix - Archiver - WAP - TOP