If a user has one single bootable partition of capacity greater than 8GB, and he or she has standard 2/3/3.1 roms, then if the Startup-sequence is edited when the disk data is beyond the 8GB barrier (standard old scsi.device limit) then the Startup-sequence will be rendered unreadable by the system. :nervous:
Why should this be? Don't you read what I write? If you use a file system which uses direct-scsi commands, you can use all capacity the scsi.device recognises as one partition. If you don't have such a file system, all partitions (not only the boot partition) are limited to the first 4 GB of the drive. File corruption only happens in the latter case, if you don't limit partitions to the first 4GB of the drive.
File systems with direct-scsi capability include the old SFS V1.84, FFS V44 (which is the result of the FFSTD64 patch), PFS3 DS and PFS3 AIO.
There is no 8GB limit as such, but scsi.device limits the capacity to what the drive reports. I the drive reports its size according to the ATA specs, the capacity is limited to 8GB. But if the drive does not follow the ATA specs and reports its real size, scsi.device can use all the capacity with direct-scsi commands.
Only if you want to patch scsi.device and then use a file system which does not use direct-scsi but TD64 or NSD, then you need to arrange the boot partition inside the first 4GB and can have other partitions outside.
Another problem can arise if you use FFS (V43 or higher) with big partitions but don't have enough RAM to allow the disk-validator to validate the partitions. Then the affected partition will remain full and write protected although there are no files on it.
