iT邦幫忙

0

FreeBSD mmap on CIFS share....

鵝公司的產品因為是based on FreeBSD這個不算太熱門的OS上,而RD說讀寫檔案因為效能考量是以mmap方式處理,之前都是要user提供NFS的storage(CIFS的話只知道因歷史因素不建議用,但為啥不能用沒人說得出所以然/images/emoticon/emoticon13.gif),最近因為user強力要求要配合CIFS storage,鵝只好拿FreeBSD去mount CIFS share,然後用iozone指定以mmap方式測試,結果果然是不work,不過讓鵝大惑不解的是iozone讀寫CIFS/NFS的方式都一樣,為啥上方的CIFS會在gettimeofday這個看似和filesystem扯不上邊的動作後產生SIGSEGV而被kill掉,但下方的NFS則一切正常啊/images/emoticon/emoticon19.gif

http://ithelp.ithome.com.tw/upload/images/20160909/20004868Y5b1QcKuut.jpg

cmwang iT邦大師 1 級 ‧ 2016-09-19 18:01:59 檢舉
鵝後來找到[url=http://osdir.com/ml/os.freebsd.devel.ports/2002-03/msg00331.html]Subject: Re: ports/29704: Imagemagick Identify utility
crashes when used on smbfs mounted share[/url]....

[quote]Yes, this is an expected behavior - smbfs uses a counter to track open/close operations and if it became zero, an SMB "close" request sent to server. Obviously, mmap() doesn't give additional VOP_OPEN() call and file is really closed after close(), so any subsequent read/write operation will fail.

In the DOS/Windows world it is normal to have strong relation between open/close operations, while VOP_OPEN()/VOP_CLOSE() in FreeBSD do not match sometime (I'm suspect that it is possible to remove inconsistence, though).

One of the possible solutions is to remove smb_close request from smbfs_close() vop and leave it only in the smbfs_inactive(), but this will not allow programs to immediately release a file by just closing it.[/quote]

看來是FreeBSD對VOP_OPEN/VOP_CLOSE的解釋造成的,難怪從十幾年前就是這樣了....

尚未有邦友回答

立即登入回答