Gnome、ノーチラスのUSBへのファイルのコピーが100％近くで停止する

以前にも同様の問題がありましたが、どのように解決したか覚えていません。

FATを使用して何かをUSBスティックにコピーしようとすると、終わり近くで停止する場合があります。そしてもちろん、メモリスティックを別の場所に転送すると、完全なファイルが含まれなくなります。（ファイルは映画です！）

mount -o flushでデバイスをマウントしようとしましたが、同じ問題が発生します。

また、USBスティックを新しいFATパーティションでフォーマットしました...

どんな風邪をひきますか？

追伸：DebianであるOSとは関係ないと思います。SSDドライブからの対処でスタックすることはないと思います。

そのように発生する理由は、プログラムが「このデータを書き込む」と言い、Linuxカーネルがそれをディスクに移動するためにキューに入れられたメモリバッファーにコピーし、「OK、完了」と言うからです。そのため、プログラムはすべてをコピーしたと考えます。その後、プログラムはファイルを閉じますが、突然バッファーがディスクにプッシュされるまでカーネルは待機します。

そのため、残念ながら、プログラムはバッファをフラッシュするのにどれだけの時間がかかるかわからないので、それを知ることができません。

パワーユーザー向けのトリックを試してみたい場合は、カーネルパラメーターvm.dirty_bytesを15000000（15 MB）のような値に設定して、Linuxが使用するバッファーのサイズを小さくすることができます。これは、アプリケーションが実際の進捗より15MB以上先に進むことができないことを意味します。（カーネルパラメーターはその場で変更できますがsudo sysctl vm.dirty_bytes=15000000、再起動後も維持/etc/sysctl.confするには、ディストリビューションに固有のような構成ファイルを変更する必要があります。）

副作用として、この設定ではコンピューターのデータ書き込みスループットが低下する可能性がありますが、全体として、大量のデータを書き込み中にプログラムが長時間実行されていることと、プログラムはそのジョブで完了したように見えますが、カーネルが実際の作業を行うため、システムはひどく遅れます。dirty_bytes適度に小さい値に設定すると、空きメモリが少なく、突然大量のデータを書き込むプログラムを実行したときにシステムが応答しなくなるのを防ぐのにも役立ちます。

ただし、あまり小さく設定しないでください！カーネルがバッファを1/4秒以下で通常のハードドライブにフラッシュできるという概算として15MBを使用します。それは私のシステムが「遅れ」を感じないようにします。

古い質問ですが、問題がまだ発生しているようです。ここで提案されているようにバッファを15MBに設定してもUbuntu 19.04では機能せず、システムが停止してしまいました。

1.5GBファイルを空の（新しくフォーマットされた）FAT32 16GBドライブにコピーしようとしました。運がなくても終了するかどうかを確認するために、約10分間実行しました。

NTFSに再フォーマットすると、操作は10秒未満で終了します。FAT32は2GB未満を許可するので、なぜこれが重要なのかわかりませんが、うまくいくように見えました。MacOSで使用したいドライブの理想的な修正ではありませんが、他のすべてのユースケースの簡単な回避策です。exFATも同様に機能すると思いましたが、テストしませんでした。