标签 故障 下的文章

一项新研究发现，人为失误是引发停机时间的首要原因。你想象一下那是什么场景。

之前有一个很老的笑话：“是人都会犯错，但是要真正把事情搞砸，你还缺台计算机。” 现在情况正好相反了，现如今，数据中心设备的可靠性已经得到了极大的提升，反而是使用设备的人员素质没能跟上，从而给计算机正常运行带来了很大的威胁。

正常运行时间协会 Uptime Institute 对数千名 IT 专业人员一整年发生的故障事件进行了调查，得出结论表示绝大多数的数据中心故障是由于人为错误造成的，人为错误导致的故障率为 70%-75%。

而且有些故障很严重。调查发现，超过 30% 的 IT 服务与数据中心运营商经历了他们称之为是“严重服务退化”的停机事故。2019 年有 10% 的受访者称他们最近的事故造成的损失超过 100 万美元。

在正常运行时间协会在 2019 年 4 月的调查中，60% 的受访者认为，对于最近发生的重大停机事件，他们本可以通过更好的管理/流程或配置进行防止。而对于损失超过 100 万美元的故障事件，这一数字跃升至 74%。

正常运行时间协会认为，导致故障事件发生的最终的错误不一定是员工，而是令人失望的管理。

“这个行业仍然严重依赖于人工去完成一些最基础和最重要的工作，易受人为错误的影响，这一点无法避免，也许可做的防错/防灾措施很有限。”正常运行时间协会期刊的主编 Kevin Heslin 在一篇博客文章中写道。

“然而，对这些故障问题的快速调查发现，故障持续存在的主要原因不是人为失误，而是由于管理失误导致，如针对员工培训投资不足，相关政策执行不力，管理程序老旧，低估一名合格员工的重要性，这一系列的管理问题导致了故障停机。” Heslin 继续写道。

正常运行时间协会指出，公司的 IT 基础设施越复杂，特别是分布式特性基础设施，可能会越容易增加简单的错误层出不穷而导致业务中断的风险。同时指出公司需要意识到基础设施越复杂所涉及的风险就越大。

并警告说，在人员配备方面，不要以超过公司吸引和应用资源来管理基础设施的速度扩大关键 IT 能力，并在影响关键任务操作之前意识到任何人员和技能短缺。

via: https://www.networkworld.com/article/3444762/the-biggest-risk-to-uptime-your-staff.html

作者：Andy Patrizio 选题：lujun9972 译者：sthwhl 校对：wxy

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

我通常会严格保持此博客的技术性，将观察、意见等内容保持在最低限度。但是，这篇和接下来的几篇文章将介绍刚进入系统管理/SRE/系统工程师/sysops/devops-ops（无论你想称自己是什么）角色的常见的基础知识。

请跟我来！

“我的网站很慢！”

我只是随机选择了本文的问题类型，这也可以应用于任何与系统管理员相关的故障排除。我并不是要炫耀那些可以发现最多的信息的最聪明的“金句”。它也不是一个详尽的、一步步指导的、并在最后一个方框中导向“利润”一词的“流程图”。

我会通过一些例子展示常规的方法。

示例场景仅用于说明本文目的。它们有时会做一些不适用于所有情况的假设，而且肯定会有很多读者在某些时候说“哦，但我觉得你会发现……”。

但那可能会让我们错失重点。

十多年来，我一直在从事于支持工作，或在支持机构工作，有一件事让我一次又一次地感到震惊，这促使我写下了这篇文章。

有许多技术人员在遇到问题时的本能反应，就是不管三七二十一去尝试可能的解决方案。

“我的网站很慢，所以”，

  • 我将尝试增大 MaxClients/MaxRequestWorkers/worker_connections
  • 我将尝试提升 innodb_buffer_pool_size/effective_cache_size
  • 我打算尝试启用 mod_gzip（遗憾的是，这是真实的故事）

“我曾经看过这个问题，它是因为某种原因造成的 —— 所以我估计还是这个原因，它应该能解决这个问题。”

这浪费了很多时间，并会让你在黑暗中盲目乱撞，胡乱鼓捣。

你的 InnoDB 的缓冲池也许达到 100％ 的利用率，但这可能只是因为有人运行了一段时间的一次性大型报告导致的。如果没有排除这种情况，那你就是在浪费时间。

开始之前

在这里，我应该说明一下，虽然这些建议同样适用于许多角色，但我是从一般的支持系统管理员的角度来撰写的。在一个成熟的内部组织中，或与规模较大的、规范管理的或“企业级”客户合作时，你通常会对一切都进行检测、测量、绘制、整理（甚至不是文字），并发出警报。那么你的方法也往往会有所不同。让我们在这里先忽略这种情况。

如果你没有这种东西，那就随意了。

澄清问题

首先确定实际上是什么问题。“慢”可以是多种形式的。是收到第一个字节的时间吗？从糟糕的 Javascript 加载和每页加载要拉取 15 MB 的静态内容，这是一个完全不同类型的问题。是慢，还是比通常慢？这是两个非常不同的解决方案！

在你着手做某事之前，确保你知道实际报告和遇到的问题。找到问题的根源通常很困难，但即便找不到也必须找到问题本身。

否则，这相当于系统管理员带着一把刀去参加枪战。

唾手可得

首次登录可疑服务器时，你可以查找一些常见的嫌疑对象。事实上，你应该这样做！每当我登录到服务器时，我都会发出一些命令来快速检查一些事情：我们是否发生了页交换（free / vmstat），磁盘是否繁忙（top / iostat / iotop），是否有丢包（netstat / proc/net/dev），是否处于连接数过多的状态（netstat），有什么东西占用了 CPU（top），谁在这个服务器上（w / who），syslog 和 dmesg 中是否有引人注目的消息？

如果你从 RAID 控制器得到 2000 条抱怨直写式缓存没有生效的消息，那么继续进行是没有意义的。

这用不了半分钟。如果什么都没有引起你的注意 —— 那么继续。

重现问题

如果某处确实存在问题，并且找不到唾手可得的信息。

那么采取所有步骤来尝试重现问题。当你可以重现该问题时，你就可以观察它。当你能观察到时，你就可以解决。如果在第一步中尚未显现出或覆盖了问题所在，询问报告问题的人需要采取哪些确切步骤来重现问题。

对于由太阳耀斑或只能运行在 OS/2 上的客户端引起的问题，重现并不总是可行的。但你的第一个停靠港应该是至少尝试一下！在一开始，你所知道的是“某人认为他们的网站很慢”。对于那些人，他们可能还在用他们的 GPRS 手机，也可能正在安装 Windows 更新。你在这里挖掘得再深也是浪费时间。

尝试重现！

检查日志

我对于有必要包括这一点感到很难过。但是我曾经看到有人在运行 tail /var/log/... 之后几分钟就不看了。大多数 *NIX 工具都特别喜欢记录日志。任何明显的错误都会在大多数应用程序日志中显得非常突出。检查一下。

缩小范围

如果没有明显的问题，但你可以重现所报告的问题，那也很棒。所以，你现在知道网站是慢的。现在你已经把范围缩小到：浏览器的渲染/错误、应用程序代码、DNS 基础设施、路由器、防火墙、网卡（所有的）、以太网电缆、负载均衡器、数据库、缓存层、会话存储、Web 服务器软件、应用程序服务器、内存、CPU、RAID 卡、磁盘等等。

根据设置添加一些其他可能的罪魁祸首。它们也可能是 SAN，也不要忘记硬件 WAF！以及…… 你明白我的意思。

如果问题是接收到第一个字节的时间，你当然会开始对 Web 服务器去应用上已知的修复程序，就是它响应缓慢，你也觉得几乎就是它，对吧？但是你错了！

你要回去尝试重现这个问题。只是这一次，你要试图消除尽可能多的潜在问题来源。

你可以非常轻松地消除绝大多数可能的罪魁祸首：你能从服务器本地重现问题吗？恭喜，你刚刚节省了自己必须尝试修复 BGP 路由的时间。

如果不能，请尝试使用同一网络上的其他计算机。如果可以的话，至少你可以将防火墙移到你的嫌疑人名单上，（但是要注意一下那个交换机！）

是所有的连接都很慢吗？虽然服务器是 Web 服务器，但并不意味着你不应该尝试使用其他类型的服务进行重现问题。netcat 在这些场景中非常有用（但是你的 SSH 连接可能会一直有延迟，这可以作为线索）！ 如果这也很慢，你至少知道你很可能遇到了网络问题，可以忽略掉整个 Web 软件及其所有组件的问题。用这个知识（我不收 200 美元）再次从顶部开始，按你的方式由内到外地进行！

即使你可以在本地复现 —— 仍然有很多“因素”留下。让我们排除一些变量。你能用普通文件重现它吗？ 如果 i_am_a_1kb_file.html 很慢，你就知道它不是数据库、缓存层或 OS 以外的任何东西和 Web 服务器本身的问题。

你能用一个需要解释或执行的 hello_world.(py|php|js|rb..) 文件重现问题吗？如果可以的话，你已经大大缩小了范围，你可以专注于少数事情。如果 hello_world 可以马上工作，你仍然学到了很多东西！你知道了没有任何明显的资源限制、任何满的队列或在任何地方卡住的 IPC 调用，所以这是应用程序正在做的事情或它正在与之通信的事情。

所有页面都慢吗？或者只是从第三方加载“实时分数数据”的页面慢？

这可以归结为：你仍然可以重现这个问题所涉及的最少量的“因素”是什么？

我们的示例是一个缓慢的网站，但这同样适用于几乎所有问题。邮件投递？你能在本地投递吗？能发给自己吗？能发给<常见的服务提供者>吗？使用小的、纯文本的消息进行测试。尝试直到遇到 2MB 拥堵时。使用 STARTTLS 和不使用 STARTTLS 呢？按你的方式由内到外地进行！

这些步骤中的每一步都只需要几秒钟，远远快于实施大多数“可能的”修复方案。

隔离观察

到目前为止，当你去除特定组件时无法重现问题时，你可能已经偶然发现了问题所在。

但如果你还没有，或者你仍然不知道为什么：一旦你找到了一种方法来重现问题，你和问题之间的“东西”（某个技术术语）最少，那么就该开始隔离和观察了。

请记住，许多服务可以在前台运行和/或启用调试。对于某些类别的问题，执行此操作通常非常有帮助。

这也是你的传统武器库发挥作用的地方。strace、lsof、netstat、GDB、iotop、valgrind、语言分析器（cProfile、xdebug、ruby-prof ……）那些类型的工具。

一旦你走到这一步，你就很少能摆脱剖析器或调试器了。

strace 通常是一个非常好的起点。

你可能会注意到应用程序停留在某个连接到端口 3306 的套接字文件描述符上的特定 read() 调用上。你会知道该怎么做。

转到 MySQL 并再次从顶部开始。显而易见：“等待某某锁”、死锁、max_connections ……进而：是所有查询？还是只写请求？只有某些表？还是只有某些存储引擎？等等……

你可能会注意到调用外部 API 资源的 connect() 需要五秒钟才能完成，甚至超时。你会知道该怎么做。

你可能会注意到，在同一对文件中有 1000 个调用 fstat() 和 open() 作为循环依赖的一部分。你会知道该怎么做。

它可能不是那些特别的东西，但我保证，你会发现一些东西。

如果你只是从这一部分学到一点，那也不错；学习使用 strace 吧！真的学习它，阅读整个手册页。甚至不要跳过历史部分。man 每个你还不知道它做了什么的系统调用。98％ 的故障排除会话以 strace 而终结。

via: http://northernmost.org/blog/troubleshooting-101/index.html

作者：Erik Ljungstrom 译者：wxy 校对：wxy

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

在严重的故障发生之前，找到引起问题的异常事件，并修复它。

黑天鹅 Black swan 用来比喻造成严重影响的小概率事件（比如 2008 年的金融危机）。在生产环境的系统中，黑天鹅是指这样的事情：它引发了你不知道的问题，造成了重大影响，不能快速修复或回滚，也不能用值班说明书上的其他标准响应来解决。它是事发几年后你还在给新人说起的事件。

从定义上看，黑天鹅是不可预测的，不过有时候我们能找到其中的一些模式，针对有关联的某一类问题准备防御措施。

例如，大部分故障的直接原因是变更（代码、环境或配置）。虽然这种方式触发的 bug 是独特的、不可预测的，但是常见的金丝雀发布对避免这类问题有一定的作用，而且自动回滚已经成了一种标准止损策略。

随着我们的专业性不断成熟，一些其他的问题也正逐渐变得容易理解，被归类到某种风险并有普适的预防策略。

公布出来的黑天鹅事件

所有科技公司都有生产环境的故障，只不过并不是所有公司都会分享他们的事故分析。那些公开讨论事故的公司帮了我们的忙。下列事故都描述了某一类问题，但它们绝对不是只一个孤例。我们的系统中都有黑天鹅在潜伏着，只是有些人还不知道而已。

达到上限

达到任何类型的限制都会引发严重事故。这类问题的一个典型例子是 2017 年 2 月 Instapaper 的一次服务中断。我把这份事故报告给任何一个运维工作者看，他们读完都会脊背发凉。Instapaper 生产环境的数据库所在的文件系统有 2 TB 的大小限制，但是数据库服务团队并不知情。在没有任何报错的情况下，数据库不再接受任何写入了。完全恢复需要好几天，而且还得迁移数据库。

资源限制有各式各样的触发场景。Sentry 遇到了 Postgres 的最大事务 ID 限制。Platform.sh 遇到了管道缓冲区大小限制。SparkPost 触发了 AWS 的 DDoS 保护。Foursquare 在他们的一个 MongoDB 耗尽内存时遭遇了性能骤降。

提前了解系统限制的一个办法是定期做测试。好的压力测试（在生产环境的副本上做）应该包含写入事务，并且应该把每一种数据存储都写到超过当前生产环境的容量。压力测试时很容易忽略的是次要存储（比如 Zookeeper）。如果你是在测试时遇到了资源限制，那么你还有时间去解决问题。鉴于这种资源限制问题的解决方案可能涉及重大的变更（比如数据存储拆分），所以时间是非常宝贵的。

说到云产品的使用，如果你的服务产生了异常的负载，或者你用的产品或功能还没有被广泛使用（比如老旧的或者新兴的），那么你遇到资源上限的风险很大。对这些云产品做一下压力测试是值得的。不过，做之前要提醒一下你的云服务提供商。

最后，知道了哪里有限制之后，要增加监控（和对应文档），这样你才能知道系统在什么时候接近了资源上限。不要寄希望于那些还在维护服务的人会记得。

扩散的慢请求

“这个世界的关联性远比我们想象中更大。所以我们看到了更多 Nassim Taleb 所说的‘黑天鹅事件’ —— 即罕见事件以更高的频率离谱地发生了，因为世界是相互关联的” —— Richard Thaler

HostedGraphite 的负载均衡器并没有托管在 AWS 上，却被 AWS 的服务中断给搞垮了，他们关于这次事故原因的分析报告很好地诠释了分布式计算系统之间存在多么大的关联。在这个事件里，负载均衡器的连接池被来自 AWS 上的客户访问占满了，因为这些连接很耗时。同样的现象还会发生在应用的线程、锁、数据库连接上 —— 任何能被慢操作占满的资源。

这个 HostedGraphite 的例子中，慢速连接是外部系统施加的，不过慢速连接经常是由内部某个系统的饱和所引起的，饱和与慢操作的级联，拖慢了系统中的其他部分。Spotify 的一个事故就说明了这样的传播 —— 流媒体服务的前端被另一个微服务的饱和所影响，造成健康检查失败。强制给所有请求设置超时时间，以及限制请求队列的长度，可以预防这一类故障传播。这样即使有问题，至少你的服务还能承担一些流量，而且因为整体上你的系统里故障的部分更少了，恢复起来也会更快。

重试的间隔应该用指数退避来限制一下，并加入一些时间抖动。Square 有一次服务中断是 Redis 存储的过载，原因是有一段代码对失败的事务重试了 500 次，没有任何重试退避的方案，也说明了过度重试的潜在风险。另外，针对这种情况，断路器设计模式也是有用的。

应该设计出监控仪表盘来清晰地展示所有资源的使用率、饱和度和报错，这样才能快速发现问题。

突发的高负载

系统在异常高的负载下经常会发生故障。用户天然会引发高负载，不过也常常是由系统引发的。午夜突发的 cron 定时任务是老生常谈了。如果程序让移动客户端同时去获取更新，这些客户端也会造成突发的大流量（当然，给这种请求加入时间抖动会好很多）。

在预定时刻同时发生的事件并不是突发大流量的唯一原因。Slack 经历过一次短时间内的多次服务中断，原因是非常多的客户端断开连接后立即重连，造成了突发的大负载。 CircleCI 也经历过一次严重的服务中断，当时 Gitlab 从故障中恢复了，所以数据库里积累了大量的构建任务队列，服务变得饱和而且缓慢。

几乎所有的服务都会受突发的高负载所影响。所以对这类可能出现的事情做应急预案 —— 并测试一下预案能否正常工作 —— 是必须的。客户端退避和减载通常是这些方案的核心。

如果你的系统必须不间断地接收数据，并且数据不能被丢掉，关键是用可伸缩的方式把数据缓冲到队列中，后续再处理。

自动化系统是复杂的系统

“复杂的系统本身就是有风险的系统”
—— Richard Cook, MD

过去几年里软件的运维操作趋势是更加自动化。任何可能降低系统容量的自动化操作（比如擦除磁盘、退役设备、关闭服务）都应该谨慎操作。这类自动化操作的故障（由于系统有 bug 或者有不正确的调用）能很快地搞垮你的系统，而且可能很难恢复。

谷歌的 Christina Schulman 和 Etienne Perot 在用安全规约协助保护你的数据中心的演讲中给了一些例子。其中一次事故是将谷歌整个内部的内容分发网络（CDN）提交给了擦除磁盘的自动化系统。

Schulman 和 Perot 建议使用一个中心服务来管理规约，限制破坏性自动化操作的速度，并能感知到系统状态（比如避免在最近有告警的服务上执行破坏性的操作）。

自动化系统在与运维人员（或其他自动化系统）交互时，也可能造成严重事故。Reddit 遭遇过一次严重的服务中断，当时他们的自动化系统重启了一个服务，但是这个服务是运维人员停掉做维护的。一旦有了多个自动化系统，它们之间潜在的交互就变得异常复杂和不可预测。

所有的自动化系统都把日志输出到一个容易搜索的中心存储上，能帮助到对这类不可避免的意外情况的处理。自动化系统总是应该具备这样一种机制，即允许快速地关掉它们（完全关掉或者只关掉其中一部分操作或一部分目标）。

防止黑天鹅事件

可能在等着击垮系统的黑天鹅可不止上面这些。有很多其他的严重问题是能通过一些技术来避免的，像金丝雀发布、压力测试、混沌工程、灾难测试和模糊测试 —— 当然还有冗余性和弹性的设计。但是即使用了这些技术，有时候你的系统还是会有故障。

为了确保你的组织能有效地响应，在服务中断期间，请保证关键技术人员和领导层有办法沟通协调。例如，有一种你可能需要处理的烦人的事情，那就是网络完全中断。拥有故障时仍然可用的通信通道非常重要，这个通信通道要完全独立于你们自己的基础设施及对其的依赖。举个例子，假如你使用 AWS，那么把故障时可用的通信服务部署在 AWS 上就不明智了。在和你的主系统无关的地方，运行电话网桥或 IRC 服务器是比较好的方案。确保每个人都知道这个通信平台，并练习使用它。

另一个原则是，确保监控和运维工具对生产环境系统的依赖尽可能的少。将控制平面和数据平面分开，你才能在系统不健康的时候做变更。不要让数据处理和配置变更或监控使用同一个消息队列，比如，应该使用不同的消息队列实例。在 SparkPost: DNS 挂掉的那一天 这个演讲中，Jeremy Blosser 讲了一个这类例子，很关键的工具依赖了生产环境的 DNS 配置，但是生产环境的 DNS 出了问题。

对抗黑天鹅的心理学

处理生产环境的重大事故时会产生很大的压力。为这些场景制定结构化的事故管理流程确实是有帮助的。很多科技公司（包括谷歌）成功地使用了联邦应急管理局事故指挥系统的某个版本。对于每一个值班的人，遇到了他们无法独立解决的重大问题时，都应该有一个明确的寻求协助的方法。

对于那些持续很长时间的事故，有一点很重要，要确保工程师不会连续工作到不合理的时长，确保他们不会不吃不睡（没有报警打扰的睡觉）。疲惫不堪的工程师很容易犯错或者漏掉了可能更快解决故障的信息。

了解更多

关于黑天鹅（或者以前的黑天鹅）事件以及应对策略，还有很多其他的事情可以说。如果你想了解更多，我强烈推荐你去看这两本书，它们是关于生产环境中的弹性和稳定性的：Susan Fowler 写的《生产微服务》，还有 Michael T. Nygard 的 《Release It!》。

via: https://opensource.com/article/18/10/taxonomy-black-swans

作者：Laura Nolan 选题：lujun9972 译者：BeliteX 校对：wxy

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

到目前为止，糟糕的文档是 Linux 用户最头痛的问题。这里还有一些其他常见的问题。

正如我在 2016 年开源年鉴的“故障排除提示：5 个最常见的 Linux 问题”中所讨论的，对大多数用户而言 Linux 能安装并按照预期运行，但有些不可避免地会遇到问题。过去一年在这方面有什么变化？又一次，我将问题提交给 LinuxQuestions.org 和社交媒体，并分析了 LQ 回复情况。以下是更新后的结果。

1、 文档

文档及其不足是今年最大的痛点之一。尽管开源的方式产生了优秀的代码，但是制作高质量文档的重要性在最近才走到了前列。随着越来越多的非技术用户采用 Linux 和开源软件，文档的质量和数量将变得至关重要。如果你想为开源项目做出贡献，但不觉得你有足够的技术来提供代码，那么改进文档是参与的好方法。许多项目甚至将文档保存在其仓库中，因此你可以使用你的贡献来适应版本控制的工作流。

2、 软件/库版本不兼容

我对此感到惊讶，但软件/库版本不兼容性屡被提及。如果你没有运行某个主流发行版，这个问题似乎更加严重。我个人许多年来没有遇到这个问题，但是越来越多的诸如 AppImage、Flatpak 和 Snaps 等解决方案的采用让我相信可能确实存在这些情况。我有兴趣听到更多关于这个问题的信息。如果你最近遇到过，请在评论中告诉我。

3、 UEFI 和安全启动

尽管随着更多支持的硬件部署，这个问题在继续得到改善，但许多用户表示仍然存在 UEFI 和/或 安全启动 secure boot 问题。使用开箱即用完全支持 UEFI/安全启动的发行版是最好的解决方案。

4、 弃用 32 位

许多用户对他们最喜欢的发行版和软件项目中的 32 位支持感到失望。尽管如果 32 位支持是必须的，你仍然有很多选择，但可能会继续支持市场份额和心理份额不断下降的平台的项目越来越少。幸运的是，我们谈论的是开源，所以只要有人关心这个平台，你可能至少有几个选择。

5、 X 转发的支持和测试恶化

尽管 Linux 的许多长期和资深的用户经常使用 X 转发 X-forwarding ，并将其视为关键功能，但随着 Linux 变得越来越主流，它看起来很少得到测试和支持，特别是对较新的应用程序。随着 Wayland 网络透明转发的不断发展，情况可能会进一步恶化。

对比去年的遗留和改进

视频（特别是视频加速器、最新的显卡、专有驱动程序、高效的电源管理）、蓝牙支持、特定 WiFi 芯片和打印机以及电源管理以及挂起/恢复，对许多用户来说仍然是麻烦的。更积极的一点的是，安装、HiDPI 和音频问题比一年前显著降低。

Linux 继续取得巨大的进步，而持续的、几乎必然的改进周期将会确保持续数年。然而，与任何复杂的软件一样，总会有问题。

那么说，你在 2017 年发现 Linux 最常见的技术问题是什么？让我在评论中知道它们。

via: https://opensource.com/article/17/10/top-5-linux-painpoints

作者：Jeremy Garcia 译者：geekpi 校对：wxy

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

不能在Linux或者类UNIX系统的硬盘上写入数据？想解决服务器上磁盘损坏的问题吗？想知道你为什么总是在屏幕上看到“磁盘已满”的字眼吗？想学习处理这些问题的办法吗？试试一下这8个解决Linux及UNIX服务器硬盘问题的小贴士吧。

1 - 错误: 设备上无剩余空间

当你的类UNIX系统磁盘写满了时你会在屏幕上看到这样的信息。本例中，我运行fallocate命令然后我的系统就会提示磁盘空间已经耗尽：

$ fallocate -l 1G test4.img
fallocate: test4.img: fallocate failed: No space left on device

第一步是运行df命令来查看一个有分区的文件系统的总磁盘空间和可用空间的信息：

$ df

或者试试可读性比较强的输出格式：

$ df -h

部分输出内容：

Filesystem      Size  Used Avail Use% Mounted on
/dev/sda6       117G   54G   57G  49% /
udev            993M  4.0K  993M   1% /dev
tmpfs           201M  264K  200M   1% /run
none            5.0M     0  5.0M   0% /run/lock
none           1002M     0 1002M   0% /run/shm
/dev/sda1       1.8G  115M  1.6G   7% /boot
/dev/sda7       4.7G  145M  4.4G   4% /tmp
/dev/sda9       9.4G  628M  8.3G   7% /var
/dev/sda8        94G  579M   89G   1% /ftpusers
/dev/sda10      4.0G  4.0G     0 100% /ftpusers/tmp

使用df命令输出可以清楚地发现，在 /dev/sda10 分区下总共4.0Gb的空间被全部写满了。

修复磁盘写满的问题

1.用gzip，bzip2或tar命令压缩未压缩的日志和其它文件：

gzip /ftpusers/tmp/*.log
bzip2 /ftpusers/tmp/large.file.name

2.在类UNIX系统中用rm命令删除不想要的文件：

rm -rf /ftpusers/tmp/*.bmp

3.用rsync命令移动文件至其它系统或外置硬盘:

rsync --remove-source-files -azv /ftpusers/tmp/*.mov /mnt/usbdisk/
rsync --remove-source-files -azv /ftpusers/tmp/*.mov server2:/path/to/dest/dir/

4.在类UNIX系统中找出最占磁盘空间的目录或文件：

du -a /ftpusers/tmp | sort -n -r | head -n 10
du -cks * | sort -rn | head

5.清空指定文件。这招对日志文件很有效：

truncate -s 0 /ftpusers/ftp.upload.log
### bash/sh等 ##
>/ftpusers/ftp.upload.log
## perl ##
perl -e'truncate "filename", LENGTH'

6.在Linux和UNIX中找出并删除显示着但已经被删除的大文件：

## 基于Linux/Unix/OSX/BSD等系统 ##
lsof -nP | grep '(deleted)'

## 只基于Linux ##
find /proc/*/fd -ls | grep  '(deleted)'

清空它：

 ## 基于Linux/Unix/OSX/BSD等所有系统 ##
> "/path/to/the/deleted/file.name"
## 只基于Linux ##
> "/proc/PID-HERE/fd/FD-HERE"

2 - 文件系统是只读模式吗？

当你尝试新建或保存一个文件时，你可能最终得到诸如以下的错误：

$ cat > file
-bash: file: Read-only file system

运行mount命令来查看被挂载的文件系统是否处于只读状态：

$ mount
$ mount | grep '/ftpusers'

在基于Linux的系统中要修复这个问题，只需将这个处于只读状态的文件系统重新挂载即可：

# mount -o remount,rw /ftpusers/tmp

（LCTT 译注：如果硬盘由于硬件故障而 fallback 到只读模式，建议不要强制变回读写模式，而是赶快替换硬盘）

另外，我是这样用rw模式重新挂载FreeBSD 9.x服务器的根目录的:

# mount -o rw /dev/ad0s1a /

3 - Am I running out of inodes?

有时候，df命令能显示出磁盘有空余的空间但是系统却声称文件系统已经写满了。此时你需要用以下命令来检查能在文件系统中识别文件及其属性的索引节点：

$ df -i
$ df -i /ftpusers/

部分输出内容：

Filesystem      Inodes IUsed   IFree IUse% Mounted on
/dev/sda8      6250496 11568 6238928    1% /ftpusers

如上 /ftpusers 下有总计62,50,496KB大小的索引节点但是只有11,568KB被使用。你可以在 /ftpusers 位置下另外创建62,38,928KB大小的文件。如果你的索引节点100%被使用了，试试看以下的选项：

  • 找出不想要的文件并删除它，或者把它移动到其它服务器上。
  • 找出不想要的大文件并删除它，或者把它移动到其它服务器上。

（LCTT 译注：如果一个分区存储了太多的小文件，会出现 inode 用完而存储扇区还有空闲的情况，这种情况下要么清除小文件或在不需要独立访问的情况下将它们打包成一个大文件；要么将数据保存好之后重新分区，并设置分区的 -t news 属性，增加 inode 分配）

4 - 我的硬盘驱动器宕了吗？

日志文件中的输入/输出错误(例如 /var/log/messages)说明硬盘出了一些问题并且可能已经失效，你可以用smartctl命令来查看硬盘的错误，这是一个在类UNIX系统下控制和监控硬盘状态的一个命令。语法如下：

smartctl -a /dev/DEVICE
# 在Linux服务器下检查 /dev/sda 
smartctl -a /dev/sda

你也可以用"Disk Utility"这个软件来获得同样的信息。

图 01: Gnome磁盘工具(Applications > System Tools > Disk Utility)

注意: 不要对S.M.A.R.T.工具期望太高，它在某些状况下无法工作，我们要定期做备份。

5 - 我的硬盘驱动器和服务器是不是太热了？

高温会引起服务器低效，所以你需要把服务器和磁盘维持在一个平稳适当的温度，高温甚至能导致服务器宕机或损坏文件系统和磁盘。用hddtemp或smartctl功能，通过从支持S.M.A.R.T.功能的硬盘上读取数据的方式，从而查出你的Linux或基于UNIX系统上的硬盘温度。只有现代硬驱动器有温度传感器。hddtemp功能也支持从SCSI驱动器读取S.M.A.R.T.信息。hddtemp能作为一个简单的命令行工具或守护程序来从所有服务器中获取信息：

hddtemp /dev/DISK
hddtemp /dev/sg0

部分输出内容如下：

图 02: hddtemp正在运行

你也可以像下面显示的那样使用smartctl命令：

smartctl -d ata -A /dev/sda | grep -i temperature

我怎么获取CPU的温度

你可以使用Linux硬件监控工具，例如像用基于Linux系统的lm\_sensor功能来获取CPU温度：

sensors

Debian服务器的部分输出内容：

图 03: sensors命令提供了一台Linux计算机的CPU核心温度和其它信息

6 - 处理损坏的文件系统

服务器上的文件系统可能会因为硬件重启或一些其它的错误比如坏的扇区而损坏。你可以用fsck命令来修复损坏的文件系统：

umount /ftpusers
fsck -y /dev/sda8

来看看怎么应对Linux文件系统故障的更多信息。

7 - 处理Linux中的软阵列

输入以下命令来查看Linux软阵列的最近状态：

 ## 获得 /dev/md0 上磁盘阵列的具体内容 ##
mdadm --detail /dev/md0

## 查看状态 ##
cat /proc/mdstat
watch cat /proc/mdstat

部分输出内容：

图 04: 查看Linux软阵列状态命令

你需要把有故障的硬件驱动器更换掉，别删错了。本例中，我更换了 /dev/sdb (RAID 6中的第二个硬件驱动器)。没必要依靠离线存储文件来修复Linux上的磁盘阵列，因为这只在你的服务器支持热插拔硬盘的情况下才能工作：

## 从一个md0阵列中删除磁盘 ##
mdadm --manage /dev/md0 --fail /dev/sdb1
mdadm --manage /dev/md0 --remove /dev/sdb1

# 对 /dev/sdbX 的剩余部分做相同操作 ##
# 如果不是热插拔硬盘就执行关机操作 ##
shutdown -h now

## 从 /dev/sda 复制分区表至新的 /dev/sdb 下 ##
sfdisk -d /dev/sda | sfdisk /dev/sdb
fdisk -l

## 添加 ##
mdadm --manage /dev/md0 --add /dev/sdb1
# 对 /dev/sdbX 的剩余部分做相同操作 ##

# 现在md0会再次同步，通过显示屏查看 ## 
watch cat /proc/mdstat

来看看加快Linux磁盘阵列同步速度的小贴士来获取更多信息。

8 - 处理硬阵列

你可以用samrtctl命令或者供应商特定的命令来查看磁盘阵列和你所管理的磁盘的状态：

## SCSI磁盘 
smartctl -d scsi --all /dev/sgX

## Adaptec磁盘阵列
/usr/StorMan/arcconf getconfig 1

## 3ware磁盘阵列
tw_cli /c0 show

对照供应商特定文档来更换你的故障磁盘。

监控磁盘的健康状况

来看看我们先前的教程：

  1. Monitoring hard disk health with smartd under Linux or UNIX operating systems
  2. Shell script to watch the disk space
  3. UNIX get an alert when disk is full
  4. Monitor UNIX / Linux server disk space with a shell scrip
  5. Perl script to monitor disk space and send an email
  6. NAS backup server disk monitoring shell script

结论

我希望以上这些小贴士会帮助你改善在基于Linux/Unix服务器上的系统磁盘问题。我还建议执行一个好的备份计划从而有能力从磁盘故障、意外的文件删除操作、文件损坏和服务器完全被破坏等意外情况中恢复：

via: http://www.cyberciti.biz/datacenter/linux-unix-bsd-osx-cannot-write-to-hard-disk/

作者：nixCraft 译者：ZTinoZ 校对：wxy

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