@Clarke #4 好搞得很。
最简单的方案，定时 smartctl -x 把输出重定向到文件，路径就在网络共享存储的根目录，平常有空顺手打开看一眼。
进阶的话稍微写点脚本做一下分析判断，结果可以放在文件可以放在网页可以发邮件。

@ebi5oowiiy1llo #15 神经质地激愤，这里讨论存储设备 IO 呢，你削尖脑袋拿网络说事是想凸显自己没长眼睛还是没长脑子呢？
就算在更普遍性的关于操作系统的讨论语境里，单说一个 IO 也大概率特指存储 IO ，要不为啥有个喜闻乐见的工具叫做 iostat ？
咋的不服？是不是还想质问“那网络的类似工具不就没有合适的名字了吗”？喏，netstat 参上。
最后，再给你补刀补到西，网络 IO 照样会导致系统卡顿，你敢说你没碰到过没听说过那要么是你没见识要么是你没良心。即使排除掉因网络问题导致程序被阻塞所呈现出来的僵死无响应这种常见情况之后，即使是单纯的网络大吞吐量也是能对系统造成压力诱发卡顿的，只不过这种影响非常小，要在老旧低算力设备上才能感觉得到。
所以别搁这少见多怪丢人现眼。

@Salticey #7 不会，我说得不够详细。
我举的例子里面，是驱动器被拔不响应、或者内部不知道在干什么不响应，相当于 IO 设备占用 100%且一直没回应，这种对应的是整个系统僵死，直到重新响应后才恢复。
你的情况并不是 100%占用，也不是长时间不响应，所以不会完全僵死，只会有卡顿的感觉。

IO“阻塞”是系统级“灾害”，无所谓在哪块盘哪个分区上。
稍微想想就能明白，外部存储器的数据交换没能及时完成的话系统必须等，因为根本没法预测“不等待”会不会造成灾难，所以只能等。但凡是内存里面的事情都多少可以预测一下，唯独外存上的事情谁都说不准，到时候数据被错误改写了、丢失了，谁负责？ CPU ？内存条？主板？寄存器？某某进程？系统内核？所以只能老老实实等着，该阻塞就阻塞。哪怕启用了读写缓存也是一样，因为缓存是系统的一部分。
参考 Windows To Go 的可移动存储设备一旦被拔系统就自动僵住，直到插回去才恢复，当然这个僵住是预先设计的可控的。
我曾经有台电脑自己加装的 SSD 会隔几个月来一次“大扫除”，我也不知道它在干嘛但反正得有个一两分钟的无响应过程，这期间整个系统都僵死，无任何反应，除了硬盘灯保持常亮（闪都不闪就直接稳稳当当地一直亮着）以外，根本无从知道发生了什么，但这个过程一旦结束，哪怕系统僵了好几分钟也能迅速恢复正常。我一开始慌得一比，后来习惯了直接起身喝水放水回来它就好了。

我在 Ubuntu 下用的替代是 fsearch ，这玩意从一开始就是冲着模仿 everything 立项的，而且目前很多常用功能都自带了，性能很强速度很快。貌似应该是跨平台的，你可以试试。

@ffzy everything 强在本地 NTFS 自动索引，远程目录索引且有一定程度的变动监控，外加路径过滤，与或非逻辑搜索，正则搜索。这些东西莫非 listary 也有？

@thinkershare xpra 试过吗？我个人使用是远程连 Windows 就用自带的远程桌面，连 Linux 就用 xpra 。
很多年前用 x2go ，当时觉得挺好用的，后来不知怎么回事几台设备都不能正常用了，没能成功排障就干脆不用 x2go 了。