Ext4文件系统上Dropbox疑问

备注

目前Ext4文件系统上运行Dropbox的高iowait问题我还没有解决，有时间我会再做尝试。目前暂时改成采用 Studio环境的LVM+XFS存储 运行。

Dropbox在2018年有一段时间放弃了Linux Ext4之外的文件系统，所以 ` How To Use Dropbox On Non-Ext4 Filesystems (Btrfs, Ext3, XFS, ZFS, Etc.) On Linux <https://www.linuxuprising.com/2018/11/how-to-use-dropbox-on-non-ext4.html>`_ 提供了解决方法。不过，2019年Dropbox又恢复了Linux下多种文件系统支持(详情见 What are the system requirements to run Dropbox? )

在 MacBook Pro上运行Arch Linux 遇到一个奇怪的问题，磁盘性能似乎极差，特别是当启动 Dropbox 同步网盘数据之后，虽然dropbox网络流量极低，但是 top 检查 iowait 非常高导致系统相应缓慢：

../../../../_images/dropbox_high_iowait.png

但是，通过 iostat 检查却发现磁盘读写非常小，完全达不到SSD的性能:

../../../../_images/dropbox_iostat.png

之前在 ThinkPad X220上运行Arch Linux 同样的Arch Linux，但是运行 Dropbox 没有丝毫问题，数据很快就同步完。那么，两者的差异是什么？

文件系统差异

ThinkPad X220上运行Arch Linux ，我做了 Studio环境的LVM+XFS存储 ，将完整的 /home 目录迁移到 XFS 文件系统中存储。但是，我觉得，默认安装的Arch Linux所使用的 ext4 文件系统不会弱到连个人目录都无法支持吧。

观察了一下 MacBook Pro上运行Arch Linux ，默认通过安装程序 genfstab -U /mnt >> /mnt/etc/fstab 生成的配置:

# <file system> <dir> <type> <options> <dump> <pass>
# /dev/sda3
UUID=e38d80cc-4044-4d34-b730-1f0c874ad765/               ext4        rw,relatime  0 1

这里 ext4 文件系统挂载参数 relatim 似乎和以往推荐的 noatime 挂载参数不同。

备注

参考 Mount options – atime vs relatime :

参数 relatime 和 atime 不同之处在于，每次文件访问时，relatime 不是马上修改访问时间(atime)，仅在以下条件之一满足时才修改atime:

  • 文件修改时间(modified time, mtime)或者文件修改时间状态(change time status, ctime) 比文件访问时间(atime)更新的时候

  • 文件访问时间(atime)比定义间隔更旧(在RHEL系统中默认是1天)

relatime 参数是介于 atime 和 noatime 选项之间的一个较好的混合参数，对于大多数需要获取文件访问时间的应用非常有用。如果使用 relatime 选项，即使一个文件经常访问也不会产生大量的磁盘流量。例如，对于WEB服务器， relatime 就是一个很好的磁盘挂载参数方案，因为这种情况下有大量的读活动，而仅仅每天更新一次 atime 。

对于固态硬盘(SSD)，如果没有应用程序需要atime，则可以修改成 noatime 。

Dropbox挂载Ext4要求

参考 Dropbox: ext4 isn’t ext4 介绍了Dropbox在Linux的Ext4文件系统工作需要满足以下要求：

  • (文档明确要求的)Dropbox需要使用 ext4 文件系统，并且 不能 设置 ecryptfs ，即文件系统不能加密

  • 其他没有明确文档的文件系统要求有： - ext4 文件系统需要使用 ext_attr 激活的方式进行格式化，这是一个默认特性，你可以通过 debugfs -R features /dev/sda1 检查。 - ext4 文件系统需要使用 user_xattr 选项挂载。这个参数可以通过 /etc/fstab 检查，或者使用 mount 命令检查挂载参数。 - 另外 Dropbox 目录需要位于二层目录

  • 检查 /dev/sda3 文件系统格式化参数情况:

    debugfs -R features /dev/sda3

显示输出:

Filesystem features: has_journal ext_attr resize_inode dir_index filetype needs_recovery extent 64bit flex_bg sparse_super large_file huge_file dir_nlink extra_isize metadata_csum

备注

使用 tune2fs -l /dev/sda3 能够检查文件系统的详细信息，也包括了 Filesystem features

  • 检查 / 文件系统挂载参数:

    mount

显示:

/dev/sda3 on / type ext4 (rw,relatime)

这个挂载参数是因为默认的安装对于ext4的挂载就是这个参数 ext4       rw,relatime

备注

user_xattr 是Ext4的用户扩展属性支持参数。

使用 tune2fs -l /dev/sda3 可以看到输出信息现实:

Filesystem features:      has_journal ext_attr resize_inode dir_index filetype needs_recovery extent 64bit flex_bg sparse_super large_file huge_file dir_nlink extra_isize metadata_csum
Filesystem flags:         signed_directory_hash
Default mount options:    user_xattr acl

这表明，Ext4文件系统默认挂载参数包括了 user_xattr acl ，所以不需要特别指定。

虽然 tune2fs -l /dev/sda3 显示默认就已经激活了 user_xattr 选项，不过 mount 输出没有，所以我还是尝试显式挂载文件系统:

mount -n -o rw,relatime,user_xattr,remount /

然后检查 mount 命令输出显示:

/dev/sda3 on / type ext4 (rw,relatime)

难道没有生效？手工修改 /etc/fstab 添加这个参数:

UUID=e38d80cc-4044-4d34-b730-1f0c874ad765/               ext4        rw,relatime,user_xattr  0 1

然后重启系统。但是发现，这个 user_xattr 挂载参数并不会显示在 mount 输出中，依然显示:

/dev/sda3 on / type ext4 (rw,relatime)

修改Ext4文件系统noatime

  • 尝试将 relatime 修订成 noatime

    mount -n -o rw,noatime,remount /

检查确认 mount 输出已经是 /dev/sda3 on / type ext4 (rw,noatime) ，然后尝试重新启动 Dropbox ，但是发现没有改善性能。

fio性能测试

参考 How to use Fio (Flexible I/O Tester) to Measure Disk Performance in Linux 做一个磁盘性能测试:

sudo fio --randrepeat=1 --ioengine=libaio --direct=1 --gtod_reduce=1 --name=test --filename=random_read_write.fio --bs=4k --iodepth=64 --size=4G --readwrite=randrw --rwmixread=75

发现磁盘性能很好:

test: (g=0): rw=randrw, bs=(R) 4096B-4096B, (W) 4096B-4096B, (T) 4096B-4096B, ioengine=libaio, iodepth=64
fio-3.16
Starting 1 process
test: Laying out IO file (1 file / 4096MiB)
Jobs: 1 (f=1): [m(1)][100.0%][r=221MiB/s,w=73.2MiB/s][r=56.5k,w=18.8k IOPS][eta 00m:00s]
test: (groupid=0, jobs=1): err= 0: pid=2144: Tue Oct 22 00:42:32 2019
  read: IOPS=58.7k, BW=229MiB/s (241MB/s)(3070MiB/13385msec)
   bw (  KiB/s): min=219472, max=247088, per=100.00%, avg=235071.08, stdev=7541.43, samples=26
   iops        : min=54868, max=61772, avg=58767.77, stdev=1885.36, samples=26
  write: IOPS=19.6k, BW=76.7MiB/s (80.4MB/s)(1026MiB/13385msec); 0 zone resets
   bw (  KiB/s): min=73592, max=82296, per=100.00%, avg=78584.31, stdev=2656.22, samples=26
   iops        : min=18398, max=20574, avg=19646.08, stdev=664.06, samples=26
  cpu          : usr=12.85%, sys=42.51%, ctx=43501, majf=0, minf=7
  IO depths    : 1=0.1%, 2=0.1%, 4=0.1%, 8=0.1%, 16=0.1%, 32=0.1%, >=64=100.0%
     submit    : 0=0.0%, 4=100.0%, 8=0.0%, 16=0.0%, 32=0.0%, 64=0.0%, >=64=0.0%
     complete  : 0=0.0%, 4=100.0%, 8=0.0%, 16=0.0%, 32=0.0%, 64=0.1%, >=64=0.0%
     issued rwts: total=785920,262656,0,0 short=0,0,0,0 dropped=0,0,0,0
     latency   : target=0, window=0, percentile=100.00%, depth=64

Run status group 0 (all jobs):
   READ: bw=229MiB/s (241MB/s), 229MiB/s-229MiB/s (241MB/s-241MB/s), io=3070MiB (3219MB), run=13385-13385msec
  WRITE: bw=76.7MiB/s (80.4MB/s), 76.7MiB/s-76.7MiB/s (80.4MB/s-80.4MB/s), io=1026MiB (1076MB), run=13385-13385msec

Disk stats (read/write):
  sda: ios=773765/258693, merge=216/54, ticks=599183/117277, in_queue=178790, util=98.03%

测试过程 top 显示没有任何 iowait。

看起来就是 Dropbox 的 iowait 高。

参考 Arch Linux running on my MacBook 介绍参数修改成:

rw,relatime,data=ordered,discard

但是我实际测试依然没有解决ext4文件系统在Dropbox下iowait极高的问题。

iotop和perf top

从 iotop 就可以看到 jdb2/sda3-8 内核线程始终极高cpu占用率。

../../../../_images/dropbox_iotop_perf_top.png

不过参考 ropbox is compatible with Ext4 but doesn’t recogn 提示，需要修改挂载参数:

ext4 rw,user,exec,auto,user_xattr

尝试执行:

mount -n -o remount,rw,user,exec,auto,user_xattr /dev/sda3 /

然后检查挂载 mount 输出:

/dev/sda3 on / type ext4 (rw,nosuid,nodev,noatime,discard,commit=60)

但是，上述方法依然没有解决负载过高问题，问题依旧。另外，上述挂载参数 nosuid 会导致文件系统无法使用 sudo ，请谨慎使用。

暂时放弃

目前还没有找到解决方案，我准备暂时切换到 Studio环境的LVM+XFS存储 方案看看能否改善这个性能问题。