Oh yes, it's a fun ride with Debian/sid. And with the (almost) latest kernel even more so. Since the wpa_supplicant breakage is pretty nasty, this will be reported later at a more useful place. I thought I could finally disable CONFIG_DNOTIFY since it says: There exist superior alternatives, but some applications may still rely on dnotify. But rpc.idmap broke, so I read again and it said "If unsure, say Y" too - and it worked. And once again, I came across: CIFS VFS: cifs_mount failed w/return code = -22 and once again it took me a while but strace(1) revealed:

lstat64("/etc/mtab", {st_mode=S_IFREG|0644, st_size=912, ...}) = 0
readlink("/192.168.10.20", 0xbf9405db, 4096) = -1 ENOENT (No such file or directory)
stat64("/sbin/mount.cifs", 0xbf9423a0)  = -1 ENOENT (No such file or directory)
rt_sigprocmask(SIG_BLOCK, ~[TRAP SEGV RTMIN RT_1], NULL, 8) = 0
stat64("/sbin/mount.cifs", 0xbf942380)  = -1 ENOENT (No such file or directory)
mount("//192.168.10.20/data-ro", "/mnt/", "cifs", MS_MGC_VAL, NULL) = -1 EINVAL

So we really *have* to install the smbfs package to mount CIFS volumes (don't bother with SMBFS, it's dead, Jim). Quick benchmark CIFS vs. NFSv3:

# dd if=/nfs/file.img of=/dev/null bs=8M
86+1 records in
86+1 records out
727306240 bytes (727 MB) copied, 66.6383 seconds, 10.9 MB/s

# dd if=/cifs/file.img of=/dev/null bs=8M
86+1 records in
86+1 records out
727306240 bytes (727 MB) copied, 112.473 seconds, 6.5 MB/s

The server (2.6.24-rc2/knfsd, smbd-3.0.26a) was pretty much idle, the file.img was cached already, so no disk i/o on the server. The client (2.6.24-rc2, smbfs-3.0.26a) had 100% iowait with NFS (network being the bottleneck) but with cifs the [cifsd] kernel thread was using up ~30% utime, while the box was idle (60%, with 8% iowait).