Finally I took some minutes and checked that cosmetic issue, which symptoms in showing 88% percent remirror status right after the start of a remirroring (where it should be 0%) on earlier NetWares.
If install.nlm shows 42.949.680 or more data blocks (that is 171.798.720 sectors, approximately 163,84 GB) for a partition, then mirror algorithm will fail to correctly calculate the percentage.
Let’s say, we have 48.832.973 (0×2E921CD) data blocks, with 6627 (0×19E3) redirection blocks.
Then according to server.exe’s calculation, ~48.408.845 (~0×2E2A90D) “mirror blocks” should be mirrored.
There is an instruction “IMUL EBX*64h” which multiplies this value by 100 (0×64), but then the value will overflow the poor 32bit register, resulting in 0×1208A0914.
Then dividing the remaining 32bit part only (0×208A0914) by the number of data blocks (0×2E921CD) would result in 11 (0xB) which would be 99-11=88% complete.
So from then on, it will reach 99% by about mirrorring the 0xA699D-th block, then at next block it would “jump to” 12% (0xffffe10/0×2E921CD=0×57=87 -> 99-87=12%)
Then it would go to 99% “normally”
This only affects the calculation and display of the status percentage, not the mirroring procedure itself.
So even 3.x/4.x NetWares - more precisely the NetWare traditional file system - can handle large harddisk/block size, but seems like who wrote the “display percentage calculation” part wasn’t prepared enough…
Traditional file system’s “most important” size related limitations:
Maximum device size recognized (physical or logical): 2 TB
Maximum partition size: 1 TB
Maximum volume size: 1 TB
Maximum file size: 4 GB
Here is a more detailed comparsion on traditional FS versus NSS.
