Date: Wed, 14 Jul 2004 12:26:02 -0400 From: Bill Moran <wmoran@potentialtech.com> To: "Artem Kuchin" <matrix@itlegion.ru> Cc: freebsd-questions@freebsd.org Subject: Re: Need a network file system with Windows client and freeBSD server Message-ID: <20040714122602.764c4ba3.wmoran@potentialtech.com> In-Reply-To: <002001c469bd$88400950$5e11a8c0@WINXP> References: <004001c469b1$a74dacf0$0c00a8c0@artem> <20040714113112.53fdbfb7.wmoran@potentialtech.com> <002001c469bd$88400950$5e11a8c0@WINXP>
next in thread | previous in thread | raw e-mail | index | archive | help
"Artem Kuchin" <matrix@itlegion.ru> wrote: > > > I need sime kind of network file system which has a FreeBSD server and > > > Windows clients (particulary Windows XP) and that FreeBSD file share > > > must be mounted on Windows XP under a drive letter. Windows client > > > is FAR FAR away and is behind nat. Traffic costs a lot, so that file > system > > > must not waste it for nothing. Of course, security is very important and > > > security based on IP address is impossible, because client is behind > nat. > > > > > > I have checked the following: > So, basically you are saying that there is no solution for what i need? > WinSCP does not suit my needs, because people on windows client must > be able to work on files (mostly html) using different software and it is > not just > about moving then around, but rather editing with special editors and after > editing they must see the result right away on the web server. In my experience, no, there is no solution to your problem. The resason is this: 1) You expect people to be able to work on mapped drives (i.e. z:) 2) You are trying to hold down the bandwidth usage These two goals are contradictary. You'll have to give up one or the other (unless there's some filesystem technology out there that I'm not familiar with) No matter how efficient the file-sharing protocol is, the fact that you've got the filesystem mounted as a network drive will push tons of extra data through the pipe. Windows is not used to high-latency links for file- sharing, thus the performance will be noticably bad. In my experienc, Windows users don't understand the idea of latency either, thus they will click on something three times when they should just wait for it to finish loading, thus generating more bandwidth. Also, directory listings, polling for changes to directories and all sorts of other things that Windows does with drives will push tons of network traffic across the link, thus driving up your costs. This has been my experience. Perhaps your users are smarter and more disciplined than the people I was working with, but mounting a network drive under windows carries a lot of traffic with it as baggage. I've never measured exactly how much, but it's more than most people realize. For example, I've found that a 1.5mb/sec T1 line isn't really fast enough for a single SMB mounted drive. If I were you, I'd set up some sort of tunnel and run a pilot test with 1 user. I don't expect you'll be happy with the results, but it is possible that I didn't set things up as well as could be the last time I did this. Just be aware of the network traffic, as it ended up being a lot more than I expected. You'll probably have better results setting up some sort of terminal serer (either VNC or MS terminal server) and allowing users to work on the remote files that way. Terminal servers still use a lot of bandwidth, but they're designed for slow links, so it's not quite as bad (this may or may not be the same in your scenerio, as working with HTML files might not generate as much traffic as the MS Access files we were working with). -- Bill Moran Potential Technologies http://www.potentialtech.com
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20040714122602.764c4ba3.wmoran>