[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Discouraging :local:

From: Greg A. Woods
Subject: Re: Discouraging :local:
Date: Mon, 27 Jan 2003 18:20:42 -0500 (EST)

[ On Monday, January 27, 2003 at 02:48:59 (-0800), Kenneth Porter wrote: ]
> Subject: Re: Discouraging :local:
> --On Saturday, January 25, 2003 2:42 PM -0500 "Greg A. Woods" 
> <address@hidden> wrote:
> > The latter, the sharing part, is where the real trouble begins.
> > Ensuring reliable order of operations for various operations which would
> > be "atomic" on a local filesystem is very very difficult (literally
> > impossible in some cases) for shared network filesystems.
> Do we include Samba in this? (I use Samba to host some PVCS archives and 
> haven't seen any archive corruption. All access is "local" because I'm 
> using the peer-to-peer PVCS stuff, not server stuff.)

Yes, I think so.  As far as I know samba has no locking protocol (I
don't think the underlying SMB protocol has locking either, but I may be

> Is Ethernet then unreliable? Isn't the data integrity handled at the 
> physical layer, with CRC's?

Well, generically speaking Ethernet's FCS field is a 32-bit CRC of the
whole data frame.  However if I understand the math correctly that means
that only 32-bit or shorter errors (remember Ethernet is serial) can be
detected reliabliy and "only" about 99.955% of error bursts longer than
32 bits can be detected.  Ethernet frames containing TCP or UDP IP
packets can be large -- up to ~1500 bytes.

The TCP and UDP data integrity checks are only a 16-bit checksum, and
while they might catch errors that the Ethernet FCS doesn't, they also
might not.

SCSI bus parity checks are a little more reliable and predictable (not
to mention that the SCSI bus electrical characteristics are a whole lot
different too, thus changing the nature of the possible errors).

                                                                Greg A. Woods

+1 416 218-0098;            <address@hidden>;           <address@hidden>
Planix, Inc. <address@hidden>; VE3TCP; Secrets of the Weird <address@hidden>

reply via email to

[Prev in Thread] Current Thread [Next in Thread]