TARGETS(5)

πŸ“¦ in fedora 43, fedora 44

πŸ’– TARGETS(5) β€” the iSCSI targets config file, bestie edition πŸ’–

okay so real talk, this is the File Formats Manual page for targets, and it's literally the blueprint for the config file that tells iscsi-target(8) what storage to hand out. let's get into it πŸ¦‹


✨ NAME ✨

targets β€” configuration file for iSCSI targets


🌸 SYNOPSIS 🌸

targets

πŸ’… DESCRIPTION πŸ’…

The targets file describes the iSCSI storage which is presented to iSCSI initiators by the iscsi-target(8) service. A description of the iSCSI protocol can be found in Internet Small Computer Systems Interface RFC 3720.

Every line in the file (except comment lines that start with a #, those are just vibes and get skipped) specifies an extent, a device (which is made up of extents or other devices), or a target to present to the initiator.

Each definition β€” an extent, a device, and a target β€” lives on a single whitespace delimited line. one line, one whole thought, periodt.

πŸŽ€ the extent definition πŸŽ€

The extent definition specifies a piece of storage that will be used as storage, and presented to initiators. It is the basic definition for an iSCSI target. Each target must contain at least one extent definition β€” no extent, no target, iykyk.

  • Field 1: the extent name, which must begin with the word extent and be followed by a number.
  • Field 2: the file or NetBSD device which will be used as persistent storage.
  • Field 3: the offset (in bytes) of the start of the extent. This field is usually 0.
  • Field 4: the size of the extent. The basic unit is bytes, and the shorthand KB, MB, GB, and TB can be used for kilobytes (1024 bytes), megabytes (1024 kilobytes), gigabytes (1024 megabytes), and terabytes (1024 gigabytes) respectively.
not me reminding you that it's possible to use the word size here to use the full size of the pre-existing regular file given in the extent name. iconic, honestly.

🌈 the device definition 🌈

The device definition specifies a LUN or device, and is made up of extents and other devices. It is possible to create hierarchies of devices using the device definition. nesting doll energy fr fr.

  • Field 1: the device name, which must begin with the word device and be followed by a number.
  • Field 2: the type of resilience that is to be provided by the device.

For simple devices, RAID0 suffices. Greater resilience can be gained by using the RAID1 resilience field. Following the resilience field is a list of extents or other devices.

Large devices can be created by using multiple RAID0 extents, in which case each extent will be concatenated. Resilient devices can be created by using multiple RAID1 devices or extents, in which case data will be written to each of the devices or extents in turn.

πŸ’€ heads up bestie: if RAID1 resilience is used, all the extents or sub-devices must be the same size. Please note that RAID1 recovery is not yet supported by the iscsi-target(8) utility. Also, an extent or sub-device may only be used once. one and done, no double dipping.

πŸ‘‘ the target definition πŸ‘‘

The target definition specifies an iSCSI target, which is presented to the iSCSI initiator. Multiple targets can be specified.

  • Field 1: the target name, which must begin with either of the words target or lun and be followed by a number. Optionally, if a target is followed by an = sign and some text, the text is taken to be that of the iSCSI Qualified Name of the target. This IQN is used by the initiator to connect to the appropriate target.
  • Field 2: a selector for whether the storage should be presented as writable, or merely as read-only storage. The field of rw denotes read-write storage, whilst ro denotes read-only storage.
  • Field 3: the device or extent name that will be used as persistent storage for this target.
  • Field 4: a slash-notation netmask which will be used, during the discovery phase, to control the network addresses to which targets will be presented.

The magic values any and all will expand to be the same as 0/0. ✨

If an attempt is made to discover a target which is not allowed by the netmask, a warning will be issued using syslog(3) to make administrators aware of this attempt. The administrator can still use tcp wrapper functionality, as found in hosts_access(5) and hosts.deny(5) to allow or deny discovery attempts from initiators as well as using the inbuilt netmask functionality. double protection, we love to see it 🫢


πŸ“ FILES πŸ“

  • /etc/iscsi/targets β€” the list of exported storage targets

🧚 SEE ALSO 🧚

syslog(3), hosts.deny(5), hosts_access(5), iscsi-target(8)


⭐ HISTORY ⭐

The targets file first appeared in NetBSD 4.0.


and that's the whole page, bestie πŸ’– this lil slice of Debian manpage magic is dated December 18, 2007, and you can find it under TARGETS(5) β€” go forth and configure your targets, you absolute main character πŸ‘‘βœ¨

πŸ“¦ where this page comes from