lkml.org 
[lkml]   [2005]   [Sep]   [2]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
SubjectRe: GFS, what's remaining
From
Date
I have to correct an error in perspective, or at least in the wording of 
it, in the following, because it affects how people see the big picture in
trying to decide how the filesystem types in question fit into the world:

>Shared storage can be more efficient than network file
>systems like NFS because the storage access is often more efficient
>than network access

The shared storage access _is_ network access. In most cases, it's a
fibre channel/FCP network. Nowadays, it's more and more common for it to
be a TCP/IP network just like the one folks use for NFS (but carrying
ISCSI instead of NFS). It's also been done with a handful of other
TCP/IP-based block storage protocols.

The reason the storage access is expected to be more efficient than the
NFS access is because the block access network protocols are supposed to
be more efficient than the file access network protocols.

In reality, I'm not sure there really is such a difference in efficiency
between the protocols. The demonstrated differences in efficiency, or at
least in speed, are due to other things that are different between a given
new shared block implementation and a given old shared file
implementation.

But there's another advantage to shared block over shared file that hasn't
been mentioned yet: some people find it easier to manage a pool of blocks
than a pool of filesystems.

>it is more reliable because it doesn't have a
>single point of failure in form of the NFS server.

This advantage isn't because it's shared (block) storage, but because it's
a distributed filesystem. There are shared storage filesystems (e.g. IBM
SANFS, ADIC StorNext) that have a centralized metadata or locking server
that makes them unreliable (or unscalable) in the same ways as an NFS
server.

--
Bryan Henderson IBM Almaden Research Center
San Jose CA Filesystems

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/

\
 
 \ /
  Last update: 2005-09-03 01:06    [W:0.440 / U:0.376 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site