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 (0x2E921CD) data blocks, with 6627 (0x19E3) redirection blocks.
Then according to server.exe’s calculation, ~48.408.845 (~0x2E2A90D) “mirror blocks” should be mirrored.
There is an instruction “IMUL EBX*64h” which multiplies this value by 100 (0x64), but then the value will overflow the poor 32bit register, resulting in 0x1208A0914.
Then dividing the remaining 32bit part only (0x208A0914) by the number of data blocks (0x2E921CD) 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/0x2E921CD=0x57=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.
