Trying to be clear on this - use iSCSI instead of SMB

[anton (staff)]

You can do that because in most modern operating systems storage stacks are "layer cake" of multiple drivers put on top of each other. On Windows Server example it's:

<physical device> := <StorPort + miniport | monolithic SCSI port>
<optional SCSI filters>
<block device> := <class driver>
<optional class driver filters>
<file system> := <file system driver>
(optional file system monolithic or minifilters>
<...>

How are you going to number these layers if at least half are optional and configuration specific? What value to the Universe you'll bring naming block device say "layer 2"?

Here's a thought.

Sometimes I think there should be layers for hardware storage definitions like there are for networks. E.g., layer 1 is hardware, layer 2 is hardware interface, layer 3 is storage structure (files, directories etc.), layer 4 is security and locking, sharing, and so on.

I'm not totally sure, but I think iSCSI is layer 2 or 3. It accesses storage at the logical block level, or maybe at the filesystem level. Which means no security, no locking.

I would probably say SMB is probably layer4 at least, as it supports pretty much full local file access semantics.

I'm not sure what layer you would put nfs at.

Feel free to correct me or disagree!

--- kenw

[wallewek]

Thank you very much for that very helpful response, Anton.

That does, I think, sort of confirm my impression that iSCSI connects to storage at a level close to hardware. It would be interesting to see how SMB/CIFS and nfs compare.

The problem for many people, I think, is that descriptions of the various network storage access protocols like iSCSI tend to be quite vague as to where they fit in the storage (as opposed to network) layer structure, and -- to me, at least -- that vagueness creates confusion. Like the question elsewhere here about using iSCSI for shared file access. As is often the case, people who work with such stuff routinely tend to forget what it was like for them at first. Not everyone can be an expert on storage drivers.

I agree that at least half of those file access components are optional and configuration specific. But many things in networks are also optional, and they still fit the structure. Think about the ARP protocol, for example. My suggestion for a starting point for numbering was "E.g., layer 1 is hardware, layer 2 is hardware interface, layer 3 is storage structure (files, directories etc.), layer 4 is security and locking, sharing, and so on."

Like I say, it was just an idea. Layers work well for network protocols. I wasn't sure if the concept could be adapted to storage. I'm still not. But I think it could be useful as a conceptual tool.

--- kenw

[anton (staff)]

SMB/CIFS called "network redirector" within Microsoft terminology for a reason: it's just a local application "talking" to file system via file system local APIs and it has network layer "injected" in between it and a remote client.
Block protocols and their way to deal with the hardware is implementation-specific, say StarWind in some configurations will deal with local files same way network redirector does. This means there's NO difference in between
how block and file protocols are "talking" to the local hardware. Which kind if breaks your idea and makes it irrelevant: You can't specify or number layers if any other vendor will have his own opinion on what to do.

Thank you very much for that very helpful response, Anton.

That does, I think, sort of confirm my impression that iSCSI connects to storage at a level close to hardware. It would be interesting to see how SMB/CIFS and nfs compare.

The problem for many people, I think, is that descriptions of the various network storage access protocols like iSCSI tend to be quite vague as to where they fit in the storage (as opposed to network) layer structure, and -- to me, at least -- that vagueness creates confusion. Like the question elsewhere here about using iSCSI for shared file access. As is often the case, people who work with such stuff routinely tend to forget what it was like for them at first. Not everyone can be an expert on storage drivers.

I agree that at least half of those file access components are optional and configuration specific. But many things in networks are also optional, and they still fit the structure. Think about the ARP protocol, for example. My suggestion for a starting point for numbering was "E.g., layer 1 is hardware, layer 2 is hardware interface, layer 3 is storage structure (files, directories etc.), layer 4 is security and locking, sharing, and so on."

Like I say, it was just an idea. Layers work well for network protocols. I wasn't sure if the concept could be adapted to storage. I'm still not. But I think it could be useful as a conceptual tool.

--- kenw