• Some users have recently had their accounts hijacked. It seems that the now defunct EVGA forums might have compromised your password there and seems many are using the same PW here. We would suggest you UPDATE YOUR PASSWORD and TURN ON 2FA for your account here to further secure it. None of the compromised accounts had 2FA turned on.
    Once you have enabled 2FA, your account will be updated soon to show a badge, letting other members know that you use 2FA to protect your account. This should be beneficial for everyone that uses FSFT.

SAN and NAS ?

A SAN is a block-level device, like a hard drive. Your computer (not the server) is what dictates what format the data is stored in. Its primary advantage is speed.

NAS devices export a "share" over a protocol like SMB or CIFS or NFS or even FTP. This is a file-level storage facility. When you save a file to the share, a file is created on the remote filesystem. In this case, the server does all the filesystem stuff. The advantage here is generally cost of implementation and flexibility.

 
For typical usage, these are complementary, not competitive technologies (although vendor packaging / marketing can make this more confusing).

What I mean is that for typical multi-user usage, you want to export a NAS interface to your clients. Whether or not the underlying storage system is a SAN is an internal implementation detail from the point of view of the NAS clients.

Of course, specialized high-performance usage would be a different usage context.
 
so if Im understanding correctly, sharing folders from a central server and working off of them from a different machine(s) would make the server machine into a NAS. Correct?

Personally Im still fuzzy on what a SAN is.
 
GLSauron said:
so if Im understanding correctly, sharing folders from a central server and working off of them from a different machine(s) would make the server machine into a NAS. Correct?

Personally Im still fuzzy on what a SAN is.
Correct. A SAN would be a device that connects over something like FC or iSCSI and provides a block device to the OS rather than a network drive. Thus, you don't have the option of partitioning a NAS device, but you do have the option of partitioning a SAN. SAN devices act like a large hard drive.

 
Would the following be a valid SAN scenario?

Client A connected to SAN "sharing" server B requesting file yy. File yy consists of three blocks on three different SAN disks: l,m and n. Server B tells l,m and n to send the data directly to A, who has a SAN 'driver' installed without B ever touching the blocks.
 
so the SAN just shows and acts like a drive in and of itself.
makes more sense now.
 
drizzt81 said:
Would the following be a valid SAN scenario?

Client A connected to SAN "sharing" server B requesting file yy. File yy consists of three blocks on three different SAN disks: l,m and n. Server B tells l,m and n to send the data directly to A, who has a SAN 'driver' installed without B ever touching the blocks.
It's more like this. You have two boxes (or sets of boxes): SAN backends and NAS front ends, S and N for short. A client requests \\N\share\filename over SMB, so N asks S for blocks from disk, processes them as part of a filesystem, and sends back the contents of share\filename.

In other words, in your scenario, B does touch the blocks, and may do complex things with them - they may actually be part of a raid 5 array, or encrypted, or compressed - but this is transparent to A. It just reads blocks from disk like B is a hard drive.

HTH

 
Back
Top