[lsb-discuss] statfs specification addition: review
tytso at mit.edu
Thu Dec 28 14:41:49 PST 2006
On Wed, Dec 27, 2006 at 08:40:51AM +0000, Anthony W. Youngman wrote:
> Note that I am aware of at least one application (IBM UniVerse) where
> the distinction between local and remote filesystems is CRUCIAL. I'm
> sure others can think of more.
> It's a database, it stores each "table" in its own OS-level file, and
> for integrity reasons it *needs* to know whether the files exist
> physically on the local or remote machine. For data integrity reasons,
> by default it will refuse to write to a remote file, instead passing a
> request to the server daemon running on the remote machine.
What do you mean by "data integrity reasons"? Do you mean accidental
data corruption? Depending on the remote filesystem involved, and the
quality of your local disk, the remote filesystem might actually be
more robust (modern remote filesystem use aggressive checksumming;
some even use encryption and message authentication codes to assure
that the data can't be tampered with on the network).
NFSv2 with checksumming disabled might be vulnerable to "data
integrity issues", but PC class machines on pre-UDMA hard drives had
no integrity checks (not even parity!) on hard drive accesses.
A badly configured iSCSI disk that has no checksum protection and
mounted as "a local filesystem" can be far less reliable by an NFSv4
filesystem with checksumming enabled to a reliable dedicated
What concerns me about people who say that "they want to know about
about local versus remote filesystems" is that invariably they are
asking the wrong question. There is this assumption that NFS will
always be less secure/able to detect data corruption/fast/whatever,
and very often that is just plain WRONG.
More information about the lsb-discuss