Re: NFS alternative
On Fri, Jul 20, 2001 at 07:26:21PM -0700, Francois Gouget wrote: >I don't know of a reference book that would be specifically about NFS > but you can have a look at "The Design and Implementation of the 4.4BSD > Operating System" by McKusik, Bostic, Karels and Quarterman. Chapter 9 > (about 25 pages) is about NFS and should give you a feel for it. And the > book as a whole is just awsome. Definitely a must have if you're > interested in operating system design. Definitely a must if you want to understand unix in general. There is also a video set to go with the book, hosted by McKusick, in which he says about NFS that it really should mean "no filesystem semantics". There are more cute anecdotes in it, like the one where McKusick expresses his regret about not having sided more strongly with Richard Stallman, when he proposed POSIX_ME_HARDER as the name for the variable that ended up with the name POSIXLY_CORRECT. Cheers, Joost
Re: NFS alternative
On Fri, Jul 20, 2001 at 07:26:21PM -0700, Francois Gouget wrote: >Well, of course you can bet that all these issues have been taken > into account in the design of the NFS protocol. >But actually this touches an important aspect of NFS servers: by > design/philosophy they are stateless. This means that the NFS server can > crash, reboot, and to the client it makes strictly no difference (the > same goes for the client). And this fits well with UDP since it's a > connectionless protocol. >Compare this to the SMB protocol used by Windows. This protocol is > resolutely stateful. And guess what: SMB uses TCP connections. So if the > server crashes then the clients have to reconnect to the server and try > to resynchronize their state with the state of the server somehow. Well, > of course, the designers of the SMB protocol thought of the issue too > and I'm sure it's all taken care of. Actually, if the SMB server goes down, all state is lost...
Re: NFS alternative
On 17 Jul 2001, Brian May wrote: [...] > I have heard though, that NFS uses RPC, and RPC doesn't do anything > this sophisticated. Rather, if the server doesn't respond in time, the > client sends the request again. > > This is OK for requests like "read file", which don't affect the state > of the server, as the worst thing that could happen is that the server > will reread the file again. > > For other requests though, like "delete file", confusion could > occur. eg. consider the case where the client wants to delete file X, [...] Well, of course you can bet that all these issues have been taken into account in the design of the NFS protocol. But actually this touches an important aspect of NFS servers: by design/philosophy they are stateless. This means that the NFS server can crash, reboot, and to the client it makes strictly no difference (the same goes for the client). And this fits well with UDP since it's a connectionless protocol. Compare this to the SMB protocol used by Windows. This protocol is resolutely stateful. And guess what: SMB uses TCP connections. So if the server crashes then the clients have to reconnect to the server and try to resynchronize their state with the state of the server somehow. Well, of course, the designers of the SMB protocol thought of the issue too and I'm sure it's all taken care of. Now, you are worried that if an NFS UDP packet is lost you'll get into trouble. But what if an SMB client sends an 'append' command to the server, the server performs the operation but crashes before sending the reply, reboots, causing the client to reconnect and resend the command... You see, using TCP did not save you completely. You get exactly the same problem as if the NFS server had crashed and rebooted, or the command packet got lost, or the reply packet got lost. I believe that the work to recover from such problems must be relatively equivalent in both cases. Btw, I doubt that there is an 'append' command as it is so obviously not 'idempotent'. Of course there must be some sort of 'delete_file' operation and I'm not sure how them make that one 'idempotent'. But in multi-user systems how do you know if the file was not deleted by some other user in the first place... > Conclusion: (if my sources are correct) never use NFS (unless mounted > read-only) over a congested network... I think you need to do some reading. I don't know of a reference book that would be specifically about NFS but you can have a look at "The Design and Implementation of the 4.4BSD Operating System" by McKusik, Bostic, Karels and Quarterman. Chapter 9 (about 25 pages) is about NFS and should give you a feel for it. And the book as a whole is just awsome. Definitely a must have if you're interested in operating system design. I'm definitely going to re-read this chapter... -- Francois Gouget [EMAIL PROTECTED]http://fgouget.free.fr/ 1 + e ^ ( i * pi ) = 0
Re: NFS alternative
On Tue, Jul 17, 2001 at 03:47:30AM +0200, Jean-Baptiste Note wrote: > > > Thankfully, I forget the details[0]. From experience, no, it won't be > > exactly hosed: you'll end up with a .nfs004950384672385721380937 file that > > will grow and eventually fill up the partition... nothing an rm -rf / won't > > fix. And then there's negative cookies and stale mounts that require a > > reboot > > on most unices I've seen... you had to remind me, didn't you? > > > > from my own limited experience, stale mounts are not a problem if you > can unmount then mount again the partition containing the "damaged" > export. Note that mount -o remount doesnt do the trick, but umount then > mount does it. That's why i keep nfs mounts on separate partition. > (i have 4 X kernel-over-ftfp and root-over-nfs boxen that users can > start and restart at will without proper shutdown, and a reboot each > time a stale mount occured started to get on my nerves.) > Do you get stale mounts on the root fs? If not, you could use autofs to mount the other nfs partitions as needed, and avoid stale mounts if files aren't kept open 24/7. Just an idea...
Re: NFS alternative
* Jean-Baptiste Note ([EMAIL PROTECTED]) spake thusly: > ... > > from my own limited experience, stale mounts are not a problem if you > can unmount then mount again the partition containing the "damaged" > export. Note that mount -o remount doesnt do the trick, but umount then > mount does it. That's why i keep nfs mounts on separate partition. > That works if you don't have a process blocked on IO to stale mount. IME fuser -k and umount -f don't work on these; reboot is the fastest way to clear it. It gets particularly bad when you have a bunch of servers exporting some FS's and nfs-mounting some others. Then you end up with dependency loops where rebooting one server creates stale mounts on others. Loads of fun. But this is way OT. Dima -- E-mail dmaziuk at bmrb dot wisc dot edu (@work) or at crosswinds dot net (@home) http://www.bmrb.wisc.edu/descript/gpgkey.dmaziuk.ascii -- GnuPG 1.0.4 public key I'm going to exit now since you don't want me to replace the printcap. If you change your mind later, run -- magicfilter config script
Re: NFS alternative
On Tue, Jul 17, 2001 at 06:53:51PM +1000, Steve Kowalik wrote: | On Tue, Jul 17, 2001 at 04:05:10PM +1000, Brian May uttered: | > Well, in theory, all UDP packets could be numbered, much like TCP | > packets, and you get exactly the same reliability TCP offers. This | | I doubt that. UDP isn't a connection oriented protocol, and as such, it | can't deal with a packet out of order. Actually, what Brian says makes sense. UDP itself can't deal with a packet out-of-order, but Brian says that the application using UDP can deal with it itself. Kind of like re-inventing the wheel. He said the nice thing about TCP, in this situation, is that other people have already done that dirty work so he (the app developer) doesn't need to worry about it. Thanks everyone for the comments on NFS and diskless terms. -D
Re: NFS alternative
In article <[EMAIL PROTECTED]>, D-Man <[EMAIL PROTECTED]> wrote: >Ok, yeah. I'm not worried about congestion on my home LAN, I was just >curios about (theoretical) reliability knowing it used UDP. To give you a perspective: Lots of people run mission critical stuff over NFS and have done so for years. Companies like Netapp make US$ 500,000 boxes that are NFS servers. Yet you're worried that at the slightest blip NFS will corrupt your files? Well, not very likely I'd say Mike. -- "dselect has a user interface which scares small children" -- Theodore Tso, on debian-devel
Re: NFS alternative
On Tue, Jul 17, 2001 at 04:05:10PM +1000, Brian May uttered: > Well, in theory, all UDP packets could be numbered, much like TCP > packets, and you get exactly the same reliability TCP offers. This I doubt that. UDP isn't a connection oriented protocol, and as such, it can't deal with a packet out of order. -- Steve "I'm a sysadmin because I couldn't beat a blind monkey in a coding contest." --Me pgpFDlbypK2z7.pgp Description: PGP signature
Re: NFS alternative
> "D-Man" == D-Man <[EMAIL PROTECTED]> writes: D-Man> Interesting ... from my understanding UDP is a D-Man> connectionless protocol, and as such packets aren't D-Man> guaranteed to arrive at the destination. It seems to me D-Man> that for a file system, you really want all the packets to D-Man> arrive. How is this not a problem? (BTW, I'm just Well, in theory, all UDP packets could be numbered, much like TCP packets, and you get exactly the same reliability TCP offers. This effectively means you are tunnelling a connection based protocol over a connectionless based protocol (in much the same way TCP uses IP). You might be able to do this with less overhead then TCP, but personally I would just use TCP, as that way, other people are responsible for the tedious tasks of congestion control, etc). I have heard though, that NFS uses RPC, and RPC doesn't do anything this sophisticated. Rather, if the server doesn't respond in time, the client sends the request again. This is OK for requests like "read file", which don't affect the state of the server, as the worst thing that could happen is that the server will reread the file again. For other requests though, like "delete file", confusion could occur. eg. consider the case where the client wants to delete file X, and the file gets deleted, but the response is lost. The client resends the request again, and the server processes that request again, but this time says "file not found" because it no longer exists (it has no way of knowing that this was the same request it just received). The client gets totally confused, because it as far as it was concerned, the file did exist. Could be more serious, I imagine for "append file" operations, where you could get the data appended twice... I once read a book that said care needs to be taken with any RPC call that alters the state of the server, for this reason, but from what I have heard, NFS doesn't care. Conclusion: (if my sources are correct) never use NFS (unless mounted read-only) over a congested network... -- Brian May <[EMAIL PROTECTED]>
Re: NFS alternative
Thankfully, I forget the details[0]. From experience, no, it won't be exactly hosed: you'll end up with a .nfs004950384672385721380937 file that will grow and eventually fill up the partition... nothing an rm -rf / won't fix. And then there's negative cookies and stale mounts that require a reboot on most unices I've seen... you had to remind me, didn't you? from my own limited experience, stale mounts are not a problem if you can unmount then mount again the partition containing the "damaged" export. Note that mount -o remount doesnt do the trick, but umount then mount does it. That's why i keep nfs mounts on separate partition. (i have 4 X kernel-over-ftfp and root-over-nfs boxen that users can start and restart at will without proper shutdown, and a reboot each time a stale mount occured started to get on my nerves.)
Re: NFS alternative
On Mon, Jul 16, 2001 at 12:13:10PM -0700, Francois Gouget wrote: | On Mon, 16 Jul 2001, D-Man wrote: | > On Mon, Jul 16, 2001 at 12:45:22PM -0500, Dimitri Maziuk wrote: | > | * D-Man ([EMAIL PROTECTED]) spake thusly: | > | ... | > | > Ok, that makes sense. How about if probability leaves us behind | > | > and a packet is lost? Does NFS provide any way to correct for | > | > that or will your filesystem be hosed? | > | | > | Thankfully, I forget the details[0]. From experience, no, it won't | > | be exactly hosed: you'll end up with a .nfs004950384672385721380937 | > | file that will grow and eventually fill up the partition... nothing | > | an rm -rf / won't fix. And then there's negative cookies and stale | > | mounts that require a reboot on most unices I've seen... | > | > Ok. It sounds like it would still result in data loss :-(. | |Hmm, I'm not an NFS expert but I'll play one on the mailing-list for | you ;-) Please, if there are experts out there, correct me if I'm wrong. Everyone's an expert on the internet :-). |AFAIU, NFS has its own mechanism to recover from lost packets. So it | won't be a problem if a packet is lost. Similarly I believe NFS RPCs That's nice to know. | cannot span UDP packets, so there is no chance that a lost packet would | change the meaning of an RPC. The RPC will be lost, pure and simple, and | NFS will have to reissue it or something similar. So I don't think | packet loss is an issue. Good. |What NFS is 'lacking' is congestion control, as in the TCP slow star | and exponential back-off. This means NFS will blast UDP packets as fast | as it cans with no regard for other trafic. This is not really an issue | on a lan and actually had a performance at a time (I think). But if you | go over multiple links, then you may saturate a slower link, causing the | router that is just before it to start dropping packets. Especially if | multiple streams converge there. And once you start dropping packets | performance degrades very significantly. I believe that's why NFS is bad | if there are multiple hops (I get it from a very reliable source that | this is also why it's very bad if the traffic will go over ATM, you need | buffering/traffic shaping). Ok, yeah. I'm not worried about congestion on my home LAN, I was just curios about (theoretical) reliability knowing it used UDP. Thanks for that info! -D
Re: diskless terms and NFS/alternatives (was Re: NFS alternative)
* D-Man ([EMAIL PROTECTED]) spake thusly: > On Mon, Jul 16, 2001 at 01:43:34PM -0500, Dimitri Maziuk wrote: ... > | There are other networked file systems out there, like Coda, more modern > | and arguably better than NFS. If you only need to support linux, why not > | use one of them? Or [e]nbd? > > They're both going to be Debian. Can I use root-over-$FS for those > filesystems? Are they stable? No idea to both. You shouldn't have any problems with NFS, other than when network/server goes titsup. I expect any network file system will have a problem with that. [e]nbd is not a filesystem, it's a raw block device exported via network ([Enhanced] Network Block Device). IIRC someone was going to package nbd for Debian, no idea about the status of that, either. Dima -- E-mail dmaziuk at bmrb dot wisc dot edu (@work) or at crosswinds dot net (@home) http://www.bmrb.wisc.edu/descript/gpgkey.dmaziuk.ascii -- GnuPG 1.0.4 public key I'm going to exit now since you don't want me to replace the printcap. If you change your mind later, run -- magicfilter config script
Re: NFS alternative
On Mon, 16 Jul 2001, D-Man wrote: > On Mon, Jul 16, 2001 at 12:45:22PM -0500, Dimitri Maziuk wrote: > | * D-Man ([EMAIL PROTECTED]) spake thusly: > | ... > | > Ok, that makes sense. How about if probability leaves us behind > | > and a packet is lost? Does NFS provide any way to correct for > | > that or will your filesystem be hosed? > | > | Thankfully, I forget the details[0]. From experience, no, it won't > | be exactly hosed: you'll end up with a .nfs004950384672385721380937 > | file that will grow and eventually fill up the partition... nothing > | an rm -rf / won't fix. And then there's negative cookies and stale > | mounts that require a reboot on most unices I've seen... > > Ok. It sounds like it would still result in data loss :-(. Hmm, I'm not an NFS expert but I'll play one on the mailing-list for you ;-) Please, if there are experts out there, correct me if I'm wrong. AFAIU, NFS has its own mechanism to recover from lost packets. So it won't be a problem if a packet is lost. Similarly I believe NFS RPCs cannot span UDP packets, so there is no chance that a lost packet would change the meaning of an RPC. The RPC will be lost, pure and simple, and NFS will have to reissue it or something similar. So I don't think packet loss is an issue. What NFS is 'lacking' is congestion control, as in the TCP slow star and exponential back-off. This means NFS will blast UDP packets as fast as it cans with no regard for other trafic. This is not really an issue on a lan and actually had a performance at a time (I think). But if you go over multiple links, then you may saturate a slower link, causing the router that is just before it to start dropping packets. Especially if multiple streams converge there. And once you start dropping packets performance degrades very significantly. I believe that's why NFS is bad if there are multiple hops (I get it from a very reliable source that this is also why it's very bad if the traffic will go over ATM, you need buffering/traffic shaping). -- Francois Gouget [EMAIL PROTECTED]http://fgouget.free.fr/ Any sufficiently advanced bug is indistinguishable from a feature. -- from some indian guy
diskless terms and NFS/alternatives (was Re: NFS alternative)
On Mon, Jul 16, 2001 at 01:43:34PM -0500, Dimitri Maziuk wrote: | * D-Man ([EMAIL PROTECTED]) spake thusly: | ... | > | > Now suppose just the right packets are lost and the RPC call ends up | > matching a different, existant, procedure that doesn't have the | > intended effect ... sounds like it would be a good idea to | > make NFS over TCP stable :-). | | Well, RPC has its own error correction so if a right packet is | lost it will be re-transmitted. Or RPC call will time out and | return error (d'oh! remote RPC call. Automated ATM machine). | The difference is that this is handled by application-level (if | you consider RPC to be in application layer) code, not by transport | layer. | | I imagine implementing NFS over TCP would involve a re-design of | RPC state machine and a serious re-write of all related code, and | it ain't exactly broken as it is, so... (given all the things that | could [theoretically] go wrong with NFS, it is surprisingly stable). Hmm, yeah, I guess that could be hard, unless the RPC mechanism could use TCP. Or maybe a different RPC implementation could be used that would work over TCP. Or maybe it isn't really a problem in practice but just in theory. | > Can I use NFS-root-over-TCP for one of the boxes (I'll have 2, the | > other I'll leave at "regular" UDP as a "control" system)? | | There are other networked file systems out there, like Coda, more modern | and arguably better than NFS. If you only need to support linux, why not | use one of them? Or [e]nbd? They're both going to be Debian. Can I use root-over-$FS for those filesystems? Are they stable? -D
Re: NFS alternative
* D-Man ([EMAIL PROTECTED]) spake thusly: ... > > Now suppose just the right packets are lost and the RPC call ends up > matching a different, existant, procedure that doesn't have the > intended effect ... sounds like it would be a good idea to > make NFS over TCP stable :-). Well, RPC has its own error correction so if a right packet is lost it will be re-transmitted. Or RPC call will time out and return error (d'oh! remote RPC call. Automated ATM machine). The difference is that this is handled by application-level (if you consider RPC to be in application layer) code, not by transport layer. I imagine implementing NFS over TCP would involve a re-design of RPC state machine and a serious re-write of all related code, and it ain't exactly broken as it is, so... (given all the things that could [theoretically] go wrong with NFS, it is surprisingly stable). > Can I use NFS-root-over-TCP for one of the boxes (I'll have 2, the > other I'll leave at "regular" UDP as a "control" system)? There are other networked file systems out there, like Coda, more modern and arguably better than NFS. If you only need to support linux, why not use one of them? Or [e]nbd? Dima -- E-mail dmaziuk at bmrb dot wisc dot edu (@work) or at crosswinds dot net (@home) http://www.bmrb.wisc.edu/descript/gpgkey.dmaziuk.ascii -- GnuPG 1.0.4 public key I'm going to exit now since you don't want me to replace the printcap. If you change your mind later, run -- magicfilter config script
Re: NFS alternative
On Mon, Jul 16, 2001 at 12:45:22PM -0500, Dimitri Maziuk wrote: | * D-Man ([EMAIL PROTECTED]) spake thusly: | ... | > Ok, that makes sense. How about if probability leaves us behind | > and a packet is lost? Does NFS provide any way to correct for | > that or will your filesystem be hosed? | | Thankfully, I forget the details[0]. From experience, no, it won't | be exactly hosed: you'll end up with a .nfs004950384672385721380937 | file that will grow and eventually fill up the partition... nothing | an rm -rf / won't fix. And then there's negative cookies and stale | mounts that require a reboot on most unices I've seen... Ok. It sounds like it would still result in data loss :-(. | you had to remind me, didn't you? Yes. Sorry. ;-) | [0] it's built on top of RPC, so whatever error-correction mechanism | RPC uses should apply. Plus, NFS does its own caching and stuff... | IIRC. Ok, I think I have a better understanding now. I'm going to be building a couple of diskless xterms soon so I'll get a bunch of experience then. Now suppose just the right packets are lost and the RPC call ends up matching a different, existant, procedure that doesn't have the intended effect ... sounds like it would be a good idea to make NFS over TCP stable :-). Can I use NFS-root-over-TCP for one of the boxes (I'll have 2, the other I'll leave at "regular" UDP as a "control" system)? -D
Re: NFS alternative
* D-Man ([EMAIL PROTECTED]) spake thusly: ... > Ok, that makes sense. How about if probability leaves us behind and a > packet is lost? Does NFS provide any way to correct for that or will > your filesystem be hosed? Thankfully, I forget the details[0]. From experience, no, it won't be exactly hosed: you'll end up with a .nfs004950384672385721380937 file that will grow and eventually fill up the partition... nothing an rm -rf / won't fix. And then there's negative cookies and stale mounts that require a reboot on most unices I've seen... you had to remind me, didn't you? [0] it's built on top of RPC, so whatever error-correction mechanism RPC uses should apply. Plus, NFS does its own caching and stuff... IIRC. Dima -- E-mail dmaziuk at bmrb dot wisc dot edu (@work) or at crosswinds dot net (@home) http://www.bmrb.wisc.edu/descript/gpgkey.dmaziuk.ascii -- GnuPG 1.0.4 public key I'm going to exit now since you don't want me to replace the printcap. If you change your mind later, run -- magicfilter config script
Re: NFS alternative
On Mon, Jul 16, 2001 at 11:44:54AM -0500, Dimitri Maziuk wrote: | * D-Man ([EMAIL PROTECTED]) spake thusly: | ... | > Interesting ... from my understanding UDP is a connectionless | > protocol, and as such packets aren't guaranteed to arrive at the | > destination. It seems to me that for a file system, you really want | > all the packets to arrive. How is this not a problem? (BTW, I'm just | > beginning in networking programming and have no NFS experience yet, | > but don't be afraid to give gory programming details :-)) | | IIRC the idea was that you don't want to use NFS over slow and unreliable | internet links anyway, you'll only use it on the LAN. Packet loss isn't | much of an issue there; OTGH, performance penalty caused by TCP overhead | is, esp. if you're trying to e.g. swap to an NFS drive. | | It's a reasonable trade-off, given that there were no gigahertz CPUs or | gigabit ethernets. With modern hardware it's the other way around: we'd | rather have reliable transport and a [usually negligible] TCP overhead. Ok, that makes sense. How about if probability leaves us behind and a packet is lost? Does NFS provide any way to correct for that or will your filesystem be hosed? -D
Re: NFS alternative
* D-Man ([EMAIL PROTECTED]) spake thusly: ... > Interesting ... from my understanding UDP is a connectionless > protocol, and as such packets aren't guaranteed to arrive at the > destination. It seems to me that for a file system, you really want > all the packets to arrive. How is this not a problem? (BTW, I'm just > beginning in networking programming and have no NFS experience yet, > but don't be afraid to give gory programming details :-)) IIRC the idea was that you don't want to use NFS over slow and unreliable internet links anyway, you'll only use it on the LAN. Packet loss isn't much of an issue there; OTGH, performance penalty caused by TCP overhead is, esp. if you're trying to e.g. swap to an NFS drive. It's a reasonable trade-off, given that there were no gigahertz CPUs or gigabit ethernets. With modern hardware it's the other way around: we'd rather have reliable transport and a [usually negligible] TCP overhead. Dima -- E-mail dmaziuk at bmrb dot wisc dot edu (@work) or at crosswinds dot net (@home) http://www.bmrb.wisc.edu/descript/gpgkey.dmaziuk.ascii -- GnuPG 1.0.4 public key Q276304 - Error Message: Your Password Must Be at Least 18770 Characters and Cannot Repeat Any of Your Previous 30689 Passwords-- RISKS 21.37
Re: NFS alternative
On Mon, Jul 16, 2001 at 03:56:02PM +1000, Brian May wrote: | > "Jeremy" == Jeremy Gaddis <[EMAIL PROTECTED]> writes: | | Jeremy> Two possible suggestions: - tunnel the NFS traffic over an | Jeremy> SSH traffic (similar to remote X sessions) | | Can you use SSH to tunnel UDP traffic??? | | (I didn't think it was possible, and last I heard, NFS over TCP was | still very experimental) Interesting ... from my understanding UDP is a connectionless protocol, and as such packets aren't guaranteed to arrive at the destination. It seems to me that for a file system, you really want all the packets to arrive. How is this not a problem? (BTW, I'm just beginning in networking programming and have no NFS experience yet, but don't be afraid to give gory programming details :-)) -D
Re: NFS alternative
"Timo \\" Blazko\ " Boewing" <[EMAIL PROTECTED]> writes: > My question: is there a distributed fs that combines the advantages of > both techs? > as there are: > NFS: mountable (more via combining with other things?) > SCP: quite secure, may compress and crypt data Have a look at sfs (http://www.fs.net/) -- there is even a Debian package in unstable since a week or so. Greetings, joachim
Re: NFS alternative
In article <[EMAIL PROTECTED]>, Timo \"Blazko\" Boewing <[EMAIL PROTECTED]> wrote: >Currently, I am using ssh/scp and NFS for syncing data between my woody >desk and my FreeBSD thing. >My question: is there a distributed fs that combines the advantages of >both techs? A google search for "crypto filesystem linux" quickly turned up http://www.tcfs.it/ a crypto network filesystem for Linux and BSD There are several similar projects. Mike. -- "dselect has a user interface which scares small children" -- Theodore Tso, on debian-devel
Re: NFS alternative
> "Jeremy" == Jeremy Gaddis <[EMAIL PROTECTED]> writes: Jeremy> Two possible suggestions: - tunnel the NFS traffic over an Jeremy> SSH traffic (similar to remote X sessions) Can you use SSH to tunnel UDP traffic??? (I didn't think it was possible, and last I heard, NFS over TCP was still very experimental) -- Brian May <[EMAIL PROTECTED]>
RE: NFS alternative
Two possible suggestions: - tunnel the NFS traffic over an SSH traffic (similar to remote X sessions) - or set up a VPN j. -- Jeremy L. Gaddis <[EMAIL PROTECTED]> -Original Message- From: "Timo \"Blazko\" Boewing" [mailto:[EMAIL PROTECTED] Sent: Sunday, July 15, 2001 9:34 PM To: debian-user@lists.debian.org Subject: NFS alternative Hello everyone! Currently, I am using ssh/scp and NFS for syncing data between my woody desk and my FreeBSD thing. My question: is there a distributed fs that combines the advantages of both techs? as there are: NFS: mountable (more via combining with other things?) SCP: quite secure, may compress and crypt data What I want to have is a sys that allows me to mount a remote fs but having data compression and encryption enabled. --> Any ideas how to give NFS the features scp has (tunneling?) ? --> Any comments on or ideas for existing alternatives (heard something of CodaFS etc.) Thanx for a future discussion, greetz, Timo -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
