私は回転するハードドライブでLinuxを実行しています。 WDC WD5000LPLX-7、「WDブラックモバイル」、7200RPM。
私は単純なファイルのコピー（または書き込み）によってfsync（）が10秒以上遅れることがわかりました。 Linuxでこれを回避する方法はありますか？いいえハードウェアを交換するか、cpコマンドを変更[*]しますか？それともこれを避けるための別の方法はありませんか？
[*]避けることができればO_DIRECTを使用したファイルの書き込み。
fsync() とは何ですか？
https://thunk.org/tytso/blog/2009/03/15/dont-fear-the-fsync/
rename() + fsync() は、停電時にも安全にファイルを自動的に更新するために使用されます。
アプリケーション開発者は、別のスレッドを使用して構成/状態更新を作成し、書き込みに時間がかかる場合にユーザーインターフェースがハングしないようにすることをお勧めします。 （例をご覧ください。GNOMEシェルで凍結）。ただし、この提案はユーザーファイルを保存するときにはあまり役に立ちません。たとえば、端末のエディタを使用して一度に 1 つずつファイルを編集すると、vi my-file編集はwq完了です。当然vi終了する前に fsync() が完了するまで待ちます。あなたは他のエディタを使用することを好むかもしれませんが、あなたのエディタも同じことをするだろうと確信しています:-).
テスト設定
$ sudo -i
# lvcreate alan_dell_2016 -n test --extents 100%FREE
Logical volume "test" created.
# ls -l /dev/alan_dell_2016/test
lrwxrwxrwx. 1 root root 7 Feb 18 13:34 /dev/alan_dell_2016/test -> ../dm-3
$ uname -r
4.20.3-200.fc29.x86_64
$ cat /sys/block/sda/queue/scheduler
mq-deadline [bfq] none
$ cat /sys/block/dm-3/queue/scheduler
none
CFQ I / Oスケジューラを使用してgnome-shell凍結を再現しました。 CFQ次のカーネルバージョンでは消えますとにかく現在、私のシステムはBFQを使用するように設定されています。
mq-deadlineスケジューラも使ってみました。これらすべてのI / Oスケジューラに対してfsync（）が10秒以上遅れることを確認しました。私のカーネルはCONFIG_BLK_WBT_MQ = yで構築されました。 （WBTはデッドラインスケジューラに適用され、デフォルトでは適用されませんbfq。）
# mkfs.ext4 /dev/alan_dell_2016/test
mke2fs 1.44.3 (10-July-2018)
Creating filesystem with 2982912 4k blocks and 746304 inodes
Filesystem UUID: 736bee3c-f0eb-49ee-b5be-de56ef1f38d4
Superblock backups stored on blocks:
32768, 98304, 163840, 229376, 294912, 819200, 884736, 1605632, 2654208
Allocating group tables: done
Writing inode tables: done
Creating journal (16384 blocks): done
Writing superblocks and filesystem accounting information: done
# mount /dev/alan_dell_2016/test /mnt
# cd /mnt
# df -h .
Filesystem Size Used Avail Use% Mounted on
/dev/mapper/alan_dell_2016-test 12G 41M 11G 1% /mnt
テストの実行
# dd if=/dev/zero of=writetest bs=1M count=5k conv=fsync & sleep 1; while true; do time sh -c 'echo 1 > latencytest; time sync latencytest; mv latencytest latencytest2'; sleep 1; killall -0 dd || break; done
[1] 17060
real 1m14.972s
user 0m0.001s
sys 0m0.000s
real 1m14.978s
user 0m0.005s
sys 0m0.002s
5120+0 records in
5120+0 records out
5368709120 bytes (5.4 GB, 5.0 GiB) copied, 75.9998 s, 70.6 MB/s
[1]+ Done dd if=/dev/zero of=writetest bs=1M count=5k conv=fsync
dd: no process found
# cp writetest copytest & sleep 3; while true; do time sh -c 'echo 1 > latencytest; time sync latencytest; mv latencytest latencytest2'; sleep 3; killall -0 cp || break; done
[1] 17397
real 0m59.479s
user 0m0.000s
sys 0m0.002s
[1]+ Done cp -i writetest copytest
real 0m59.504s
user 0m0.037s
sys 0m4.385s
cp: no process found
私はこれがファイルシステムの詳細に関連していると思います。ブロックデバイスレベルで同じタスクを実行すると、レイテンシがはるかに低くなります。
# cd / && umount /mnt
# dd if=/dev/zero of=/dev/alan_dell_2016/test bs=1M count=2000 conv=fsync &
[1] 6681
# dd if=/dev/zero of=/dev/alan_dell_2016/test oflag=sync bs=4096 count=1
1+0 records in
1+0 records out
4096 bytes (4.1 kB, 4.0 KiB) copied, 0.193815 s, 21.1 kB/s
ベストアンサー1
これらの遅延はファイルシステムによって異なります。さまざまなファイルシステムでテストを実行しました。 ext3どちらも少しext4「悪い」結果を示しました。 XFS、btrfs、bcachefsは「それほど悪くない」厳密な統計を収集しませんでしたが、次のセクションにいくつかの例示的な数字があります。
更新：結果はカーネルのバージョンによって異なります。一部のパッチが承認されたばかりで、ext4この問題と非常に関連しているようです。うん！
でテストを実行しましたが、v5.2-rc5-293-g001da3fd278f10秒以上の遅延が発生しませんでした。時々それに近いが。時には私のXFS / btrfs / bcachefsの結果よりも悪いかもしれません。
免責事項：私のテストはそれほど科学的ではありません:-)。今回のアップデートでは、「10秒を超えるfsync()待ち時間」に基づいて再現できることを確認しました。ただし、基本テストはカーネル5.1.6-200.fc29ではなくカーネルで行われましたv5.2-rc5。最初のテスト（）では長い遅延しか再現できず、writetest2番目のテスト（copytest）では再現できませんでした。
copytest後で、Firefoxと.Firefoxバージョン67.0.4（複数の拡張を含む）の両方をテストしてみました。 （カーネルは上部にパッチがあるv5.2-rc5-293-g001da3fd278fと同じで、ベースラインは5.1.11-200.fc29です。）
私のFirefoxテストは新しいタブを開くことでしたgoogle.com。ベースラインには数十秒の遅延があります。これは次のとおりです。可能同様の長いfsync遅延に関連しています。そして私考えるパッチが適用されたカーネルは、Firefoxでこの10秒以上の遅延を修正します。
だから今回のパッチに対する期待は大きいです！
つまり、copytest10G程度に達すると、マウスカーソルを含むGUI全体の応答性が低下し始めます。 Alt+SysRQ+R を使用して VT 切り替えを許可するように強制しました。数回のVTスイッチを前後に切り替えた後、GUIがクラッシュしました。
競合に関するログメッセージは、この回答の最後に添付されています。たぶん、GUIはこのような強制が好きではないかもしれません。またはそれ可能交換による遅延は、Waylandコンポジターおよび/またはXWaylandで次のようないくつかの競争条件を引き起こす可能性があります。既知のエラーどのGNOMEシェル「避けようとしています」:-(.
Ted T'soはまた、ext4ロギングの長期的な変更について文句を言ってきました。したがって、おそらく将来のある時点では、ext4にさらに改善があるでしょう！
[パッチ v2 2/3] jbd2: jbd2_inode ダーティ範囲の紹介
現在、Journal_submit_inode_data_buffers() および Journal_finish_inode_data_buffers() はどちらも、特定のログエントリに関連付けられた各 inode の完全なアドレス空間で動作します。その結果、ダーティページを継続的に追加するためのinodeがある場合は、再記録されたすべてのページが記録されるのを待っている間、無限の期間Journal_finish_inode_data_buffers（）で待機する可能性があります。
これらのワークロードを生成する最も簡単な方法は、ファイルシステム全体がいっぱいになるまで/ dev / zeroからファイルを追加することです。これにより、Journal_finish_inode_data_buffers（）がddジョブの全期間待機する可能性があります。
特定のトランザクションに関連する各inodeのダーティ範囲を決定することで、この状況を改善できます。範囲が jbd2 内に含まれ、構造のライフサイクルとロック規則に従うように、jbd2_inode 構造を介してこれを行います。
これにより、書き込みの保存を制限し、ジャーナル_submit_inode_data_buffers() および Journal_finish_inode_data_buffers() で与えられた構造 jdb2_inode のダーティ範囲に対してそれぞれ待機できるため、問題の inode がまだ接続されている場合、永遠に待つ必要はありません。
(以前)他のファイルシステムの結果
このテストは、bachefsツリーバージョンv4.20-297-g2252e4b79f8f（2019-02-14）で構築されたカーネルを使用して行われました。
上記のアップデートの免責事項も参照してください。 v5.1.6では、すべてのext4結果を再現することはできません。私のテスト方法が信頼できない場合、またはv5.1.6にアップグレードするときに大きな変更がありました。
ext4 bfq: writetest saw 15s, 30s. copytest 10s, 40s.
ext4 mq-deadline: writetest saw 10s, 30s. copytest 5s, 45s.
ext3 bfq: writetest saw 20s, 40s. copytest ~0.2s, once saw 0.5s and 2s.
ext3 mq-deadline: writetest saw 50s. copytest ~0.2s, very occasionally 1.5s.
ext3 mq-deadline, wbt disabled: writetest saw 10s, 40s. copytest similar to the above.
ext2 bfq: writetest 0.1 - 0.9s. copytest ~0.5s.
ext2 mq-deadline: writetest 0.2 - 0.6s. copytest ~0.4s
xfs bfq: writetest 0.5 - 2s. copytest 0.5 - 3.5s.
xfs mq-deadline: writetest 0.2s, some 0.5s. copytest 0 - 3s.
bcachefs bfq: writetest 1.5 - 3s.
bcachefs mq-deadline: writetest 1 - 5s.
btrfs bfq: writetest 0.5-2s, copytest 1 - 2s.
btrfs mq-deadline: writetest ~0.4s, copytest 1 - 4s.
ファイルをコピーするとext3の数字が良く見えますが、ext3はいいえ一般的に言えば、延期することをお勧めします（例：tytsoリンク参照：-）。 ext2へのログイン不足 - 一般的にロギングは堅牢性のために望ましいが、extロギングはこの遅延の原因である。
したがって、私が最も興味を持っている代替案は、XFS、実験的なbachefs、btrfsです。私はXFSが少なくとも機械式ハードドライブで最も使いやすいと思います。注目すべき違いの1つは、XFSファイルシステムを縮小するツールがなく、拡張のみが可能であることです。
GUIの競合
上記の「GUI競合」に対応するログメッセージです。
（このクラッシュの直後にgdmグリーティングプログラムもクラッシュしましたが、メッセージは少し異なりました。）
Jun 26 22:27:25 alan-laptop gnome-shell[1814]: Failed to set CRTC mode 1366x768: Permission denied
Jun 26 22:27:25 alan-laptop gnome-shell[1814]: Failed to disable CRTC
Jun 26 22:27:25 alan-laptop gnome-shell[1814]: Failed to disable CRTC
Jun 26 22:27:26 alan-laptop gnome-shell[1814]: WL: unknown object (31), message get_swipe_gesture(no)
Jun 26 22:27:26 alan-laptop gnome-shell[1814]: WL: error in client communication (pid 2259)
Jun 26 22:27:26 alan-laptop gnome-shell[1814]: WL: unknown object (28), message get_swipe_gesture(no)
Jun 26 22:27:26 alan-laptop gnome-shell[1814]: WL: error in client communication (pid 1896)
Jun 26 22:27:27 alan-laptop org.gnome.Shell.desktop[1814]: (EE)
Jun 26 22:27:27 alan-laptop org.gnome.Shell.desktop[1814]: Fatal server error:
Jun 26 22:27:27 alan-laptop org.gnome.Shell.desktop[1814]: (EE) wl_display@1: error 1: invalid arguments for [email protected]_relative_pointer
Jun 26 22:27:27 alan-laptop org.gnome.Shell.desktop[1814]: (EE)
Jun 26 22:27:26 alan-laptop gnome-shell[1814]: WL: unknown object (28), message get_swipe_gesture(no)
Jun 26 22:27:26 alan-laptop gnome-shell[1814]: WL: error in client communication (pid 2257)
Jun 26 22:27:27 alan-laptop gnome-shell[1814]: WL: unknown object (237), message get_relative_pointer(no)
Jun 26 22:27:27 alan-laptop gnome-shell[1814]: WL: error in client communication (pid 1814)
Jun 26 22:27:28 alan-laptop audit[1842]: ANOM_ABEND auid=1000 uid=1000 gid=1000 ses=2 subj=unconfined_u:unconfined_r:unconfined_t:s0-s0:c0.c1023 pid=1842 comm="Xwayland" exe="/usr/bin/Xwayland" sig=6 res=1
Jun 26 22:27:27 alan-laptop gnome-shell[1814]: clutter_actor_set_reactive: assertion 'CLUTTER_IS_ACTOR (actor)' failed
Jun 26 22:27:27 alan-laptop gnome-shell[1814]: clutter_actor_set_reactive: assertion 'CLUTTER_IS_ACTOR (actor)' failed
Jun 26 22:27:27 alan-laptop gnome-shell[1814]: clutter_actor_set_reactive: assertion 'CLUTTER_IS_ACTOR (actor)' failed
Jun 26 22:27:27 alan-laptop gnome-shell[1814]: WL: unknown object (28), message get_swipe_gesture(no)
Jun 26 22:27:27 alan-laptop gnome-shell[1814]: WL: error in client communication (pid 2251)
Jun 26 22:27:27 alan-laptop unknown[2257]: Error 22 (Invalid argument) dispatching to Wayland display.
Jun 26 22:27:27 alan-laptop gnome-shell[1814]: clutter_input_device_get_device_type: assertion 'CLUTTER_IS_INPUT_DEVICE (device)' failed
Jun 26 22:27:27 alan-laptop gnome-shell[1814]: JS ERROR: TypeError: device is null
_init/<@resource:///org/gnome/shell/ui/keyboard.js:615:1
Jun 26 22:27:27 alan-laptop unknown[2251]: Error 22 (Invalid argument) dispatching to Wayland display.
Jun 26 22:27:31 alan-laptop systemd[1]: Created slice system-systemd\x2dcoredump.slice.