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

Software-based VM-centric and flash-friendly VM storage + free version

Moderators: anton (staff), art (staff), Max (staff), Anatoly (staff)

User avatar
anton (staff)
Site Admin
Posts: 4008
Joined: Fri Jun 18, 2004 12:03 am
Location: British Virgin Islands
Contact:

Sat Nov 07, 2020 1:09 pm

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"?
wallewek wrote: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
Regards,
Anton Kolomyeytsev

Chief Technology Officer & Chief Architect, StarWind Software

Image
wallewek
Posts: 114
Joined: Wed Sep 20, 2017 9:13 pm

Sat Nov 07, 2020 6:19 pm

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
------------------------
"In theory, theory and practice are the same, but in practice they're not." -- Yogi Berra
User avatar
anton (staff)
Site Admin
Posts: 4008
Joined: Fri Jun 18, 2004 12:03 am
Location: British Virgin Islands
Contact:

Tue Nov 10, 2020 11:22 am

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.
wallewek wrote: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
Regards,
Anton Kolomyeytsev

Chief Technology Officer & Chief Architect, StarWind Software

Image
Post Reply