<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
<HTML><HEAD>
<META http-equiv=Content-Type content="text/html; charset=us-ascii">
<META content="MSHTML 6.00.2900.3640" name=GENERATOR></HEAD>
<BODY>
<DIV dir=ltr align=left><FONT face=Arial color=#0000ff
size=2></FONT> </DIV><BR>
<DIV class=OutlookMessageHeader lang=en-us dir=ltr align=left>
<HR tabIndex=-1>
<FONT face=Tahoma size=2><B>From:</B> centos-bounces@centos.org
[mailto:centos-bounces@centos.org] <B>On Behalf Of </B>Rudi
Ahlers<BR><B>Sent:</B> Friday, January 29, 2010 12:23 AM<BR><B>To:</B> CentOS
mailing list<BR><B>Subject:</B> Re: [CentOS] NFS vs SMb vs iSCSI for remote
backup mounts<BR></FONT><BR></DIV>
<DIV></DIV><BR><BR>
<DIV class=gmail_quote>On Fri, Jan 29, 2010 at 1:18 AM, nate <SPAN
dir=ltr><<A
href="mailto:centos@linuxpowered.net">centos@linuxpowered.net</A>></SPAN>
wrote:<BR>
<BLOCKQUOTE class=gmail_quote
style="PADDING-LEFT: 1ex; MARGIN: 0px 0px 0px 0.8ex; BORDER-LEFT: #ccc 1px solid">
<DIV class=im>Rudi Ahlers wrote:<BR><BR>> nate, why not? Is it simply
unavoidable at all costs to mount on system on<BR>> another, over a WAN?
That's all I really want todo<BR><BR></DIV>If what you have now works, stick
with it.. in general network<BR>file systems are very latency
sensitive.<BR><BR>CIFS might work best *if* your using a WAN optimization
appliance,<BR>I'm not sure how much support NFS gets from those
vendors.<BR><BR>iSCSI certainly is the worst, block devices are very
intolerant of<BR>latency.<BR><BR>AFS may be another option though quite a bit
more complicated, as<BR>far as I know it's a layer on top of an existing file
system that<BR>is used for things like replication<BR><BR><A
href="http://www.openafs.org/"
target=_blank>http://www.openafs.org/</A><BR><BR>I have no experience with it
myself.<BR>
<DIV>
<DIV
class=h5><BR>nate<BR><BR><BR>_______________________________________________<BR>CentOS
mailing list<BR><A href="mailto:CentOS@centos.org">CentOS@centos.org</A><BR><A
href="http://lists.centos.org/mailman/listinfo/centos"
target=_blank>http://lists.centos.org/mailman/listinfo/centos</A><BR></DIV></DIV></BLOCKQUOTE></DIV>
<DIV><BR></DIV>
<DIV><BR></DIV>
<DIV>Thanx nate, this is what I wanted to hear :)<BR></DIV>
<DIV><BR></DIV>
<DIV>So, is there any benefit in using NFS over SMB in this case?<SPAN
class=117583612-29012010><FONT face=Arial color=#0000ff
size=2> </FONT></SPAN></DIV>
<DIV><SPAN class=117583612-29012010></SPAN> </DIV>
<DIV><SPAN class=117583612-29012010><FONT face=Arial color=#0000ff
size=2></FONT></SPAN> </DIV>
<DIV><SPAN class=117583612-29012010><FONT face=Arial color=#0000ff size=2>Can't
speak for NFS(3/4), but i can tell you that that smb-protocol combined with high
latency is a recepy for disaster.</FONT></SPAN></DIV>
<DIV><SPAN class=117583612-29012010><FONT face=Arial color=#0000ff size=2>We
tried it from europe to the carribean (both sat or fibre) but users spent their
time more complaining then working.</FONT></SPAN></DIV>
<DIV><SPAN class=117583612-29012010><FONT face=Arial color=#0000ff size=2>Needed
horrible expensive lan-optimesers at both end</FONT></SPAN></DIV>
<DIV><SPAN class=117583612-29012010><FONT face=Arial color=#0000ff
size=2></FONT></SPAN> </DIV>
<DIV><SPAN class=117583612-29012010><FONT face=Arial color=#0000ff size=2>So
perhaps nfs4 or afs (later is intended for geographically separated machines,
afaicr)</FONT></SPAN></DIV>
<DIV><SPAN class=117583612-29012010><FONT face=Arial color=#0000ff size=2>but
certainly not smb!</FONT></SPAN></DIV>
<HR>Dit bericht kan informatie bevatten die niet voor u is bestemd. Indien u niet de geadresseerde bent of dit bericht abusievelijk aan u is toegezonden, wordt u verzocht dat aan de afzender te melden en het bericht te verwijderen. De Staat aanvaardt geen aansprakelijkheid voor schade, van welke aard ook, die verband houdt met risico's verbonden aan het elektronisch verzenden van berichten.<BR>
<BR>
This message may contain information that is not intended for you. If you are not the addressee or if this message was sent to you by mistake, you are requested to inform the sender and delete the message. The State accepts no liability for damage of any kind resulting from the risks inherent in the electronic transmission of messages.<BR>
</BODY></HTML>