Can my 2006 Laptop use Samsung 860 EVO 500GB SSD?

[j7n]

Are there restrictions for an atypical number of reserved sectors or cluster size for the system partition with old Windows? I seem to recall that it didn't boot with with an aligned partition start, but last I formatted a disk years ago and have forgotten the details. I also ordered a flash memory for replacement of the system disk.

Is this a legit check: create a file system, write one file, find its start address in a hex editor, divide it by 4k? I don't think I can use RMprepUSB for an internal disk.

[jaclaz]

2 hours ago, j7n said:

Are there restrictions for an atypical number of reserved sectors or cluster size for the system partition with old Windows? I seem to recall that it didn't boot with with an aligned partition start, but last I formatted a disk years ago and have forgotten the details. I also ordered a flash memory for replacement of the system disk.

Is this a legit check: create a file system, write one file, find its start address in a hex editor, divide it by 4k? I don't think I can use RMprepUSB for an internal disk.

 

No practical restriction, the (new or old) windows will create a volume (FAT, NTFS has NOT "reserved sectors") with a certain number (automatically determined) of "reserved sectors" as well as a certain size of the FAT tables (2 of them), you can increase the number of "reserved sectors" (shifting forward the FAT tables) as much as you want, or you can increase the single FAT table size (leaving one or more "unused" sectors at the end).

Cluster size is instead normally automatically determined by volume size, namely, according to this table:

 https://support.microsoft.com/en-us/topic/default-cluster-size-for-ntfs-fat-and-exfat-9772e6f1-e31a-00d7-e18f-73169155af95

as you might know there are third party formatting tools allowing 32 kB sized clusters on largish volumes (up to the limit of FAT32), that "unsupported" [1] size might give issues with different Operating Systems, particularly as "boot"  volume, but there are too many possible combination of volumes sizes, operating system versions and *what not* to be able to be more specific.

The check may be legit, but - with all due respect - it seems to me rather pointless.

I mean ("normal" way):

1) format a volume as FAT32
2) read and jolt down from its bootsector the number of reserved sectors and FAT size, then add "sectors before"+"reserved sectors"+2*"FAT size" and divide the result by whatever alignment value you choose
3) if you have a remainder either increase the number of hidden sectors and shift both the FAT tables or (if the remainder is even) increase the FAT size of 1/2 of the remainder and shift only the second Fat table

Your check:
1) format a volume as FAT32
2) write a file to it, find the address (in sectors offset) of the beginning of that file and divide the "sectors before"+"address of file in sectors" by whatever alignment value you choose 
3) if you have a remainder either increase the number of hidden sectors and shift both the FAT tables or (if the remainder is even) increase the FAT size of 1/2 of the remainder and shift only the second Fat table (but you will have to additionally overwrite with 00's the area when you wrote the file as it will likely become part of the second copy of the FAT tables)

The tricky enough part is #3.

And remember that Steve6375's experiments led to aligning NOT to the file area, but to align to the actual first file (i.e. excluding the cluster occupied by the "label" on a freshly formatted disk to a MUCH larger value (1 Mb) so that it is a multiple of *everything*, i.e. not only cluster size but also page size.

If you prefer, if you format and use a label, you have already written a first file to it, and you should align to the next cluster (where the actual first file will be written to).

Of course, instead of the above you *can* align the volume contents by simply moving the volume/partition monolythically ("sectors before" in the boot sector an partition table in the MBR), but this would lead to "crazy numbers" in the MBR and this may actually cause an issue, either as the "booting" one you seem to remember[2] or - before or later - with Diskpart or some other partitioning tool, again this may depend on the specific OS and tool versions, and - besides the "move" will anyway need to be done manually as most partition tools align partitions/volumes with either the canonical "head" or the "MB" conventions, I don't seem to remember any valid tool that is both "automatic"/"user friendly" and has the sensibility to move/place volumes/partitions at single sector granularity.

Anyway, on internal devices you won't notice any improvement in access or transfer times.

jaclaz

[1] even if MS calls the 32 kB cluster size "unsupported", it actually means that they don't provide a tool to format a volume with that cluster size, but once you have a validly formatted volume with 32 kB clusters, in normal operation it behaves just fine, at least for "data" volumes

[2] never experienced it, but in theory it is possible that this or that OS throws a fit with not canonically aligned boot volumes