主页 / user-8088

liori's questions

Martin Hope
liori
Asked: 2019-05-27 06:36:35 +0800 CST
  • 3

我正在调试一个 fuse 文件系统，它报告了错误的du. 事实证明，它正在将st_size / st_blksize[*] 放入结构中st_blocks。statLinux手册页stat(2)说：

struct stat {
    …
    off_t     st_size;    /* total size, in bytes */
    blksize_t st_blksize; /* blocksize for file system I/O */
    blkcnt_t  st_blocks;  /* number of 512B blocks allocated */
    …
};

st_blksize无论如何，如果在 512B 块中是什么意思st_blocks？

[*] 无论如何看起来都是错误的，因为整数除法不考虑小数部分......

stat api
Martin Hope
liori
Asked: 2019-02-03 16:24:24 +0800 CST
  • 3

在最近一次硬件迁移之后，我开始遇到奇怪的 I/O 停顿，影响我的桌面 Debian Stretch 系统。典型症状，都发生在每个摊位期间：

  • 我无法与我的网络浏览器 Chromium 交互。没有任何效果：网页滚动（通常这是我注意到停顿的方式）、切换标签等。无论是在网页上还是在 Chromium UI 上，都没有鼠标悬停动作。

  • 在虚拟终端中，我无法再运行新进程。例如，我在其中打开一个新选项卡，mate-terminal但我的 shell 没有出现，只是光标在闪烁。在停止前打开 shell 的终端中，我可以输入命令，但通常它不会启动；sudo something甚至不要求输入密码。

  • 其他程序，如 RStudio，无法将任何内容保存到磁盘，并且在尝试保存时经常挂起。

  • 我在日志中看到journald -f，如果停顿时间足够长，journald它本身会重新启动，例如：

      sty 30 14:03:54 liori-pc systemd[1]: systemd-journald.service: Main process exited, code=killed, status=6/ABRT
  sty 30 14:03:54 liori-pc systemd[1]: systemd-journald.service: Unit entered failed state.
  sty 30 14:03:54 liori-pc systemd[1]: systemd-journald.service: Failed with result 'watchdog'.
  sty 30 14:03:54 liori-pc systemd[1]: systemd-journald.service: Service has no hold-off time, scheduling restart.
  sty 30 14:03:54 liori-pc systemd[1]: Stopped Flush Journal to Persistent Storage.
  sty 30 14:03:54 liori-pc systemd[1]: Stopping Flush Journal to Persistent Storage...
  sty 30 14:03:54 liori-pc systemd[1]: Stopped Journal Service.
  sty 30 14:03:54 liori-pc systemd[1]: Starting Journal Service...
  sty 30 14:03:54 liori-pc systemd-journald[23935]: Journal started
  sty 30 14:03:54 liori-pc systemd-journald[23935]: System journal (/var/log/journal/2318080f60e357aaf765e98d0000035c) is 2.1G, max 4.0G, 1.8G free.

  • 当使用 dm_crypt 时，一个dmcrypt_write进程开始占用单个 CPU 内核的 100%（我后来从这个系统中删除了 dm_crypt，但仍然会发生停顿）。

  • 我观察/proc/meminfo并看到这个Dirty数字永远不会超过几兆字节。值得注意的是，在停顿期间，这个数字不会改变。

  • 在极少数情况下，我什至会收到一条内核消息，格式为“INFO：task «some process»blocked for more than 120 seconds.”，«some_process»通常是 mdX_raid5、chromium 或其线程之一等。示例日志.

/dev/sdd最初，我的设置只是单个 1TB 驱动器（当前）分区上的单个 600GB ext4 文件系统。然后我迁移到 3×6TB 驱动器 ( /dev/sd{b,c,e})，使用基于 LVM 的 raid5、bcache 及其在 SSD 驱动器上的缓存，然后是 dm_crypt — 这就是停顿开始的时候。在调试的过程中，我将其简化为 LVM-raid5，没有 bcache 或 dm_crypt；摊位仍然会发生，尽管我觉得现在已经不那么频繁了。

这种失速一天会发生数次，通常持续几分钟。我注意到我可以通过明确请求一些磁盘操作来破坏它：我有时可以通过从远程机器上通过 ssh 登录到这个系统来破坏它，或者（几乎总是）通过cat /dev/sdb >/dev/null或者cat /dev/sdc >/dev/null（有时一个，有时另一个工作; 特别是cat /dev/sde >/dev/null从来没有帮助过）。然后，一切停滞不前的东西突然又开始工作了。

所以我怀疑问题是由以下之一或相互作用引起的：

  • 驱动器：三个都是希捷 Skyhawk ST6000VX0023。其中两个在此设置之前未使用，第三个使用了半年（/dev/sdc）。
  • 磁盘控制器：主板：Gigabyte Z68X-UD3H-B3有两个控制器：Marvell 88SE9172其中一个驱动器连接到其中，芯片组内置控制器（Intel® Z68）与另外两个（我可以检查哪一个在软件中的位置吗？）。
  • 控制器内核驱动程序中的一些错误。
  • LVM 或 raid5 中的一些错误。

这是一个 Debian Stretch 系统，安装了一些向后移植的软件包，最显着的是 kernel 4.19.0-0.bpo.1-amd64。英特尔酷睿 i7-2600k，16GB 内存。

在这一点上，我没有想法了。如何进一步调试此问题？

编辑：我开始了一个脚本，它每 4 秒从其中一个驱动器中读取一个随机扇区，并且现在 2 天没有停顿。因此，确实看起来某些系统组件（LVM？raid？）在必要时无法正确地将设备从某种低功耗模式中唤醒。

编辑：我不再可以访问这个系统，所以我不能再测试任何假设。我只能说，在运行该脚本后，我不再获得摊位。不过，我希望我知道如何调试它。

io delay