文件系统是一个在计算机上帮你去管理数据怎么去存储和检索的数据结构。文件系统也可以被视作是磁盘上的物理（或扩展）分区。如果它没有很好地被维护或定期监视，它可能在长期运行中出现各种各样的错误或损坏。

这里有几个可能导致文件系统出问题的因素：系统崩溃、硬件或软件故障、 有问题的驱动和程序、不正确的优化、大量的数据过载加上一些小故障。

这其中的任何一个问题都可以导致 Linux 不能顺利地挂载（或卸载）一个文件系统，从而导致系统故障。

扩展阅读：Linux 中判断文件系统类型（Ext2, Ext3 或 Ext4）的 7 种方法

另外，受损的文件系统运行在你的系统上可能导致操作系统中的组件或用户应用程序的运行时错误，它可能会进一步扩大到服务器数据的丢失。为避免文件系统错误或损坏，你需要去持续关注它的健康状况。

在这篇文章中，我们将介绍监视或维护一个 ext2、ext3 和 ext4 文件系统健康状况的工具。在这里描述的所有工具都需要 root 用户权限，因此，需要使用 sudo 命令去运行它们。

怎么去查看 EXT2/EXT3/EXT4 文件系统信息

dumpe2fs 是一个命令行工具，用于去转储 ext2/ext3/ext4 文件系统信息，这意味着它可以显示设备上文件系统的超级块和块组信息。

在运行 dumpe2fs 之前，先去运行 df -hT 命令，确保知道文件系统的设备名。

$ sudo dumpe2fs /dev/sda10

示例输出：

dumpe2fs 1.42.13 (17-May-2015)
Filesystem volume name:   
Last mounted on:          /
Filesystem UUID:          bb29dda3-bdaa-4b39-86cf-4a6dc9634a1b
Filesystem magic number:  0xEF53
Filesystem revision #:    1 (dynamic)
Filesystem features:      has_journal ext_attr resize_inode dir_index filetype needs_recovery extent flex_bg sparse_super large_file huge_file uninit_bg dir_nlink extra_isize
Filesystem flags:         signed_directory_hash 
Default mount options:    user_xattr acl
Filesystem state:         clean
Errors behavior:          Continue
Filesystem OS type:       Linux
Inode count:              21544960
Block count:              86154752
Reserved block count:     4307737
Free blocks:              22387732
Free inodes:              21026406
First block:              0
Block size:               4096
Fragment size:            4096
Reserved GDT blocks:      1003
Blocks per group:         32768
Fragments per group:      32768
Inodes per group:         8192
Inode blocks per group:   512
Flex block group size:    16
Filesystem created:       Sun Jul 31 16:19:36 2016
Last mount time:          Mon Nov  6 10:25:28 2017
Last write time:          Mon Nov  6 10:25:19 2017
Mount count:              432
Maximum mount count:      -1
Last checked:             Sun Jul 31 16:19:36 2016
Check interval:           0 ()
Lifetime writes:          2834 GB
Reserved blocks uid:      0 (user root)
Reserved blocks gid:      0 (group root)
First inode:              11
Inode size:           256
Required extra isize:     28
Desired extra isize:      28
Journal inode:            8
First orphan inode:       6947324
Default directory hash:   half_md4
Directory Hash Seed:      9da5dafb-bded-494d-ba7f-5c0ff3d9b805
Journal backup:           inode blocks
Journal features:         journal_incompat_revoke
Journal size:             128M
Journal length:           32768
Journal sequence:         0x00580f0c
Journal start:            12055

你可以通过 -b 选项来显示文件系统中的任何保留块，比如坏块（无输出说明没有坏块）：

$ sudo dumpe2fs -b

检查 EXT2/EXT3/EXT4 文件系统的错误

e2fsck 用于去检查 ext2/ext3/ext4 文件系统的错误。fsck 可以检查并且可选地 修复 Linux 文件系统；它实际上是底层 Linux 提供的一系列文件系统检查器 （fsck.fstype，例如 fsck.ext3、fsck.sfx 等等） 的前端程序。

记住，在系统引导时，Linux 会为 /etc/fstab 配置文件中被标为“检查”的分区自动运行 e2fsck/fsck。而在一个文件系统没有被干净地卸载时，一般也会运行它。

注意：不要在已挂载的文件系统上运行 e2fsck 或 fsck，在你运行这些工具之前，首先要去卸载分区，如下所示。

$ sudo unmount /dev/sda10
$ sudo fsck /dev/sda10

此外，可以使用 -V 开关去启用详细输出，使用 -t 去指定文件系统类型，像这样：

$ sudo fsck -Vt ext4 /dev/sda10

调优 EXT2/EXT3/EXT4 文件系统

我们前面提到过，导致文件系统损坏的其中一个因素就是不正确的调优。你可以使用 tune2fs 实用程序去改变 ext2/ext3/ext4 文件系统的可调优参数，像下面讲的那样。

去查看文件系统的超级块，包括参数的当前值，使用 -l 选项，如下所示。

$ sudo tune2fs -l /dev/sda10

示例输出：

tune2fs 1.42.13 (17-May-2015)
Filesystem volume name:   
Last mounted on:          /
Filesystem UUID:          bb29dda3-bdaa-4b39-86cf-4a6dc9634a1b
Filesystem magic number:  0xEF53
Filesystem revision #:    1 (dynamic)
Filesystem features:      has_journal ext_attr resize_inode dir_index filetype needs_recovery extent flex_bg sparse_super large_file huge_file uninit_bg dir_nlink extra_isize
Filesystem flags:         signed_directory_hash 
Default mount options:    user_xattr acl
Filesystem state:         clean
Errors behavior:          Continue
Filesystem OS type:       Linux
Inode count:              21544960
Block count:              86154752
Reserved block count:     4307737
Free blocks:              22387732
Free inodes:              21026406
First block:              0
Block size:               4096
Fragment size:            4096
Reserved GDT blocks:      1003
Blocks per group:         32768
Fragments per group:      32768
Inodes per group:         8192
Inode blocks per group:   512
Flex block group size:    16
Filesystem created:       Sun Jul 31 16:19:36 2016
Last mount time:          Mon Nov  6 10:25:28 2017
Last write time:          Mon Nov  6 10:25:19 2017
Mount count:              432
Maximum mount count:      -1
Last checked:             Sun Jul 31 16:19:36 2016
Check interval:           0 ()
Lifetime writes:          2834 GB
Reserved blocks uid:      0 (user root)
Reserved blocks gid:      0 (group root)
First inode:              11
Inode size:           256
Required extra isize:     28
Desired extra isize:      28
Journal inode:            8
First orphan inode:       6947324
Default directory hash:   half_md4
Directory Hash Seed:      9da5dafb-bded-494d-ba7f-5c0ff3d9b805
Journal backup:           inode blocks

接下来，使用 -c 标识，你可以设置文件系统在挂载多少次后将进行 e2fsck 检查。下面这个命令指示系统每挂载 4 次之后，去对 /dev/sda10 运行 e2fsck。

$ sudo tune2fs -c 4 /dev/sda10
tune2fs 1.42.13 (17-May-2015)
Setting maximal mount count to 4

你也可以使用 -i 选项定义两次文件系统检查的时间间隔。下列的命令在两次文件系统检查之间设置了一个 2 天的时间间隔。

$ sudo tune2fs  -i  2d  /dev/sda10
tune2fs 1.42.13 (17-May-2015)
Setting interval between checks to 172800 seconds

现在，如果你运行下面的命令，你可以看到对 /dev/sda10 已经设置了文件系统检查的时间间隔。

$ sudo tune2fs -l /dev/sda10

示例输出：

Filesystem created:       Sun Jul 31 16:19:36 2016
Last mount time:          Mon Nov  6 10:25:28 2017
Last write time:          Mon Nov  6 13:49:50 2017
Mount count:              432
Maximum mount count:      4
Last checked:             Sun Jul 31 16:19:36 2016
Check interval:           172800 (2 days)
Next check after:         Tue Aug  2 16:19:36 2016
Lifetime writes:          2834 GB
Reserved blocks uid:      0 (user root)
Reserved blocks gid:      0 (group root)
First inode:              11
Inode size:           256
Required extra isize:     28
Desired extra isize:      28
Journal inode:            8
First orphan inode:       6947324
Default directory hash:   half_md4
Directory Hash Seed:      9da5dafb-bded-494d-ba7f-5c0ff3d9b805
Journal backup:           inode blocks

要改变缺省的日志参数，可以使用 -J 选项。这个选项也有子选项： size=journal-size （设置日志的大小）、device=external-journal （指定日志存储的设备）和 location=journal-location （定义日志的位置）。

注意，这里一次仅可以为文件系统设置一个日志大小或设备选项：

$ sudo tune2fs -J size=4MB /dev/sda10

最后，同样重要的是，可以去使用 -L 选项设置文件系统的卷标，如下所示。

$ sudo tune2fs -L "ROOT" /dev/sda10

调试 EXT2/EXT3/EXT4 文件系统

debugfs 是一个简单的、交互式的、基于 ext2/ext3/ext4 文件系统的命令行调试器。它允许你去交互式地修改文件系统参数。输入 ? 查看子命令或请求。

$ sudo debugfs /dev/sda10

缺省情况下，文件系统将以只读模式打开，使用 -w 标识去以读写模式打开它。使用 -c 选项以灾难（catastrophic）模式打开它。

示例输出：

debugfs 1.42.13 (17-May-2015)
debugfs:  ?
Available debugfs requests:
show_debugfs_params, params
Show debugfs parameters
open_filesys, open       Open a filesystem
close_filesys, close     Close the filesystem
freefrag, e2freefrag     Report free space fragmentation
feature, features        Set/print superblock features
dirty_filesys, dirty     Mark the filesystem as dirty
init_filesys             Initialize a filesystem (DESTROYS DATA)
show_super_stats, stats  Show superblock statistics
ncheck                   Do inode->name translation
icheck                   Do block->inode translation
change_root_directory, chroot
....

要展示未使用空间的碎片，使用 freefrag 请求，像这样：

debugfs: freefrag

示例输出：

Device: /dev/sda10
Blocksize: 4096 bytes
Total blocks: 86154752
Free blocks: 22387732 (26.0%)
Min. free extent: 4 KB 
Max. free extent: 2064256 KB
Avg. free extent: 2664 KB
Num. free extent: 33625
HISTOGRAM OF FREE EXTENT SIZES:
Extent Size Range :  Free extents   Free Blocks  Percent
4K...    8K-  :          4883          4883    0.02%
8K...   16K-  :          4029          9357    0.04%
16K...   32K-  :          3172         15824    0.07%
32K...   64K-  :          2523         27916    0.12%
64K...  128K-  :          2041         45142    0.20%
128K...  256K-  :          2088         95442    0.43%
256K...  512K-  :          2462        218526    0.98%
512K... 1024K-  :          3175        571055    2.55%
1M...    2M-  :          4551       1609188    7.19%
2M...    4M-  :          2870       1942177    8.68%
4M...    8M-  :          1065       1448374    6.47%
8M...   16M-  :           364        891633    3.98%
16M...   32M-  :           194        984448    4.40%
32M...   64M-  :            86        873181    3.90%
64M...  128M-  :            77       1733629    7.74%
128M...  256M-  :            11        490445    2.19%
256M...  512M-  :            10        889448    3.97%
512M... 1024M-  :             2        343904    1.54%
1G...    2G-  :            22      10217801   45.64%
debugfs:  

通过去简单浏览它所提供的简要描述，你可以试试更多的请求，比如，创建或删除文件或目录，改变当前工作目录等等。要退出 debugfs，使用 q。

现在就这些！我们收集了不同分类下的相关文章，你可以在里面找到对你有用的内容。

文件系统使用信息：

1. 12 Useful “df” Commands to Check Disk Space in Linux
2. Pydf an Alternative “df” Command to Check Disk Usage in Different Colours
3. 10 Useful du (Disk Usage) Commands to Find Disk Usage of Files and Directories

检查磁盘或分区健康状况：

1. 3 Useful GUI and Terminal Based Linux Disk Scanning Tools
2. How to Check Bad Sectors or Bad Blocks on Hard Disk in Linux
3. How to Repair and Defragment Linux System Partitions and Directories

维护一个健康的文件系统可以提升你的 Linux 系统的整体性能。如果你有任何问题或更多的想法，可以使用下面的评论去分享。

via: https://www.tecmint.com/manage-ext2-ext3-and-ext4-health-in-linux/

作者：Aaron Kili 译者：qhwdw 校对：wxy

本文由 LCTT 原创编译，Linux中国 荣誉推出

开放容器计划（OCI）和原生云计算基金会（CNCF）的代表说，Kubernetes 和容器可以在降低程序员和系统管理成本的同时加速部署进程，从被忽视的 Kubernetes 特性（比如命令空间）开始，去利用 Kubernetes 和它的相关工具运行一个原生云架构。

Kubernetes 不止是一个云容器管理器。正如 Steve Pousty，他是 Red Hat 支持的 OpenShift 的首席开发者，在 Linux 基金会的开源峰会上的讲演中解释的那样，Kubernetes 提供了一个 “使用容器进行原生云计算的通用操作平台”。

Pousty 的意思是什么？先让我们复习一下基础知识。

开源容器计划（OCI）和 原生云计算基金会 （CNCF）的执行董事 Chris Aniszczyk 的解释是，“原生云计算使用开源软件栈将应用程序部署为微服务，打包每一个部分到其容器中，并且动态地编排这些容器以优化资源使用”。Kubernetes 一直在关注着原生云计算的最新要素。这将最终将导致 IT 中很大的一部分发生转变，如从服务器到虚拟机，从 构建包 buildpack 到现在的 容器。

会议主持人表示，数据中心的演变将节省相当可观的成本，部分原因是它需要更少的专职员工。例如，据 Aniszczyk 说，通过使用 Kubernetes，谷歌每 10000 台机器仅需要一个网站可靠性工程师（LCTT 译注：即 SRE）。

实际上，系统管理员可以利用新的 Kubernetes 相关的工具的优势，并了解那些被低估的功能。

构建一个原生云平台

Pousty 解释说，“对于 Red Hat 来说，Kubernetes 是云 Linux 的内核。它是每个人都可以构建于其上的基础设施”。

例如，假如你在一个容器镜像中有一个应用程序。你怎么知道它是安全的呢？ Red Hat 和其它的公司使用 OpenSCAP，它是基于 安全内容自动化协议 Security Content Automation Protocol （SCAP）的，是使用标准化的方式表达和操作安全数据的一个规范。OpenSCAP 项目提供了一个开源的强化指南和配置基准。选择一个合适的安全策略，然后，使用 OpenSCAP 认可的安全工具去使某些由 Kubernetes 控制的容器中的程序遵守这些定制的安全标准。

Red Hat 将使用 原子扫描 Atomic Scan 来自动处理这个过程；它借助 OpenSCAP 提供者 provider 来扫描容器镜像中已知的安全漏洞和策略配置问题。原子扫描会以只读方式加载文件系统。这些通过扫描的容器，会在一个可写入的目录存放扫描器的输出。

Pousty 指出，这种方法有几个好处，主要是，“你可以扫描一个容器镜像而不用实际运行它”。因此，如果在容器中有糟糕的代码或有缺陷的安全策略，它不会影响到你的系统。

原子扫描比手动运行 OpenSCAP 快很多。 因为容器从启用到消毁可能就在几分钟或几小时内，原子扫描允许 Kubernetes 用户在（很快的）容器生命期间保持容器安全，而不是在更缓慢的系统管理时间跨度里进行。

关于工具

帮助系统管理员和 DevOps 管理大部分 Kubernetes 操作的另一个工具是 CRI-O。这是一个基于 OCI 实现的 Kubernetes 容器运行时接口。CRI-O 是一个守护进程， Kubernetes 可以用于运行存储在 Docker 仓库中的容器镜像，Dan Walsh 解释说，他是 Red Hat 的顾问工程师和 SELinux 项目领导者。它允许你直接从 Kubernetes 中启动容器镜像，而不用花费时间和 CPU 处理时间在 Docker 引擎 上启动。并且它的镜像格式是与容器无关的。

在 Kubernetes 中， kubelet 管理 pod（容器集群）。使用 CRI-O，Kubernetes 及其 kubelet 可以管理容器的整个生命周期。这个工具也不是和 Docker 镜像捆绑在一起的。你也可以使用新的 OCI 镜像格式 和 CoreOS 的 rkt 容器镜像。

同时，这些工具正在成为一个 Kubernetes 栈：编排系统、容器运行时接口 （CRI）和 CRI-O。Kubernetes 首席工程师 Kelsey Hightower 说，“我们实际上不需要这么多的容器运行时——无论它是 Docker 还是 rkt。只需要给我们一个到内核的 API 就行”，这个结果是这些技术人员的承诺，是推动容器比以往更快发展的强大动力。

Kubernetes 也可以加速构建容器镜像。目前为止，有三种方法来构建容器。第一种方法是通过一个 Docker 或者 CoreOS 去构建容器。第二种方法是注入定制代码到一个预构建镜像中。最后一种方法是， 资产生成管道 Asset Generation Pipeline 使用容器去编译那些 资产 asset ，然后其被包含到使用 Docker 的 多阶段构建 Multi-Stage Build 所构建的随后镜像中。

现在，还有一个 Kubernetes 原生的方法：Red Hat 的 Buildah， 这是一个脚本化的 shell 工具 用于快速、高效地构建 OCI 兼容的镜像和容器。Buildah 降低了容器环境的学习曲线，简化了创建、构建和更新镜像的难度。Pousty 说。你可以使用它和 Kubernetes 一起基于应用程序的调用来自动创建和使用容器。Buildah 也更节省系统资源，因为它不需要容器运行时守护进程。

因此，比起真实地引导一个容器和在容器内按步骤操作，Pousty 说，“挂载该文件系统，就如同它是一个常规的文件系统一样做一些正常操作，并且在最后提交”。

这意味着你可以从一个仓库中拉取一个镜像，创建它所匹配的容器，并且优化它。然后，你可以使用 Kubernetes 中的 Buildah 在你需要时去创建一个新的运行镜像。最终结果是，他说，运行 Kubernetes 管理的容器化应用程序比以往速度更快，需要的资源更少。

你所不知道的 Kubernetes 拥有的特性

你不需要在其它地方寻找工具。Kubernetes 有几个被低估的特性。

根据谷歌云全球产品经理 Allan Naim 的说法，其中一个是 Kubernetes 命名空间。Naim 在开源峰会上谈及 “Kubernetes 最佳实践”，他说，“很少有人使用命名空间，这是一个失误。”

“命名空间是将一个单个的 Kubernetes 集群分成多个虚拟集群的方法”，Naim 说。例如，“你可以认为命名空间就是 姓氏 family name ”，因此，假如说 “Simth” 用来标识一个家族，如果有个成员 Steve Smith，他的名字就是 “Steve”，但是，家族范围之外的，它就是 “Steve Smith” 或称 “来自 Chicago 的 Steve Smith”。

严格来说，“命名空间是一个逻辑分区技术，它允许一个 Kubernetes 集群被多个用户、用户团队或者一个用户的多个不能混淆的应用程序所使用。Naim 解释说，“每个用户、用户团队、或者应用程序都可以存在于它的命名空间中，与集群中的其他用户是隔离的，并且可以像你是这个集群的唯一用户一样操作它。”

Practically 说，你可以使用命名空间去构建一个企业的多个业务/技术的实体进入 Kubernetes。例如，云架构可以通过映射产品、地点、团队和成本中心为命名空间，从而定义公司的命名空间策略。

Naim 建议的另外的方法是，去使用命名空间将软件开发 流程 pipeline 划分到分离的命名空间中，如测试、质量保证、 预演 staging 和成品等常见阶段。或者命名空间也可以用于管理单独的客户。例如，你可以为每个客户、客户项目、或者客户业务单元去创建一个单独的命名空间。它可以更容易地区分项目，避免重用相同名字的资源。

然而，Kubernetes 现在还没有提供一个跨命名空间访问的控制机制。因此，Naim 建议你不要使用这种方法去对外公开程序。还要注意的是，命名空间也不是一个管理的“万能药”。例如，你不能将命名空间嵌套在另一个命名空间中。另外，也没有跨命名空间的强制安全机制。

尽管如此，小心地使用命名空间，还是很有用的。

以人为中心的建议

从谈论较深奥的技术换到项目管理。Pousty 建议，在转移到原生云和微服务架构时，在你的团队中要有一个微服务操作人员。“如果你去做微服务，你的团队最终做的就是 Ops-y。并且，不去使用已经知道这种操作的人是愚蠢的行为”，他说。“你需要一个正确的团队核心能力。我不想开发人员重新打造运维的轮子”。

而是，将你的工作流彻底地改造成一个能够使用容器和云的过程，对此，Kubernetes 是很适用的。

使用 Kubernetes 的原生云计算：领导者的课程

• 迅速扩大的原生云生态系统。寻找可以扩展你使用容器的方法的工具。
• 探索鲜为人知的 Kubernetes 特性，如命名空间。它们可以改善你的组织和自动化程度。
• 确保部署到容器的开发团队有一个 Ops 人员参与。否则，冲突将不可避免。

作者简介：

Steven J. Vaughan-Nichols, Vaughan-Nichols & Associates 的 CEO

Steven J. Vaughan-Nichols，即 sjvn，是一个技术方面的作家，从 CP/M-80 还是前沿技术、PC 操作系统、300bps 是非常快的因特网连接、WordStar 是最先进的文字处理程序的那个时候开始，一直从事于商业技术的写作，而且喜欢它。他的作品已经发布在了从高科技出版物（IEEE Computer、ACM Network、 Byte）到商业出版物（eWEEK、 InformationWeek、ZDNet），从大众科技（Computer Shopper、PC Magazine、PC World）再到主流出版商（Washington Post、San Francisco Chronicle、BusinessWeek) 等媒体之上。

via: https://insights.hpe.com/articles/how-to-implement-cloud-native-computing-with-kubernetes-1710.html

作者：Steven J. Vaughan-Nichols 译者：qhwdw 校对：wxy

本文由 LCTT 原创编译，Linux中国 荣誉推出

没有时间运行命令？使用 cron 的计划任务意味着你不用熬夜程序也可以运行。

系统管理员（在许多好处中）的挑战之一是在你该睡觉的时候去运行一些任务。例如，一些任务（包括定期循环运行的任务）需要在没有人使用计算机资源的时候去运行，如午夜或周末。在下班后，我没有时间去运行命令或脚本。而且，我也不想在晚上去启动备份或重大更新。

取而代之的是，我使用两个服务功能在我预定的时间去运行命令、程序和任务。cron 和 at 服务允许系统管理员去安排任务运行在未来的某个特定时间。at 服务指定在某个时间去运行一次任务。cron 服务可以安排任务在一个周期上重复，比如天、周、或月。

在这篇文章中，我将介绍 cron 服务和怎么去使用它。

常见（和非常见）的 cron 用途

我使用 cron 服务去安排一些常见的事情，比如，每天凌晨 2:00 发生的定期备份，我也使用它去做一些不常见的事情。

• 许多电脑上的系统时钟（比如，操作系统时间）都设置为使用网络时间协议（NTP）。 NTP 设置系统时间后，它不会去设置硬件时钟，它可能会“漂移”。我使用 cron 基于系统时间去设置硬件时钟。
• 我还有一个 Bash 程序，我在每天早晨运行它，去在每台电脑上创建一个新的 “每日信息” （MOTD）。它包含的信息有当前的磁盘使用情况等有用的信息。
• 许多系统进程和服务，像 Logwatch、logrotate、和 Rootkit Hunter，使用 cron 服务去安排任务和每天运行程序。

crond 守护进程是一个完成 cron 功能的后台服务。

cron 服务检查在 /var/spool/cron 和 /etc/cron.d 目录中的文件，以及 /etc/anacrontab 文件。这些文件的内容定义了以不同的时间间隔运行的 cron 作业。个体用户的 cron 文件是位于 /var/spool/cron，而系统服务和应用生成的 cron 作业文件放在 /etc/cron.d 目录中。/etc/anacrontab 是一个特殊的情况，它将在本文中稍后部分介绍。

使用 crontab

cron 实用程序运行基于一个 cron 表（crontab）中指定的命令。每个用户，包括 root，都有一个 cron 文件。这些文件缺省是不存在的。但可以使用 crontab -e 命令创建在 /var/spool/cron 目录中，也可以使用该命令去编辑一个 cron 文件（看下面的脚本）。我强烈建议你，不要使用标准的编辑器（比如，Vi、Vim、Emacs、Nano、或者任何其它可用的编辑器）。使用 crontab 命令不仅允许你去编辑命令，也可以在你保存并退出编辑器时，重启动 crond 守护进程。crontab 命令使用 Vi 作为它的底层编辑器，因为 Vi 是预装的（至少在大多数的基本安装中是预装的）。

现在，cron 文件是空的，所以必须从头添加命令。 我增加下面示例中定义的作业到我的 cron 文件中，这是一个快速指南，以便我知道命令中的各个部分的意思是什么，你可以自由拷贝它，供你自己使用。

# crontab -e
SHELL=/bin/bash
[email protected]
PATH=/bin:/sbin:/usr/bin:/usr/sbin:/usr/local/bin:/usr/local/sbin

# For details see man 4 crontabs

# Example of job definition:
# .---------------- minute (0 - 59)
# |  .------------- hour (0 - 23)
# |  |  .---------- day of month (1 - 31)
# |  |  |  .------- month (1 - 12) OR jan,feb,mar,apr ...
# |  |  |  |  .---- day of week (0 - 6) (Sunday=0 or 7) OR sun,mon,tue,wed,thu,fri,sat
# |  |  |  |  |
# *  *  *  *  * user-name  command to be executed

# backup using the rsbu program to the internal 4TB HDD and then 4TB external
01 01 * * * /usr/local/bin/rsbu -vbd1 ; /usr/local/bin/rsbu -vbd2

# Set the hardware clock to keep it in sync with the more accurate system clock
03 05 * * * /sbin/hwclock --systohc

# Perform monthly updates on the first of the month
# 25 04 1 * * /usr/bin/dnf -y update

crontab 命令用于查看或编辑 cron 文件。

上面代码中的前三行设置了一个缺省环境。对于给定用户，环境变量必须是设置的，因为，cron 不提供任何方式的环境。SHELL 变量指定命令运行使用的 shell。这个示例中，指定为 Bash shell。MAILTO 变量设置发送 cron 作业结果的电子邮件地址。这些电子邮件提供了 cron 作业（备份、更新、等等）的状态，和你从命令行中手动运行程序时看到的结果是一样的。第三行为环境设置了 PATH 变量。但即使在这里设置了路径，我总是使用每个程序的完全限定路径。

在上面的示例中有几个注释行，它详细说明了定义一个 cron 作业所要求的语法。我将在下面分别讲解这些命令，然后，增加更多的 crontab 文件的高级特性。

01 01 * * * /usr/local/bin/rsbu -vbd1 ; /usr/local/bin/rsbu -vbd2

在我的 /etc/crontab 中的这一行运行一个脚本，用于为我的系统执行备份。

这一行运行我自己编写的 Bash shell 脚本 rsbu，它对我的系统做完全备份。这个作业每天的凌晨 1:01 (01 01) 运行。在这三、四、五位置上的星号（*），像文件通配符一样代表一个特定的时间，它们代表 “一个月中的每天”、“每个月” 和 “一周中的每天”，这一行会运行我的备份两次，一次备份内部专用的硬盘驱动器，另外一次运行是备份外部的 USB 驱动器，使用它这样我可以很保险。

接下来的行我设置了一个硬件时钟，它使用当前系统时钟作为源去设置硬件时钟。这一行设置为每天凌晨 5：03 分运行。

03 05 * * * /sbin/hwclock --systohc

这一行使用系统时间作为源来设置硬件时钟。

我使用的第三个也是最后一个的 cron 作业是去执行一个 dnf 或 yum 更新，它在每个月的第一天的凌晨 04:25 运行，但是，我注释掉了它，以后不再运行。

# 25 04 1 * * /usr/bin/dnf -y update

这一行用于执行一个每月更新，但是，我也把它注释掉了。

其它的定时任务技巧

现在，让我们去做一些比基本知识更有趣的事情。假设你希望在每周四下午 3:00 去运行一个特别的作业：

00 15 * * Thu /usr/local/bin/mycronjob.sh

这一行会在每周四下午 3:00 运行 mycronjob.sh 这个脚本。

或者，或许你需要在每个季度末去运行一个季度报告。cron 服务没有为 “每个月的最后一天” 设置选项，因此，替代方式是使用下一个月的第一天，像如下所示（这里假设当作业准备运行时，报告所需要的数据已经准备好了）。

02 03 1 1,4,7,10 * /usr/local/bin/reports.sh

在季度末的下一个月的第一天运行这个 cron 作业。

下面展示的这个作业，在每天的上午 9:01 到下午 5:01 之间，每小时运行一次。

01 09-17 * * * /usr/local/bin/hourlyreminder.sh

有时，你希望作业在业务期间定时运行。

我遇到一个情况，需要作业在每二、三或四小时去运行。它需要用期望的间隔去划分小时，比如， */3 为每三个小时，或者 6-18/3 为上午 6 点到下午 6 点每三个小时运行一次。其它的时间间隔的划分也是类似的。例如，在分钟位置的表达式 */15 意思是 “每 15 分钟运行一次作业”。

*/5 08-18/2 * * * /usr/local/bin/mycronjob.sh

这个 cron 作业在上午 8:00 到下午 18:59 之间，每五分钟运行一次作业。

需要注意的一件事情是：除法表达式的结果必须是余数为 0（即整除）。换句话说，在这个例子中，这个作业被设置为在上午 8 点到下午 6 点之间的偶数小时每 5 分钟运行一次（08:00、08:05、 08:10、 08:15……18:55 等等），而不运行在奇数小时。另外，这个作业不能运行在下午 7:00 到上午 7:59 之间。（LCTT 译注：此处本文表述有误，根据正确情况修改）

我相信，你可以根据这些例子想到许多其它的可能性。

限制访问 cron

普通用户使用 cron 访问可能会犯错误，例如，可能导致系统资源（比如内存和 CPU 时间）被耗尽。为避免这种可能的问题， 系统管理员可以通过创建一个 /etc/cron.allow 文件去限制用户访问，它包含了一个允许去创建 cron 作业的用户列表。（不管是否列在这个列表中，）不能阻止 root 用户使用 cron。

通过阻止非 root 用户创建他们自己的 cron 作业，那也许需要将非 root 用户的 cron 作业添加到 root 的 crontab 中， “但是，等等！” 你说，“不是以 root 去运行这些作业？” 不一定。在这篇文章中的第一个示例中，出现在注释中的用户名字段可以用于去指定一个运行作业的用户 ID。这可以防止特定的非 root 用户的作业以 root 身份去运行。下面的示例展示了一个作业定义，它以 “student” 用户去运行这个作业：

04 07 * * * student /usr/local/bin/mycronjob.sh

如果没有指定用户，这个作业将以 contab 文件的所有者用户去运行，在这个情况中是 root。

cron.d

目录 /etc/cron.d 中是一些应用程序，比如 SpamAssassin 和 sysstat 安装的 cron 文件。因为，这里没有 spamassassin 或者 sysstat 用户，这些程序需要一个位置去放置 cron 文件，因此，它们被放在 /etc/cron.d 中。

下面的 /etc/cron.d/sysstat 文件包含系统活动报告（SAR）相关的 cron 作业。这些 cron 文件和用户 cron 文件格式相同。

# Run system activity accounting tool every 10 minutes
*/10 * * * * root /usr/lib64/sa/sa1 1 1
# Generate a daily summary of process accounting at 23:53
53 23 * * * root /usr/lib64/sa/sa2 -A

sysstat 包安装了 /etc/cron.d/sysstat cron 文件来运行程序生成 SAR。

该 sysstat cron 文件有两行执行任务。第一行每十分钟去运行 sa1 程序去收集数据，存储在 /var/log/sa 目录中的一个指定的二进制文件中。然后，在每天晚上的 23:53， sa2 程序运行来创建一个每日汇总。

计划小贴士

我在 crontab 文件中设置的有些时间看上起似乎是随机的，在某种程度上说，确实是这样的。尝试去安排 cron 作业可能是件很具有挑战性的事， 尤其是作业的数量越来越多时。我通常在我的每个电脑上仅有一些任务，它比起我工作用的那些生产和实验环境中的电脑简单多了。

我管理的一个系统有 12 个每天晚上都运行 cron 作业，另外 3、4 个在周末或月初运行。那真是个挑战，因为，如果有太多作业在同一时间运行，尤其是备份和编译系统，会耗尽内存并且几乎填满交换文件空间，这会导致系统性能下降甚至是超负荷，最终什么事情都完不成。我增加了一些内存并改进了如何计划任务。我还删除了一些写的很糟糕、使用大量内存的任务。

crond 服务假设主机计算机 24 小时运行。那意味着如果在一个计划运行的期间关闭计算机，这些计划的任务将不再运行，直到它们计划的下一次运行时间。如果这里有关键的 cron 作业，这可能导致出现问题。 幸运的是，在定期运行的作业上，还有一个其它的选择： anacron。

anacron

anacron 程序执行和 cron 一样的功能，但是它增加了运行被跳过的作业的能力，比如，如果计算机已经关闭或者其它的原因导致无法在一个或多个周期中运行作业。它对笔记本电脑或其它被关闭或进行睡眠模式的电脑来说是非常有用的。

只要电脑一打开并引导成功，anacron 会检查过去是否有计划的作业被错过。如果有，这些作业将立即运行，但是，仅运行一次（而不管它错过了多少次循环运行）。例如，如果一个每周运行的作业在最近三周因为休假而系统关闭都没有运行，它将在你的电脑一启动就立即运行，但是，它仅运行一次，而不是三次。

anacron 程序提供了一些对周期性计划任务很好用的选项。它是安装在你的 /etc/cron.[hourly|daily|weekly|monthly] 目录下的脚本。 根据它们需要的频率去运行。

它是怎么工作的呢？接下来的这些要比前面的简单一些。

1、 crond 服务运行在 /etc/cron.d/0hourly 中指定的 cron 作业。

# Run the hourly jobs
SHELL=/bin/bash
PATH=/sbin:/bin:/usr/sbin:/usr/bin
MAILTO=root
01 * * * * root run-parts /etc/cron.hourly

/etc/cron.d/0hourly 中的内容使位于 /etc/cron.hourly 中的 shell 脚本运行。

2、 在 /etc/cron.d/0hourly 中指定的 cron 作业每小时运行一次 run-parts 程序。

3、 run-parts 程序运行所有的在 /etc/cron.hourly 目录中的脚本。

4、 /etc/cron.hourly 目录包含的 0anacron 脚本，它使用如下的 /etdc/anacrontab 配置文件去运行 anacron 程序。

# /etc/anacrontab: configuration file for anacron

# See anacron(8) and anacrontab(5) for details.

SHELL=/bin/sh
PATH=/sbin:/bin:/usr/sbin:/usr/bin
MAILTO=root
# the maximal random delay added to the base delay of the jobs
RANDOM_DELAY=45
# the jobs will be started during the following hours only
START_HOURS_RANGE=3-22

#period in days   delay in minutes   job-identifier   command
1       5       cron.daily              nice run-parts /etc/cron.daily
7       25      cron.weekly             nice run-parts /etc/cron.weekly
@monthly 45     cron.monthly            nice run-parts /etc/cron.monthly

/etc/anacrontab 文件中的内容在合适的时间运行在 cron.[daily|weekly|monthly] 目录中的可执行文件。

5、 anacron 程序每日运行一次位于 /etc/cron.daily 中的作业。它每周运行一次位于 /etc/cron.weekly 中的作业。以及每月运行一次 cron.monthly 中的作业。注意，在每一行指定的延迟时间，它可以帮助避免这些作业与其它 cron 作业重叠。

我在 /usr/local/bin 目录中放置它们，而不是在 cron.X 目录中放置完整的 Bash 程序，这会使我从命令行中运行它们更容易。然后，我在 cron 目录中增加一个符号连接，比如，/etc/cron.daily。

anacron 程序不是设计用于在指定时间运行程序的。而是，用于在一个指定的时间开始，以一定的时间间隔去运行程序，比如，从每天的凌晨 3:00（看上面脚本中的 START_HOURS_RANGE 行）、从周日（每周第一天）和这个月的第一天。如果任何一个或多个循环错过，anacron 将立即运行这个错过的作业。

更多的关于设置限制

我在我的计算机上使用了很多运行计划任务的方法。所有的这些任务都需要一个 root 权限去运行。在我的经验中，很少有普通用户去需要运行 cron 任务，一种情况是开发人员需要一个 cron 作业去启动一个开发实验室的每日编译。

限制非 root 用户去访问 cron 功能是非常重要的。然而，在一些特殊情况下，用户需要去设置一个任务在预先指定时间运行，而 cron 可以允许他们去那样做。许多用户不理解如何正确地配置 cron 去完成任务，并且他们会出错。这些错误可能是无害的，但是，往往不是这样的，它们可能导致问题。通过设置功能策略，使用户与管理员互相配合，可以使个别的 cron 作业尽可能地不干扰其它的用户和系统功能。

可以给为单个用户或组分配的资源设置限制，但是，这是下一篇文章中的内容。

更多信息，在 cron、crontab、anacron、anacrontab、和 run-parts 的 man 页面上，所有的这些信息都描述了 cron 系统是如何工作的。

作者简介：

David Both - 是一位 Linux 和开源软件的倡导者，居住在 Raleigh，North Carolina。他从事 IT 行业超过四十年，并且在 IBM 教授 OS/2 超过 20 年时间，他在 1981 年 IBM 期间，为最初的 IBM PC 写了第一部培训教程。他为 Red Hat 教授 RHCE 系列课程，并且他也为 MCI Worldcom、 Cisco、和 North Carolina 州工作。他使用 Linux 和开源软件工作差不多 20 年了。

via: https://opensource.com/article/17/11/how-use-cron-linux

作者：David Both 译者：qhwdw 校对：wxy

本文由 LCTT 原创编译，Linux中国 荣誉推出

过了这个夏天，我把我的桌面环境迁移到了 i3，这是一个瓦片式窗口管理器。当初，切换到 i3 是一个挑战，因为我必须去处理许多以前 GNOME 帮我处理的事情。其中一件事情就是改变屏幕亮度。 xbacklight 这个在笔记本电脑上改变背光亮度的标准方法，它在我的硬件上不工作了。

最近，我发现一个改变背光亮度的工具 brightlight。我决定去试一下它，它工作在 root 权限下。但是，我发现 brightligh 在 Fedora 下没有 RPM 包。我决定，是在 Fedora 下尝试创建一个包的时候了，并且可以学习怎么去创建一个 RPM 包。

在这篇文章中，我将分享以下的内容：

• 创建 RPM SPEC 文件
• 在 Koji 和 Copr　中构建包
• 使用调试包处理一个问题
• 提交这个包到 Fedora 包集合中

前提条件

在 Fedora 上，我安装了包构建过程中所有步骤涉及到的包。

sudo dnf install fedora-packager fedpkg fedrepo_req copr-cli

创建 RPM SPEC 文件

创建 RPM 包的第一步是去创建 SPEC 文件。这些规范，或者是指令，它告诉 RPM 怎么去构建包。这是告诉 RPM 从包的源代码中创建一个二进制文件。创建 SPEC 文件看上去是整个包处理过程中最难的一部分，并且它的难度取决于项目。

对我而言，幸运的是，brightlight 是一个用 C 写的简单应用程序。维护人员用一个 Makefile 使创建二进制应用程序变得很容易。构建它只是在仓库中简单运行 make 的问题。因此，我现在可以用一个简单的项目去学习 RPM 打包。

查找文档

谷歌搜索 “how to create an RPM package” 有很多结果。我开始使用的是 IBM 的文档。然而，我发现它理解起来非常困难，不知所云（虽然十分详细，它可能适用于复杂的 app）。我也在 Fedora 维基上找到了 创建包 的介绍。这个文档在构建和处理上解释的非常好，但是，我一直困惑于 “怎么去开始呢？”

最终，我找到了 RPM 打包指南，它是大神 Adam Miller 写的。这些介绍非常有帮助，并且包含了三个优秀的示例，它们分别是用 Bash、C 和 Python 编写的程序。这个指南帮我很容易地理解了怎么去构建一个 RPM SPEC，并且，更重要的是，解释了怎么把这些片断拼到一起。

有了这些之后，我可以去写 brightlight 程序的我的 第一个 SPEC 文件 了。因为它是很简单的，SPEC 很短也很容易理解。我有了 SPEC 文件之后，我发现其中有一些错误。处理掉一些错误之后，我创建了源 RPM (SRPM) 和二进制 RPM，然后，我解决了出现的每个问题。

rpmlint SPECS/brightlight.spec
rpmbuild -bs SPECS/brightlight.spec
rpmlint SRPMS/brightlight-5-1.fc26.src.rpm
rpmbuild -bb SPECS/brightlight-5-1.fc26.x86_64.rpm
rpmlint RPMS/x86_64/brightlight-5-1.fc26.x86_64.rpm

现在，我有了一个可用的 RPM，可以发送到 Fedora 仓库了。

在 Copr 和 Koji 中构建

接下来，我读了该 指南 中关于怎么成为一个 Fedora 打包者。在提交之前，他们鼓励打包者通过在在 Koji 中托管、并在 Copr 中构建项目来测试要提交的包。

使用 Copr

首先，我为 brightlight 创建了一个 Copr 仓库，Copr 是在 Fedora 的基础设施中的一个服务，它构建你的包，并且为你任意选择的 Fedora 或 EPEL 版本创建一个定制仓库。它对于快速托管你的 RPM 包，并与其它人去分享是非常方便的。你不需要特别操心如何去托管一个 Copr 仓库。

我从 Web 界面创建了我的 Copr 项目，但是，你也可以使用 copr-cli 工具。在 Fedora 开发者网站上有一个 非常优秀的指南。在该网站上创建了我的仓库之后，我使用这个命令构建了我的包。

copr-cli build brightlight SRPMS/brightlight.5-1.fc26.src.rpm

我的包在 Corp 上成功构建，并且，我可以很容易地在我的 Fedora 系统上成功安装它。

使用 Koji

任何人都可以使用 Koji 在多种架构和 Fedora 或 CentOS/RHEL 版本上测试他们的包。在 Koji 中测试，你必须有一个源 RPM。我希望 brightlight 包在 Fedora 所有的版本中都支持，因此，我运行如下的命令：

koji build --scratch f25 SRPMS/brightlight-5-1.fc26.src.rpm
koji build --scratch f26 SRPMS/brightlight-5-1.fc26.src.rpm
koji build --scratch f27 SRPMS/brightlight-5-1.fc26.src.rpm

它花费了一些时间，但是，Koji 构建了所有的包。我的包可以很完美地运行在 Fedora 25 和 26 中，但是 Fedora 27 失败了。 Koji 模拟构建可以使我走在正确的路线上，并且确保我的包构建成功。

问题：Fedora 27 构建失败！

现在，我已经知道我的 Fedora 27 上的包在 Koji 上构建失败了。但是，为什么呢？我发现在 Fedora 27 上有两个相关的变化。

• Subpackage and Source Debuginfo
• RPM 4.14 (特别是，debuginfo 包重写了)

这些变化意味着 RPM 包必须使用一个 debuginfo 包去构建。这有助于排错或调试一个应用程序。在我的案例中，这并不是关键的或者很必要的，但是，我需要去构建一个。

感谢 Igor Gnatenko，他帮我理解了为什么我在 Fedora 27 上构建包时需要去将这些增加到我的包的 SPEC 中。在 %make_build 宏指令之前，我增加了这些行。

export CFLAGS="%{optflags}"
export LDFLAGS="%{__global_ldflags}"

我构建了一个新的 SRPM 并且提交它到 Koji 去在 Fedora 27 上构建。成功了，它构建成功了！

提交这个包

现在，我在 Fedora 25 到 27 上成功校验了我的包，是时候为 Fedora 打包了。第一步是提交这个包，为了请求一个包评估，要在 Red Hat Bugzilla 创建一个新 bug。我为 brightlight 创建了一个工单。因为这是我的第一个包，我明确标注它 “这是我的第一个包”，并且我寻找一个发起人。在工单中，我链接 SPEC 和 SRPM 文件到我的 Git 仓库中。

进入 dist-git

Igor Gnatenko 发起我进入 Fedora 打包者群组，并且在我的包上留下反馈。我学习了一些其它的关于 C 应用程序打包的特定的知识。在他响应我之后，我可以在 dist-git 上申请一个仓库，Fedora 的 RPM 包集合仓库为所有的 Fedora 版本保存了 SPEC 文件。

一个很方便的 Python 工具使得这一部分很容易。fedrepo-req 是一个用于创建一个新的 dist-git 仓库的请求的工具。我用这个命令提交我的请求。

fedrepo-req brightlight \
    --ticket 1505026 \
    --description "CLI tool to change screen back light brightness" \
    --upstreamurl https://github.com/multiplexd/brightlight

它为我在 fedora-scm-requests 仓库创建了一个新的工单。这是一个我是管理员的 创建的仓库。现在，我可以开始干了！

My first RPM in Fedora dist-git – woohoo!

与 dist-git 一起工作

接下来，fedpkg 是用于和 dist-git 仓库进行交互的工具。我改变当前目录到我的 git 工作目录，然后运行这个命令。

fedpkg clone brightlight

fedpkg 从 dist-git 克隆了我的包的仓库。对于这个仅有的第一个分支，你需要去导入 SRPM。

fedpkg import SRPMS/brightlight-5-1.fc26.src.rpm

fedpkg 导入你的包的 SRPM 到这个仓库中，然后设置源为你的 Git 仓库。这一步对于使用 fedpkg 是很重要的，因为它用一个 Fedora 友好的方去帮助规范这个仓库（与手动添加文件相比）。一旦你导入了 SRPM，推送这个改变到 dist-git 仓库。

git commit -m "Initial import (#1505026)."
git push

构建包

自从你推送第一个包导入到你的 dist-git 仓库中，你已经准备好了为你的项目做一次真实的 Koji 构建。要构建你的项目，运行这个命令。

fedpkg build

它会在 Koji 中为 Rawhide 构建你的包，这是 Fedora 中的非版本控制的分支。在你为其它分支构建之前，你必须在 Rawhide 分支上构建成功。如果一切构建成功，你现在可以为你的项目的其它分支发送请求了。

fedrepo-req brightlight f27 -t 1505026
fedrepo-req brightlight f26 -t 1505026
fedrepo-req brightlight f25 -t 1505026

关于构建其它分支的注意事项

一旦你最初导入了 SRPM，如果你选择去创建其它分支，记得合并你的主分支到它们。例如，如果你后面为 Fedora 27 请求一个分支，你将需要去使用这些命令。

fedpkg switch-branch f27
git merge master
git push
fedpkg build

提交更新到 Bodhi

这个过程的最后一步是，把你的新包作为一个更新包提交到 Bodhi 中。当你初次提交你的更新包时，它将去测试这个仓库。任何人都可以测试你的包并且增加 karma 到该更新中。如果你的更新接收了 3 个以上的投票（或者像 Bodhi 称它为 karma），你的包将自动被推送到稳定仓库。否则，一周之后，推送到测试仓库中。

要提交你的更新到 Bodhi，你仅需要一个命令。

fedpkg update

它为你的包用一个不同的配置选项打开一个 Vim 窗口。一般情况下，你仅需要去指定一个 类型（比如，newpackage）和一个你的包评估的票据 ID。对于更深入的讲解，在 Fedora 维基上有一篇更新的指南。

在保存和退出这个文件后，fedpkg 会把你的包以一个更新包提交到 Bodhi，最后，同步到 Fedora 测试仓库。我也可以用这个命令去安装我的包。

sudo dnf install brightlight -y --enablerepo=updates-testing --refresh

稳定仓库

最近提交了我的包到 Fedora 26 稳定仓库，并且不久将进入 Fedora 25 和 Fedora 27 稳定仓库。感谢帮助我完成我的第一个包的每个人。我期待有更多的机会为发行版添加包。

via: https://blog.justinwflory.com/2017/11/first-rpm-package-fedora/

作者：JUSTIN W. FLORY 译者：qhwdw 校对：wxy

本文由 LCTT 原创编译，Linux中国 荣誉推出

由于我刚刚提交了最后一个改进 PostgreSQL 11 哈希索引的补丁，并且大部分哈希索引的改进都致力于预计下周发布的 PostgreSQL 10（LCTT 译注：已发布），因此现在似乎是对过去 18 个月左右所做的工作进行简要回顾的好时机。在版本 10 之前，哈希索引在并发性能方面表现不佳，缺少预写日志记录，因此在宕机或复制时都是不安全的，并且还有其他二等公民。在 PostgreSQL 10 中，这在很大程度上被修复了。

虽然我参与了一些设计，但改进哈希索引的首要功劳来自我的同事 Amit Kapila，他在这个话题下的博客值得一读。哈希索引的问题不仅在于没有人打算写预写日志记录的代码，还在于代码没有以某种方式进行结构化，使其可以添加实际上正常工作的预写日志记录。要拆分一个桶，系统将锁定已有的桶（使用一种十分低效的锁定机制），将半个元组移动到新的桶中，压缩已有的桶，然后松开锁。即使记录了个别更改，在错误的时刻发生崩溃也会使索引处于损坏状态。因此，Aimt 首先做的是重新设计锁定机制。新的机制在某种程度上允许扫描和拆分并行进行，并且允许稍后完成那些因报错或崩溃而被中断的拆分。完成了一系列漏洞的修复和一些重构工作，Aimt 就打了另一个补丁，添加了支持哈希索引的预写日志记录。

与此同时，我们发现哈希索引已经错过了许多已应用于 B 树索引多年的相当明显的性能改进。因为哈希索引不支持预写日志记录，以及旧的锁定机制十分笨重，所以没有太多的动机去提升其他的性能。而这意味着如果哈希索引会成为一个非常有用的技术，那么需要做的事只是添加预写日志记录而已。PostgreSQL 索引存取方法的抽象层允许索引保留有关其信息的后端专用缓存，避免了重复查询索引本身来获取相关的元数据。B 树和 SQLite 的索引正在使用这种机制，但哈希索引没有，所以我的同事 Mithun Cy 写了一个补丁来使用此机制缓存哈希索引的元页。同样，B 树索引有一个称为“单页回收”的优化，它巧妙地从索引页移除没用的索引指针，从而防止了大量索引膨胀。我的同事 Ashutosh Sharma 打了一个补丁将这个逻辑移植到哈希索引上，也大大减少了索引的膨胀。最后，B 树索引自 2006 年以来就有了一个功能，可以避免重复锁定和解锁同一个索引页——所有元组都在页中一次性删除，然后一次返回一个。Ashutosh Sharma 也将此逻辑移植到了哈希索引中，但是由于缺少时间，这个优化没有在版本 10 中完成。在这个博客提到的所有内容中，这是唯一一个直到版本 11 才会出现的改进。

关于哈希索引的工作有一个更有趣的地方是，很难确定行为是否真的正确。锁定行为的更改只可能在繁重的并发状态下失败，而预写日志记录中的错误可能仅在崩溃恢复的情况下显示出来。除此之外，在每种情况下，问题可能是微妙的。没有东西崩溃还不够；它们还必须在所有情况下产生正确的答案，并且这似乎很难去验证。为了协助这项工作，我的同事 Kuntal Ghosh 先后跟进了最初由 Heikki Linnakangas 和 Michael Paquier 开始的工作，并且制作了一个 WAL 一致性检查器，它不仅可以作为开发人员测试的专用补丁，还能真正提交到 PostgreSQL。在提交之前，我们对哈希索引的预写日志代码使用此工具进行了广泛的测试，并十分成功地查找到了一些漏洞。这个工具并不仅限于哈希索引，相反：它也可用于其他模块的预写日志记录代码，包括堆，当今的所有 AM 索引，以及一些以后开发的其他东西。事实上，它已经成功地在 BRIN 中找到了一个漏洞。

虽然 WAL 一致性检查是主要的开发者工具——尽管它也适合用户使用，如果怀疑有错误——也可以升级到专为数据库管理人员提供的几种工具。Jesper Pedersen 写了一个补丁来升级 pageinspect contrib 模块来支持哈希索引，Ashutosh Sharma 做了进一步的工作，Peter Eisentraut 提供了测试用例（这是一个很好的办法，因为这些测试用例迅速失败，引发了几轮漏洞修复）。多亏了 Ashutosh Sharma 的工作，pgstattuple contrib 模块也支持哈希索引了。

一路走来，也有一些其他性能的改进。我一开始没有意识到的是，当一个哈希索引开始新一轮的桶拆分时，磁盘上的大小会突然加倍，这对于 1MB 的索引来说并不是一个问题，但是如果你碰巧有一个 64GB 的索引，那就有些不幸了。Mithun Cy 通过编写一个补丁，把加倍过程分为四个阶段在某个程度上解决了这一问题，这意味着我们将从 64GB 到 80GB 到 96GB 到 112GB 到 128GB，而不是一次性从 64GB 到 128GB。这个问题可以进一步改进，但需要对磁盘格式进行更深入的重构，并且需要仔细考虑对查找性能的影响。

七月时，一份来自于“AP”测试人员的报告使我们感到需要做进一步的调整。AP 发现，若试图将 20 亿行数据插入到新创建的哈希索引中会导致错误。为了解决这个问题，Amit 修改了拆分桶的代码，使得在每次拆分之后清理旧的桶，大大减少了溢出页的累积。为了得以确保，Aimt 和我也增加了四倍的位图页的最大数量，用于跟踪溢出页分配。

虽然还是有更多的事情要做，但我觉得，我和我的同事们——以及在 PostgreSQL 团队中的其他人的帮助下——已经完成了我们的目标，使哈希索引成为一个一流的功能，而不是被严重忽视的半成品。不过，你或许会问，这个功能可能有哪些应用场景。我在文章开头提到的（以及链接中的）Amit 的博客内容表明，即使是 pgbench 的工作负载，哈希索引页也可能在低级和高级并发方面优于 B 树。然而，从某种意义上说，这确实是最坏的情况。哈希索引的卖点之一是，索引存储的是字段的哈希值，而不是原始值——所以，我希望像 UUID 或者长字符串的宽键将有更大的改进。它们可能会在读取繁重的工作负载时做得更好。我们没有像优化读取那种程度来优化写入，但我鼓励任何对此技术感兴趣的人去尝试并将结果发到邮件列表（或发私人电子邮件），因为对于开发一个功能而言，真正关键的并不是一些开发人员去思考在实验室中会发生什么，而是在实际中发生了什么。

最后，我要感谢 Jeff Janes 和 Jesper Pedersen 为这个项目及其相关所做的宝贵的测试工作。这样一个规模适当的项目并不易得，以及有一群坚持不懈的测试人员，他们勇于打破任何废旧的东西的决心起了莫大的帮助。除了以上提到的人之外，其他人同样在测试，审查以及各种各样的日常帮助方面值得赞扬，其中包括 Andreas Seltenreich，Dilip Kumar，Tushar Ahuja，Alvaro Herrera，Micheal Paquier，Mark Kirkwood，Tom Lane，Kyotaro Horiguchi。谢谢你们，也同样感谢那些本该被提及却被我无意中忽略的所有朋友。

via：https://rhaas.blogspot.jp/2017/09/postgresqls-hash-indexes-are-now-cool.html

作者：Robert Haas 译者：polebug 校对：wxy

本文由[LCTT]（[https://github.com/LCTT/TranslateProject）原创编译，[Linux中国]（https://linux.cn/）荣誉推出](https://github.com/LCTT/TranslateProject%EF%BC%89%E5%8E%9F%E5%88%9B%E7%BC%96%E8%AF%91%EF%BC%8C%5BLinux%E4%B8%AD%E5%9B%BD%5D%EF%BC%88https://linux.cn/%EF%BC%89%E8%8D%A3%E8%AA%89%E6%8E%A8%E5%87%BA)

在这一系列的文章中，我们将来看下 mlocate，来看看如何快速、轻松地满足你的需求。

对于一个系统管理员来说，草中寻针一样的查找文件的事情并不少见。在一台拥挤的机器上，文件系统中可能存在数十万个文件。当你需要确定一个特定的配置文件是最新的，但是你不记得它在哪里时怎么办？

如果你使用过一些类 Unix 机器，那么你肯定用过 find 命令。毫无疑问，它是非常复杂和功能强大的。以下是一个只搜索目录中的符号链接，而忽略文件的例子：

# find . -lname "*"

你可以用 find 命令做几乎无尽的事情，这是不容否认的。find 命令好用的时候是很好且简洁的，但是它也可以很复杂。这不一定是因为 find 命令本身的原因，而是它与 xargs 结合，你可以传递各种选项来调整你的输出，并删除你找到的那些文件。

位置、位置，让人沮丧

然而，通常情况下简单是最好的选择，特别是当一个脾气暴躁的老板搭着你的肩膀，闲聊着时间的重要性时。你还在模糊地猜测这个你从来没有见过的文件的路径，而你的老板却肯定它在拥挤的 /var 分区的某处。

进一步看下 mlocate。你也许注意过它的一个近亲：slocate，它安全地（注意前缀字母 s 代表安全）记录了相关的文件权限，以防止非特权用户看到特权文件。此外，还有它们所起源的一个更老的，原始 locate 命令。

mlocate 与其家族的其他成员（至少包括 slocate）的不同之处在于，在扫描文件系统时，mlocate 不需要持续重新扫描所有的文件系统。相反，它将其发现的文件（注意前面的 m 代表合并）与现有的文件列表合并在一起，使其可以借助系统缓存从而性能更高、更轻量级。

在本系列文章中，我们将更仔细地了解 mlocate （由于其流行，所以也简称其为 locate），并研究如何快速轻松地将其调整到你心中所想的方式。

小巧和 紧凑

除非你经常重复使用复杂的命令，否则就会像我一样，最终会忘记它们而需要在用的时候寻找它们。locate 命令的优点是可以快速查询整个文件系统，而不用担心你处于顶层目录、根目录和所在路径，只需要简单地使用 locate 命令。

以前你可能已经发现 find 命令非常不听话，让你经常抓耳挠腮。你知道，丢失了一个分号或一个没有正确转义的特殊的字符就会这样。现在让我们离开这个复杂的 find 命令，放松一下，看一下这个聪明的小命令。

你可能需要首先通过运行以下命令来检查它是否在你的系统上：

对于 Red Hat 家族：

# yum install mlocate

对于 Debian 家族：

# apt-get install mlocate

发行版之间不应该有任何区别，但版本之间几乎肯定有细微差别。小心。

接下来，我们将介绍 locate 命令的一个关键组件，名为 updatedb。正如你可能猜到的那样，这是更新 locate 命令的数据库的命令。这名字非常符合直觉。

这个数据库是我之前提到的 locate 命令的文件列表。该列表被保存在一个相对简单而高效的数据库中。updatedb 通过 cron 任务定期运行，通常在一天中的安静时间运行。在下面的清单 1 中，我们可以看到文件 /etc/cron.daily/mlocate.cron 的内部（该文件的路径及其内容可能因发行版不同）。

#!/bin/sh

nodevs=$(< /proc/filesystems awk '$1 == "nodev" { print $2 }')

renice +19 -p $$ >/dev/null 2>&1

ionice -c2 -n7 -p $$ >/dev/null 2>&1

/usr/bin/updatedb -f "$nodevs"

清单 1： 每天如何触发 “updatedb” 命令。

如你所见，mlocate.cron 脚本使用了优秀的 nice 命令来尽可能少地影响系统性能。我还没有明确指出这个命令每天都在设定的时间运行（但如果我没有记错的话，原始的 locate 命令与你在午夜时的计算机减速有关）。这是因为，在一些 “cron” 版本上，延迟现在被引入到隔夜开始时间。

这可能是因为所谓的 “ 河马之惊群 Thundering Herd of Hippos ”问题。想象许多计算机（或饥饿的动物）同时醒来从单一或有限的来源要求资源（或食物）。当所有的“河马”都使用 NTP 设置它们的手表时，这可能会发生（好吧，这个寓言扯多了，但请忍受一下）。想象一下，正好每五分钟（就像一个 “cron 任务”），它们都要求获得食物或其他东西。

如果你不相信我，请看下配置文件 - 清单 2 中名为 anacron 的 cron 版本，这是文件 /etc/anacrontab 的内容。

# /etc/anacrontab: configuration file for anacron

# See anacron(8) and anacrontab(5) for details.

SHELL=/bin/sh

PATH=/sbin:/bin:/usr/sbin:/usr/bin

MAILTO=root

# the maximal random delay added to the base delay of the jobs

RANDOM_DELAY=45

# the jobs will be started during the following hours only

START_HOURS_RANGE=3-22

#period in days   delay in minutes   job-identifier   command

1       5       cron.daily              nice run-parts /etc/cron.daily

7       25      cron.weekly             nice run-parts /etc/cron.weekly

@monthly 45     cron.monthly            nice run-parts /etc/cron.monthly 

清单 2： 运行 “cron” 任务时延迟是怎样被带入的。

从清单 2 可以看到 RANDOM_DELAY 和 “delay in minutes” 列。如果你不熟悉 cron 这个方面，那么你可以在这找到更多的东西：

# man anacrontab

否则，如果你愿意，你可以自己延迟一下。有个很棒的网页（现在已有十多年的历史）以非常合理的方式讨论了这个问题。本网站讨论如何使用 sleep 来引入一个随机性，如清单 3 所示。

#!/bin/sh

# Grab a random value between 0-240.
value=$RANDOM
while [ $value -gt 240 ] ; do
 value=$RANDOM
done

# Sleep for that time.
sleep $value

# Syncronize.
/usr/bin/rsync -aqzC --delete --delete-after masterhost::master /some/dir/

清单 3：在触发事件之前引入随机延迟的 shell 脚本，以避免河马之惊群。

在提到这些（可能令人惊讶的）延迟时，是指 /etc/crontab 或 root 用户自己的 crontab 文件。如果你想改变 locate 命令运行的时间，特别是由于磁盘访问速度减慢时，那么它不是太棘手。实现它可能会有更优雅的方式，但是你也可以把文件 /etc/cron.daily/mlocate.cron 移到别的地方（我使用 /usr/local/etc 目录），使用 root 用户添加一条记录到 root 用户的 crontab，粘贴以下内容：

# crontab -e

33 3 * * * /usr/local/etc/mlocate.cron

使用 anacron，而不是通过 /var/log/cron 以及它的旧的、轮转的版本，你可以快速地告诉它上次 cron.daily 任务被触发的时间：

# ls -hal /var/spool/anacron

下一次，我们会看更多的使用 locate、updatedb 和其他工具来查找文件的方法。

via: https://www.linux.com/blog/learn/intro-to-linux/2017/11/finding-files-mlocate

作者：CHRIS BINNIE 译者：geekpi 校对：wxy

本文由 LCTT 原创编译，Linux中国 荣誉推出