Unlike the FORMAT UNIT command, these commands seem designed to work in the background. So they will return quickly (although sbc5r01.pdf does not state that) and the disk will be placed in a reduced functionality state where only a specified number of commands will be executed (e.g. INQUIRY and REPORT LUNS) until the operation is complete. Other commands will receive sense data with a sense key of NOT READY and an additional sense code of 'Depopulation in progress' (for REAT and REAMZ) or 'Depopulation restoration in progress' (for RESAR). See the NOTES section below for more information.
The REMOVE ELEMENT AND TRUNCATE [REAT] and the RESTORE ELEMENTS AND REBUILD
[RESAR] commands are defined in SBC-4 and later (i.e. SCSI Block Command
standard) while REMOVE ELEMENT AND MODIFY ZONES [REAMZ] is defined in
ZBC-2 and later (i.e. Zoned Block Command standard). Note that the REAMZ
command can be issued by this utility (with the --modify option)
or the sg_zone utility (with the --remove option); the resulting
action should be the same.
The difference between REAT and REAMZ is that the former "changes the
association between LBAs and physical blocks" and the latter does not
change that association. Zones affected by the REAMZ command are placed
into the zone condition: "Offline".
A (storage) element of a rotating hard disk is one side of a platter typically associated with one head. Such hard disks typically have multiple platters with two heads per platter (i.e. one head each side of the platter).
Only one element can be depopulated at a time. It seems that user data is striped across various platters (manufacturers pointedly don't describe how that is done) so depopulation can take a very long time irrespective of which element (e.g. the last element) is depopulated. The DEPOPULATION TIME field in the Block Device Characteristics VPD page gives an indication of how long the depopulation of one element will take. The unit of that field is seconds and for reference, there are 86,400 seconds in a day. Once a --remove or --restore based command has successfully returned, the disk goes into what can be considered as "depopulation" mode. While a disk is in "depopulation" mode, all media access commands (and some others) are rejected with a NOT READY sense code and additional sense code of 0x4,0x24 or 0x4,0x25 (the latter one is for "depopulation restoration in progress").
While this facility is described by reference to hard (spinning) disks, the commands are defined in general terms so that they might also apply to solid state disks (SSDs) that are implemented using multiple ICs (die_s). Depopulation may be useful if one of those ICs becomes faulty.
At time of writing, OS and HBA support for depopulating hard disks is incomplete. For example Linux as of lk 6.5.7 does not properly handle the situation when a hard disk is in "depopulation" mode. Also at least one SAS-4 HBA has trouble booting when one of its attached hard disks is in "depopulation" mode. Suggestion: depopulating a head on a hard disk (or restoring it) should be done on a non-production system that is not used for any other purpose during the depopulation.
When a hard disk is in "depopulation" mode a REQUEST SENSE command can be sent to obtain "progress" information. This can be done with the 'sg_requests' or 'sg_requests --progress' utility.
In summary, "head" depopulation on a hard disk can be viewed as a type of format operation that takes a failed or failing disk with media errors all on one side of a platter, and produces a properly functioning disk with (slightly) reduced capacity. Finally the T10 specifications do not say that depopulation on a disk will lead to all data will be lost, but it is a safe assumption that all data will indeed be lost. So the normal warnings about taking backups before attempting depopulation apply.