I'm a developer...treading here on foreign terrain. Please pardon any naivete.

I work on an application that stores data both in a database and the filesystem.

Context: Clustering and Network Shares

In the past when we ran the application clustered (i.e. multiple application servers fronting the data), we have handled the filesystem as follows:

  • Node A : shares the "data directory " (via samba or nfs)
  • Nodes B,C,D, etc: mounts the "network share" and uses that at its "data directory"

Reduced "disk speed" for nodes B,C,D was suboptimal, but not a big problem.

Also note: The application uses its own file locking mechanism. Concurrent writes are not a problem.

The Questions

  • So in a modern data center fibre-channel connects servers to SANS, what's the best way to share a "hunk of disk" amongst several servers ?

  • Is such 'disk sharing' widely used?

  • Any OS-specific concerns ("works on linux, but not available on Windows")

  • Any caveats? Hard to configure, unreliable, etc?

I have heard a lot of "we can't do that" from our sysadmins ..which finally when I asked more details, they said "well, technically it's possible, but it's not how we do it here"

thanks in advance,

Update: Thanks for the answers. (They were all good: i had to pick one. Sorry if it wasn't yours) Just as I had (somewhat) expected: my hopes that you could simply attach NTFS or XFS or whatever "regular" filesystem to the same 'hunk of 'disk' proved naive. Clustered filesystem is the ticket. And fancy filesystems aren't on our hosting team's top priorities).

  • 1
    SANs make it easier to connect more than one server to a block device. However...that does not mean that you can simply connect a bunch of servers to an ext4 filesystem and expect things to work. That's not the case. If you have to have concurrent access, you need a cluster filesystem or you need to do something like you've done in the past with NFS.
    – EEAA
    Sep 24, 2014 at 20:24

3 Answers 3


"well, technically it's possible, but it's not how we do it here"

That sounds quite a lot like what I regularly tell developers ;)

From an enterprise operational perspective you want as much as possible that applications use standard repeatable solutions. If your application doesn't need/warrant special treatment you're not going to get it. Non-standard solutions require specialised skills, more expensive or simply more equipment and if it's "state-of-the-art" failures are often catastrophic as well.

For many applications a (highly available) file share is still a very suitable and commonly deployed solution.

Common HA alternate solutions to using a file-share are:

  • Do not store files on file-systems but use a highly available database and store them as BLOB's instead. A very common approach. Often you already need a database anyway and this makes application servers almost stateless, solves a lot of locking, replication, HA, consistency and access problems by shifting them to the database layer, where a lot of those problems are old news, well understood and solved. It can be expensive to maintain though once you reach (a sizeable fraction of) the petabyte range.

  • A proper clustered file-system, that allows concurrent read-write block-level access to your shared storage over Fiber Channel or iSCSI. Enterprise storage arrays tend to be pretty expensive but this can scale very well. Often the cluster file system requires (expensive) licensing for each node for the cluster FS software. Also quite common in enterprise environments for specialised applications.

  • Use a distributed object store. This is the more open source solution, with low-end commodity hardware, creating redundancy and scalability in the software. This is a common "cloud" approach.


If you're connecting several servers to a shared block device (DASD/SAN) you still need to either manually manage access to chunks of disk (some databases do that on raw disks, LVM is also an option, with managed LV access) or use a cluster file system, which will manage concurrent access.

Even with write locks managed on a per-file basis, you might run into FS corruption otherwise, if two hosts attempt to perform FS metadata changes at the same time, on a non-clustered FS. Nothing modern about it, BTW, SANs and concurrent block access have been around since the 80s (if not the 70s).

All modern OS have clustered FS implementations, and block chunk isolation is also possible if you're willing to write everything yourself, so it's very specific to what you intend to use.

EDIT: Your "old" network share approach is still quite feasible, and the file server will take care of file locks, so you don't need extra locking mechanisms. If you're not after extra performance and want a simple deployment, it's probably still the easiest route.

Now, if you want to talk "modern", start thinking about object storage and scale out architecture for your app.

  • +1 for object storage. Looks like that is the core of the question, i.e. scalable storage of irregular chunks of data. Sep 26, 2014 at 7:20

You need not just the shared hardware, but also a clustered filesystem.

Regular filesystems wont work - two computers would end up overwriting each others changes, and you would end up with a corrupt filesystem.

Clustered filesystems have the computers all notify each other about changes they are making, and handle locking files when needed so they don't step on each other's toes.

Some of those filesystems are application specific - VMware has VMFS for example, and Hyper-V has cluster shared volumes - they work great for storing virtual machines, but are not meant as general file storage. There are others that are designed to store any files. Each has various advantages and drawbacks, so which is best depends heavily on what you are doing with it. They are all (as far as I know) OS specific - you wont be able to share a filesystem between windows and linux this way.

For some things like high availability virtual machine failover you really need this. For applications where SMB or NFS will do, those are generally preferred - they may be slightly slower, but there are far fewer things that could go wrong, and easier to recover when they do break.

  • VM failover these days can be done using non-shared storage. Besides, clustered FS is not the only solution to shared block storage, in fact, systems like VMFS are severely hampered in scalability, unlike direct block access systems. This is why oVirt can have hundreds of hosts in a single cluster, and vsphere only 32 (last time I checked at least, it was only 32, with no more than 20 recommended)
    – dyasny
    Sep 24, 2014 at 20:43

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .