search

PiSCSI / piscsi

PiSCSI allows a Raspberry Pi to function as emulated SCSI devices (hard disk, CD-ROM, and others) for vintage SCSI-based computers and devices. This is a fork of the RaSCSI project by GIMONS.
https://piscsi.org
BSD 3-Clause "New" or "Revised" License
545 stars 82 forks source link

Optionally encode physical sector size in image name #965

Closed uweseimet closed 2 years ago

uweseimet commented 2 years ago

With some real world drives (e.g. FUJITU M2624S) the physical sector size can be changed when formatting. Some tools support this and change the sector size with MODE SELECT (provided that MODE SENSE reports it to be changeable) right before formatting a drive. After FORMAT UNIT has completed the drive has a new physical sector size. rascsi currently displays a warning with a note to use the -b startup option in order to set a different sector size (the one required for the respective client platform). If the sector size were encoded in the filename, rascsi would be able to actually format drives with a different sector size, namely by renaming the image file accordingly.

Suggested approach: The sector size in bytes is encoded right before the extension, preceded by a dot, e.g. image_file.512.hds or image_file.1024.hda. If a file with this filename format is attached and if no explicit sector size is set on the command line, rascsi will automatically set the sector size to the value encoded in the filename. Illegal values will be rejected, just like the -b option does it. rasctl will not be involved, i.e. the filename is evaluated by rascsi only. Instead of using the command line option to override the size it might be better to report an error if there is a mismatch. When changing the sector size when formatting the drive, rascsi uses the sector size provided with the subsequent MODE SELECT to rename the file, e.g. from image_file.512.hds to image_file.2048.hds. If a filename does not have an encoded sector size when formatting with a new size, the file shall be renamed, i.e. the new sector size is inserted before the extension. image_file.hds would become image_file.2048.hds, for instance. If the size does not change no renaming takes place.

rdmark commented 2 years ago

An optional approach here would be to make the rascsi backend aware of and store this information in the *.properties files that the Web Interface uses for this purpose.

In fact, the proposed scheme to append the block size to the file name would break the current implementation of *.properties for the Web Interface in the corner case where both are applied at the same time. Similarly to the issue described in https://github.com/akuker/RASCSI/issues/786

I'm not married to the current *.properties scheme either, so I'm open to revisiting this for a more sturdy approach that the rascsi backend manages.

uweseimet commented 2 years ago

@rdmark In https://github.com/akuker/RASCSI/issues/786 I already mentioned issues caused by additional files. And there is one more issue I think I did not mention: Currently a user can copy an image with any available means in order to get a fully working clone. With additional files this is not possible anymore, which is a disadvantage.

uweseimet commented 2 years ago

Going to close this ticket because it appears to open Pandora's box, without resolving anything that cannot easily be handled (at least since release 22.10.01) by using the -b option for the respective drive.