我有一个Vagrant来宾，我正在使用它在本地运行Symfony 2应用程序进行开发。总的来说，这很好，但是，我经常发现进程锁定在"D+"状态（等待I/O）。
例如。我试着运行我的单元测试：
/bin/phpunit-c应用
任务启动，但从未退出。在流程列表中，我看到：
流浪者3279 0.5 4.9 378440 101132分/0 D+02:43 0:03 php/bin/phpunit-c应用
这项任务是艰巨的。我需要给流浪客通电，让它再次回来。这似乎主要发生在PHP命令行应用程序中（但它也是我执行的主要命令行任务，因此可能不相关）。
系统日志报告一个挂起的任务：
Aug 20 03:04:40 precise64 kernel: [ 6240.210396] INFO: task php:3279 blocked for more than 120 seconds.
Aug 20 03:04:40 precise64 kernel: [ 6240.211920] "echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables this message.
Aug 20 03:04:40 precise64 kernel: [ 6240.212843] php D 0000000000000000 0 3279 3091 0x00000004
Aug 20 03:04:40 precise64 kernel: [ 6240.212846] ffff88007aa13c98 0000000000000082 ffff88007aa13c38 ffffffff810830df
Aug 20 03:04:40 precise64 kernel: [ 6240.212849] ffff88007aa13fd8 ffff88007aa13fd8 ffff88007aa13fd8 0000000000013780
Aug 20 03:04:40 precise64 kernel: [ 6240.212851] ffff88007aa9c4d0 ffff880079e596f0 ffff88007aa13c78 ffff88007fc14040
Aug 20 03:04:40 precise64 kernel: [ 6240.212853] Call Trace:
Aug 20 03:04:40 precise64 kernel: [ 6240.212859] [<ffffffff810830df>] ? queue_work+0x1f/0x30
Aug 20 03:04:40 precise64 kernel: [ 6240.212863] [<ffffffff811170e0>] ? __lock_page+0x70/0x70
Aug 20 03:04:40 precise64 kernel: [ 6240.212866] [<ffffffff8165a55f>] schedule+0x3f/0x60
Aug 20 03:04:40 precise64 kernel: [ 6240.212867] [<ffffffff8165a60f>] io_schedule+0x8f/0xd0
Aug 20 03:04:40 precise64 kernel: [ 6240.212869] [<ffffffff811170ee>] sleep_on_page+0xe/0x20
Aug 20 03:04:40 precise64 kernel: [ 6240.212871] [<ffffffff8165ae2f>] __wait_on_bit+0x5f/0x90
Aug 20 03:04:40 precise64 kernel: [ 6240.212873] [<ffffffff81117258>] wait_on_page_bit+0x78/0x80
Aug 20 03:04:40 precise64 kernel: [ 6240.212875] [<ffffffff8108af00>] ? autoremove_wake_function+0x40/0x40
Aug 20 03:04:40 precise64 kernel: [ 6240.212877] [<ffffffff8111736c>] filemap_fdatawait_range+0x10c/0x1a0
Aug 20 03:04:40 precise64 kernel: [ 6240.212882] [<ffffffff81122a01>] ? do_writepages+0x21/0x40
Aug 20 03:04:40 precise64 kernel: [ 6240.212884] [<ffffffff81118da8>] filemap_write_and_wait_range+0x68/0x80
Aug 20 03:04:40 precise64 kernel: [ 6240.212892] [<ffffffffa01269fe>] nfs_file_fsync+0x5e/0x130 [nfs]
Aug 20 03:04:40 precise64 kernel: [ 6240.212896] [<ffffffff811a632b>] vfs_fsync+0x2b/0x40
Aug 20 03:04:40 precise64 kernel: [ 6240.212900] [<ffffffffa01272c3>] nfs_file_flush+0x53/0x80 [nfs]
Aug 20 03:04:40 precise64 kernel: [ 6240.212903] [<ffffffff81175d6f>] filp_close+0x3f/0x90
Aug 20 03:04:40 precise64 kernel: [ 6240.212905] [<ffffffff81175e72>] sys_close+0xb2/0x120
Aug 20 03:04:40 precise64 kernel: [ 6240.212907] [<ffffffff81664a82>] system_call_fastpath+0x16/0x1b`
为了提供盒子，我使用共享一个本地文件夹
config.vm.synced_folder"/my/local/path.dev"，"/var/www"，：nfs=>true
Vagrant在OSX主机上创建以下/etc/exports文件：
# VAGRANT-BEGIN: c7d0c56a-a126-46f5-a293-605bf554bc9a
"/Users/djdrey-local/Sites/oddswop.dev" 192.168.33.101 -mapall=501:20
# VAGRANT-END: c7d0c56a-a126-46f5-a293-605bf554bc9a
nfsstat在流浪客户上的输出
Server rpc stats:
calls badcalls badclnt badauth xdrcall
0 0 0 0 0
Client rpc stats:
calls retrans authrefrsh
87751 0 87751
Client nfs v3:
null getattr setattr lookup access readlink
0 0% 35018 39% 1110 1% 8756 9% 19086 21% 0 0%
read write create mkdir symlink mknod
5100 5% 7059 8% 4603 5% 192 0% 0 0% 0 0%
remove rmdir rename link readdir readdirplus
4962 5% 262 0% 313 0% 0 0% 0 0% 1056 1%
fsstat fsinfo pathconf commit
1 0% 2 0% 1 0% 229 0%
我已经确保使用插件的访客添加是最新的：流浪者vbguest
我不知道如何调试它。我很清楚这是来宾和Mac OSX主机之间的NFS问题。如果我尝试使用NFS管理器在OSX上设置NFS的调试日志，我会在OSX中遇到内核死机。
其他人也有类似的问题吗？任何关于前进道路的建议都将不胜感激，因为客人每天几次电动自行车是不可行的。
环境
- OSX 10.8.4
- 流浪者1.2.7
- 虚拟机4.2.16
- 流浪客O/S:Ubuntu 12.04.2 LTS（GNU/Linux 3.2.0-23-generic x86_64）[precisie64.box]
我在共享nfs文件夹中运行npm安装时遇到了类似的问题，随后发现禁用nfs_udp修复了挂起的问题：
config.vm.synced_folder ".", "/vagrant", type: "nfs", nfs_udp: false
对于特定的答案，您没有提供足够的关于特定配置的详细信息（例如，导出文件、fstab文件、防火墙配置等）。以下是一些想法：
在fstab中，尝试将"hard，intr"标志添加到装载选项中——这样就可以杀死在死装载上等待I/O的进程。
还要确保您的防火墙对rpc调用是开放的，并且rpc-stad服务正在运行。
还要弄清楚您正在运行的nfs的版本，以及您是否打开了正确的TCP/UDP端口。如果NFS v4不起作用，可以尝试NFS v3。
最后，您是通过IP地址还是主机名进行连接？主机名很好，但要确保它总是正确解析——可能在/etc/hosts文件中。或者，对IP地址进行硬编码，这样名称解析就不会失败。。。