Re: how it works
thanks...yes, it helped :-) On Sunday, January 12, 2020 at 4:32:55 AM UTC+1, The Lee-Man wrote: > > On Jan 11, 2020, at 11:26 AM, Bobby > > wrote: > > > Hi , > > Thanks for your patience regarding my questions. Because after I had dug > (digged) very older posts, I realized > many of the older posts already had answers for many of my earlier > questions :). After your couple of answers and going > through old posts, I have a better understanding of *user land* and *kernel > land*. > > > Excellent. > > > Now one more point. > > *Kernel land: * > While we are at kernel land, I have a confusion on that. > AFAIK in linux kernel, the linux *block layer* is a glue that, on the one > hand, allows applications to access > diverse storage devices > in a uniform way, and on the other hand, > provides storage devices and drivers with a single point of entry from all > applications. > I mean this Linux OS (host) block layer is the most > critical part of the I/O hierarchy, as it orchestrates the I/O > requests from different applications to the underlying storage. > > *Question:* > So in context of *Open-iSCSI*, where does the user-land interacts the > block layer in the kernel land? I > mean, when it comes to kernel land, why we are considering only > *scsi_transport_iscsi.c* and *iscsi_tcp.c* codes? Shouldn't > the block request go through block layer? > > As always, thanks in advance :) > > > > The iscsi initiator (open-iscsi) acts as an HBA, in effect, in the block > system. > > The layer above the block layer (conceptually) are the disc or tape > drivers.The block layer presents an abstract interface to them, so that > they only have to deal with putting bits in blocks, or getting bits from > blocks. > > The layer below the block layer, on the other hand, gets requests to put > bits in blocks or to get bits from blocks, and has to deal with how to > actually implement that, given where the bits live. For a local disc, this > is an HBA adapter driver. For iSCSI, this is actually a transport rather > than an HBA. There are several transports, for example iSER (Infiniband) is > another. > > I hope that helps. > — > Lee > > > -- You received this message because you are subscribed to the Google Groups "open-iscsi" group. To unsubscribe from this group and stop receiving emails from it, send an email to open-iscsi+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/open-iscsi/0623097f-bd0a-4002-845c-273f67bfbd81%40googlegroups.com.
Re: how it works
On Jan 11, 2020, at 11:26 AM, Bobby wrote: > > Hi , > > Thanks for your patience regarding my questions. Because after I had dug > (digged) very older posts, I realized > many of the older posts already had answers for many of my earlier questions > :). After your couple of answers and going > through old posts, I have a better understanding of user land and kernel land. Excellent. > > Now one more point. > > Kernel land: > While we are at kernel land, I have a confusion on that. > AFAIK in linux kernel, the linux block layer is a glue that, on the one hand, > allows applications to access > diverse storage devices > in a uniform way, and on the other hand, > provides storage devices and drivers with a single point of entry from all > applications. > I mean this Linux OS (host) block layer is the most > critical part of the I/O hierarchy, as it orchestrates the I/O > requests from different applications to the underlying storage. > > Question: > So in context of Open-iSCSI, where does the user-land interacts the block > layer in the kernel land? I > mean, when it comes to kernel land, why we are considering only > scsi_transport_iscsi.c and iscsi_tcp.c codes? Shouldn't > the block request go through block layer? > > As always, thanks in advance :) > > The iscsi initiator (open-iscsi) acts as an HBA, in effect, in the block system. The layer above the block layer (conceptually) are the disc or tape drivers.The block layer presents an abstract interface to them, so that they only have to deal with putting bits in blocks, or getting bits from blocks. The layer below the block layer, on the other hand, gets requests to put bits in blocks or to get bits from blocks, and has to deal with how to actually implement that, given where the bits live. For a local disc, this is an HBA adapter driver. For iSCSI, this is actually a transport rather than an HBA. There are several transports, for example iSER (Infiniband) is another. I hope that helps. — Lee -- You received this message because you are subscribed to the Google Groups "open-iscsi" group. To unsubscribe from this group and stop receiving emails from it, send an email to open-iscsi+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/open-iscsi/ABCA782A-1508-45D5-9283-933FE7855CF4%40gmail.com.
Re: how it works
Hi , Thanks for your patience regarding my questions. Because after I had dug (digged) very older posts, I realized many of the older posts already had answers for many of my earlier questions :). After your couple of answers and going through old posts, I have a better understanding of *user land* and *kernel land*. Now one more point. *Kernel land: * While we are at kernel land, I have a confusion on that. AFAIK in linux kernel, the linux *block layer* is a glue that, on the one hand, allows applications to access diverse storage devices in a uniform way, and on the other hand, provides storage devices and drivers with a single point of entry from all applications. I mean this Linux OS (host) block layer is the most critical part of the I/O hierarchy, as it orchestrates the I/O requests from different applications to the underlying storage. *Question:* So in context of *Open-iSCSI*, where does the user-land interacts the block layer in the kernel land? I mean, when it comes to kernel land, why we are considering only *scsi_transport_iscsi.c* and *iscsi_tcp.c* codes? Shouldn't the block request go through block layer? As always, thanks in advance :) On Friday, January 10, 2020 at 10:55:34 PM UTC+1, The Lee-Man wrote: > > On Friday, January 10, 2020 at 8:44:05 AM UTC-8, Bobby wrote: >> >> >> Hi, >> >> >> - Question 1: The kernel still contains 2 files? >> - Question 2: Do we still have those diagrams available online? >> >> >> The kernel has many files, but those two files are still present for > open-iscsi. If you look in drivers/scsi/*iscsi*.[ch], each of those files > are either initiator or target files. > > I don't know what diagrams were around in the past, but we no longer have > any on the web page, which is hosted by github now. A simple google of > "open-iscsi architecture diagrams" yields quite a few pictures, though, > such as this one: > https://www.researchgate.net/figure/General-iSCSI-architecture_fig1_221396996 > -- You received this message because you are subscribed to the Google Groups "open-iscsi" group. To unsubscribe from this group and stop receiving emails from it, send an email to open-iscsi+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/open-iscsi/30876a44-cc2e-44ef-a052-a5b91dd31147%40googlegroups.com.
Re: how it works
On Friday, January 10, 2020 at 8:44:05 AM UTC-8, Bobby wrote: > > > Hi, > > > - Question 1: The kernel still contains 2 files? > - Question 2: Do we still have those diagrams available online? > > > The kernel has many files, but those two files are still present for open-iscsi. If you look in drivers/scsi/*iscsi*.[ch], each of those files are either initiator or target files. I don't know what diagrams were around in the past, but we no longer have any on the web page, which is hosted by github now. A simple google of "open-iscsi architecture diagrams" yields quite a few pictures, though, such as this one: https://www.researchgate.net/figure/General-iSCSI-architecture_fig1_221396996 -- You received this message because you are subscribed to the Google Groups "open-iscsi" group. To unsubscribe from this group and stop receiving emails from it, send an email to open-iscsi+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/open-iscsi/9745153a-66eb-4abb-8628-23e2ba1b28fd%40googlegroups.com.
Re: how it works
Hi, - Question 1: The kernel still contains 2 files? - Question 2: Do we still have those diagrams available online? On Tuesday, May 24, 2005 at 1:11:26 AM UTC+2, Dmitry Yusupov wrote: > > On Mon, 2005-05-23 at 16:51 -0400, Eddy Quicksall wrote: > > Is there an explanation someplace as to how the iSCSI initiator works? > > e.g., the meaning of each .c file, an explanation of each function. > > open-iscsi/linux kernel part contains of two C-files: > > - scsi_transport_iscsi.c > > SCSI transport class implements iSCSI sysfs abstraction, transport > API > and user/kernel NETLINK IPC. > > - iscsi_tcp.c > > implements data-path mover over TCP/IP. Uses zero-copy PDU > processing, > sendfile-like receive and sendpages-like transmit. Very optimized. > > userspace stuff... who cares how many C-files in there? > > there are some diagrams on http://www.open-iscsi.org > > -- You received this message because you are subscribed to the Google Groups "open-iscsi" group. To unsubscribe from this group and stop receiving emails from it, send an email to open-iscsi+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/open-iscsi/1306f306-ef08-4e79-b98a-6d1e6ee42f25%40googlegroups.com.
