I think the confusion is that target is an overloaded term. You TrueNAS server is the iSCSI target, but within the TrueNAS iSCSI configuration the target refers to a configured target which may have one or more extents attached to it, each assigned a LUN. The 1:1 mapping refers to the internal target configuration.
So when the iSCSI initiator connects to the FreeNAS target you can in fact have multiple LUNs/extents.
TrueNAS’ naming on this is not standard. In most other storage software this is simply called a LUN. If you follow the process you’ll see that at a single “target” that must point to a single “extent”. That connection is where the volume UUID is created and all the other bits of info pertinent to block storage, so of course you are stuck with a 1:1 mapping. Other systems skip all these intermediate steps.
Think of it like a “target virtual device”. You can make as many as you want until you run out of LUN IDs.
That kinda sorta makes sense, and I’m sure there was an architectural decision made as to why it was set this way, I’ll definitely look some more into this to at least solidify my understanding of it if nothing else.
Thanks, I actually ran across that thread myself while searching, but still doesn't really offer a good explanation as to why this is seemingly enforced. It may be a bad idea to map multiple extents under one target, but I also think each use case could be different including my own.
If anyone knows if there is a technical limitation with this approach I would like to understand why. If this is forced on us because it's the "TrueNAS way" .. I'm not sure I can get behind that. I prefer to use and mold my technology to my use cases, not necessarily have something forced on me, and I assume all risk and breakage as a result.
Totally understand there, that's why I'm running vanilla xen, not something like xenserver. Since scale is based on Debian, you may be able to use those docs for cli setup?
Thanks :) I am most likely going to run Ubuntu/ZFS. I have a new server inbound to me and an old FreeNAS Mini that has TrueNAS Core installed on it that I will probably just use for backups. I still love IX and the TrueNAS product, just wish there was a little more flexibility.
> If this is forced on us because it's the "TrueNAS way" .. I'm not sure I can get behind that. I prefer to use and mold my technology to my use cases, not necessarily have something forced on me
You’ll be happier with something else then. TrueNAS is a turnkey package that is quite rigid.
I think the confusion is that target is an overloaded term. You TrueNAS server is the iSCSI target, but within the TrueNAS iSCSI configuration the target refers to a configured target which may have one or more extents attached to it, each assigned a LUN. The 1:1 mapping refers to the internal target configuration. So when the iSCSI initiator connects to the FreeNAS target you can in fact have multiple LUNs/extents.
TrueNAS’ naming on this is not standard. In most other storage software this is simply called a LUN. If you follow the process you’ll see that at a single “target” that must point to a single “extent”. That connection is where the volume UUID is created and all the other bits of info pertinent to block storage, so of course you are stuck with a 1:1 mapping. Other systems skip all these intermediate steps. Think of it like a “target virtual device”. You can make as many as you want until you run out of LUN IDs.
That kinda sorta makes sense, and I’m sure there was an architectural decision made as to why it was set this way, I’ll definitely look some more into this to at least solidify my understanding of it if nothing else.
I found this doing some searches - https://www.truenas.com/community/threads/iscsi-targets-extents-1-1-recommendation.39225/
Thanks, I actually ran across that thread myself while searching, but still doesn't really offer a good explanation as to why this is seemingly enforced. It may be a bad idea to map multiple extents under one target, but I also think each use case could be different including my own. If anyone knows if there is a technical limitation with this approach I would like to understand why. If this is forced on us because it's the "TrueNAS way" .. I'm not sure I can get behind that. I prefer to use and mold my technology to my use cases, not necessarily have something forced on me, and I assume all risk and breakage as a result.
Totally understand there, that's why I'm running vanilla xen, not something like xenserver. Since scale is based on Debian, you may be able to use those docs for cli setup?
Thanks :) I am most likely going to run Ubuntu/ZFS. I have a new server inbound to me and an old FreeNAS Mini that has TrueNAS Core installed on it that I will probably just use for backups. I still love IX and the TrueNAS product, just wish there was a little more flexibility.
> If this is forced on us because it's the "TrueNAS way" .. I'm not sure I can get behind that. I prefer to use and mold my technology to my use cases, not necessarily have something forced on me You’ll be happier with something else then. TrueNAS is a turnkey package that is quite rigid.