What is the server type? (you can view this by seeing the "NOS" field in /proc/fs/cifs/DebugData or checking to see if "unix" is listed in the mount when you do "cat /proc/mounts | grep cifs") When mounted to Samba for example, with cifs unix extensions negotiated, the cifs client will send open flags (including O_DIRECT IIRC) to the server on open. When mounted to Windows/NetApp etc. or when using "nounix" on mount, the flag is not sent on open. On Fri, Jun 27, 2014 at 6:14 AM, Kevin Wolf <kwolf@xxxxxxxxxx> wrote: > Hi Steve, > > I just discussed a problem with a qemu user on IRC, which boiled down to > him trying to open an image file on cifs with O_DIRECT, but not using a > directio mount. I understand that this probably isn't going to work > anytime soon (if at all), but it resulted in a rather unhelpful failure > mode. > > What happens is that cifs lets the open() call succeed even with the > unsupported O_DIRECT on that mount, but then fails any I/O on the file > descriptor. I believe this was introduced in commit dca69288 (which I > think is otherwise pretty useful). > > With the old behaviour, qemu detected what's going on and suggested to > use a non-O_DIRECT mode to the user, but with the new one, it got rather > unhappy after failing to find a working O_DIRECT alignment and ran into > an assertion failure... > > Now I'll certainly fix the latter in qemu, but I also think that the > behaviour of cifs is rather surprising. Any chance that you can make > open() with O_DIRECT fail again on non-directio mounts? > > Thanks, > Kevin -- Thanks, Steve -- To unsubscribe from this list: send the line "unsubscribe linux-cifs" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
