ls hangs for a certain directory
Solution 1:
Run strace ls /var/www/ and see what it hangs on. It's certainly hung on I/O -- that's what the D state in your ps output means (and since kill doesn't help, it's one of the uninterruptible I/O syscalls). Most hangs involve an NFS server that's gone to god, but based on your df that isn't the case here. A quick check of dmesg for anything related to filesystems or disks might be worthwhile, just in case.
Solution 2:
I had a problem with the same symptoms. It turned out that I had a symlink in that directory to an SMB mount over GVFS.
lrwxrwxrwx 1 alex alex 45 Sep 16 2011 foo -> /home/alex/.gvfs/bar on foo/data/
Normally ls would complete instantly whether or not the share was mounted. But in this case I had suspended and resumed the machine, and the mount was performing poorly in general. Remounting the share fixed the problem.
Solution 3:
On the hope this will be helpful, I had the above symptoms being caused by using docker and docker compose with the AUFS driver in Ubuntu 14.04. ls <dir> was hanging, and strace ls <dir> showed it was hanging on the getdents call. Stopping all running containers allowed me to begin using the drive as expected.
Solution 4:
I was experiencing the same problem.
Entering a directory is fine, listing it hangs, find works, tab complete hangs, and some folders beneath do work. Very head-scratchingly-weird.
Reading this thread on Server Fault did lead me on a logic path towards the solution.
It being to do with NAS, and NAS commonly being put as `automount' made me realise that I had recently changed my fstab to 'automount' some usb drives if they were present but carry on as normal when they weren't.
I then proceeded as follows:
- Unmount the partition containing the delinquent directory.
- Edit fstab and convert all automount to either commented out or without auto.
- Reload SystemD if you have it: systemctl --system daemon-reload
- mount -a
Try entering the directory again and get that warm fuzzy feeling of having fixed the issue.