Server Fault is a question and answer site for system and network administrators. Join them; it only takes a minute:

Sign up
Here's how it works:
  1. Anybody can ask a question
  2. Anybody can answer
  3. The best answers are voted up and rise to the top

Can these storage devices be accessed like normal hard drives or applications specifically target a device? The applications you guys use against these devices, do you have tell your application what they are connected to?

I mean if I have an application X. Would X work only for SAN storage or NAS storage or it doesn't matter what is the target storage device because they are all accessed as normal hard drives or network shares?

Do I as an application developer have to care what storage device my customer would be using?

share|improve this question
up vote 4 down vote accepted

These storage devices are fully transparent for applications (Applications don't care if you are using local storage or network).

You have to worry about what storage device your customer would be using only if you develop some sort of management/configuration software (which has to deal with particular storage devices and thus hardware dependent).

share|improve this answer

Don't think of it so much NAS vs. SAN, think more along the lines of file-level vs. block-level.

Some apps NEED block-level access to data, usually databases do, plus anything that assumes it has exclusive access to the disk such as MS Clustering & VMWare ESX. Often web apps don't need this level of access and are happy with purely file-level access - but it's worth knowing that anything that's happy with file-level is almost always sure to work fine with block-level too. It's this requirement that defines your access type, block-level=Fibre-Channel & iSCSI, file-level=CIFS/SMB, HTTP, & NFS (plus one or two others).

Now onto the second requirement - speed. File-level boxes usually talk via 1Gbps Ethernet (often using multiple ports) with newer, more expensive boxes offering 10Gbps ports. Block-level boxes almost always support 1Gbps and/or 1/2/4Gbps Fibre-Channel with 10Gbps and/or 8/10Gbps becoming more prevalent - they are also generally designed for higher performance under high load than file-level boxes, so take that into consideration.

As a general ruleset; if cost is the issue you may be forced to use a file-level 1Gbps NAS box, if performance is the issue then you may need to go with a top-end block-level FC SAN - if you're looking for bang-for-the-buck you have a wealth of options but may end up focussing on top-end file-level 10Gbps NAS boxes or lower-end block-level 4/8Gbps SAN boxes.

Hope this helps.

share|improve this answer

It depends...

NAS storage is typically accessed at the file level, ie as a shared CIFS (Windows) or NFS drive. SAN storage it typically accessed at a block level, so it looks more like DAS - direct attached storage.

But tons of storage devices (NetApp is the first that comes to mind) allow the storage to be accessed either way, or both.

The usual rule of thumb is that you want a SAN for high-performance block access, e.g. a database that sees lots of access.

share|improve this answer

If you need to share storage over more than one server, than NAS is generally used, as access is generally using NFS and CIFS protocols.

If you can dedicate the disk area to one specific host, then in general SAN storage is used. The interface between the host and the SAN looks like SCSI.

share|improve this answer
Well, yes and no. To make things even more confusing, clustered environments may just as well have it's shared storage on a SAN. Also, the most popular NAS solutions have multiple nodes acessing the actual storage on a shared SAN. – Roy Oct 12 '09 at 5:40

There are a number of differences between how traditional NAS and SAN storage technologies are typically applied. However, new devices can often be connected either way and many of the differences has been washed away with the introduction of iSCSI - which is essentially network attached SAN.

share|improve this answer

Your Answer


By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.