How much speed differes between block level and file level access

[senthil_kumar_1]

Hi All,

I am new to SAN and NAS.

My Questions:

1)Which is fater file level and block level?

2)Which is preferable for which environment, could you please give some example?

3)What is the speed of file level and block level , how to view / calculate?

[Uwe Zessin]

1: There is no universal rule. A simple block read/write has less overhead, but an old SAN device can be slower than a more modern NAS device.

2: File level (NAS) is usually used when data files need to be shared by many clients (e.g. desktop PCs or CAD workstations).
It is also possible to share file systems via block-level access, but then all meta-data changes need to be communicated between the clients.

3: Don't try to think in such absolute ways. I've run block-level and file services through 10, 100 and 1,000 MegaBit Ethernet, but that was only the *bandwidth* of the transport medium. Storage performance depends on many more factors and cannot be put into a simple formula.

[senthil_kumar_1]

Could any one of you clarify me more?

[Kranti Mahmud · Accepted solution]

Hi Senthil,

Check the below links first:

http://www.nas-san.com/differ.html

http://compnetworking.about.com/od/networkstorage/f/san-vs-nas.htm

http://www.comnews.com/stories/articles/0804/0804coverstory.htm

Rgds-Kranti

[Kranti Mahmud]

Hi Senthil,

Cloning an entire hard drive to another drive can be achieved in two ways: 1) Copying every file individually from one volume to the other or 2) Copying the underlying blocks from one hard drive to the other. These two methods are called "file-level copying" and "block-level copying", respectively. While each method produces functionally the same result, block-level copying is almost always faster than file-level copying.

To benefit from a block-level copy, the following criteria must be met:
You must choose to "Delete items from the target that don't exist on the source" during the clone.
You must be able to unmount both devices (there cannot be any open files on either drive and you cannot be booted from either drive). Do not actually unmount the drives prior to the clone.
The target drive must be at least as large as the source drive.

If any of these criteria are not met, CCC will automatically fall back to a file-level clone. A file-level clone will yield the same result -- a bootable clone, but it will take a little longer.

While a block-level clone is rarely required to insure the fidelity of your backup, some people find comfort in the fact that, block-for-block, the resulting target is precisely like the original (this is simply impossible with a file-level clone). Don't lose sleep, though, if meeting the requirements for a block-level clone is untenable for your particular backup or cloning situation. The file-level backup engine in CCC has been tuned and honed to bring the best performance and fidelity possible among Mac OS X backup utilities.

Rgds-Kranti

[Kranti Mahmud]

Hi Senthil,

A block-level interface (between a 'host' system and storage) views the
storage as a linear range of equal-sized 'disk blocks': the host asks the
storage to read or write one or more consecutive blocks per request.
Traditional storage maps these blocks linearly to the actual disk blocks (or
perhaps 'stripes' them across multiple disks with a simple algorithm);
'virtualized' storage may map the storage blocks seen by the host
arbitrarily to disk locations, even across multiple storage boxes.

A file-level interface (between a 'client' system and a 'file server') views
the storage as a group of files, organized into the traditional hierarchical
structure by directories. Aside from maintenance operations (open, close,
list directory, etc.), the client asks the server to read or write a
consecutive range of bytes within a particular file in each request, and the
server maps this request to its storage much like a client system maps local
requests to its local storage.

With a block-level interface, you need to use a 'SAN file system' (or a
similarly-integrated database mechanism such as Oracle Parallel Server) on
the hosts if multiple hosts want to share the same files on the storage,
because the host/storage interface is too low-level to be aware of the
file-level coordination required and the hosts must thus communicate among
themselves to provide it (if no portion of the storage is shared among
multiple hosts, they all can just treat their portion like a local disk,
with no inter-host coordination required). With a file-level interface,
that coordination can take place on the server (very much like access
coordination on a stand-alone system between applications that access a
single file concurrently occurs); however, that precludes caching any data
locally on the clients, so high-performance NAS implementations extend the
interface to allow this and thus make it more complex, some even requiring
similar inter-host coordination to that required to share files on a
block-level SAN - and sophisticated NAS approaches can even map files across
multiple NAS servers.

Thus a simple SAN maps what appear to the host to be 'disk blocks' quite
directly to actual disk blocks at the storage, with little loss of bandwidth
or increase in latency over comparable local storage. A simple NAS just
exports client requests to a server where the requested file-level operation
is performed, incurring somewhat greater latency than would occur accessing
local storage (and possibly compromising bandwidth as well). But a simple
NAS allows easy file-sharing among multiple hosts, while a simple SAN does
not.


Rgds-Kranti