Size of files/folders vs "size on disk" MASSIVELY different?

I think this will be addressed in 4.2.26 (or was it already addressed in 4.2.25? What firmware are you running?), and yes it is to improve performance.

Your data should all be intact.

I observe the same big difference.
On my RNDP4000 with firmware 4.2.24 I see my Pictures folder:

1. Under Windows 8:
Size: 328 GB (352 863 936 767)
Size on disk: 328 GB (352 903 155 712)

2. Under Windows 8.1:
Size: 328 GB (352 863 936 767)
Size on disk: 7,72 TB (8 498 498 764 800)

Under Windows 8 everything is ok, but under Windows 8.1 there is a big difference as you can see above. Why??

The issue is described here: viewtopic.php?f=51&t=72934&p=406274#p406274

It is fixed in 4.2.25.

Thanks StephenB. I have upgraded to 4.2.25 and now I can see:

1. Under Windows 8:
Size: 328 GB (352 863 936 767)
Size on disk: 328 GB (352 903 155 712)

2. Under Windows 8.1:
Size: 328 GB (352 863 936 767)
Size on disk: 331 GB (355 647 881 216)

So still there is difference in size on disk. Could you explain me why, please?

Whereas I use 'du -b' command in the system shell I can see another size than Windows presents:
352 868 872 447

We have 2014 and such basic problems with calculate the size of files??? It's very irritating. Now we can't be sure which value out of the above is correct.

ReadyAS wrote:
1. Under Windows 8: Size: 328 GB (352 863 936 767) Size on disk: 328 GB (352 903 155 712) 2. Under Windows 8.1: Size: 328 GB (352 863 936 767) Size on disk: 331 GB (355 647 881 216) So still there is difference in size on disk. Could you explain me why, please?

The smallest unit of space that can be allocated on your drives is called a "cluster" or "allocation unit". The size of a cluster varies from one drive to another, although it is typically around 4K bytes.

With a 4KB cluster size, even a one-byte file will require 4KB of disk space. You can see this for yourself: Create a text file containming a single character, then look at its properties in Windows. It'll be shown as something like "Size: 1, Size on disk: 4096". That "size on disk" indicates that a full cluster was allocated even though only one byte of storage was needed.

What you're seeing with your NAS is that Windows 8 assumes one cluster size for its "Size on disk" display and Windows 8.1 assumes another. I don't know what sizes they're using, but if I had to guess from your numbers I would say that Windows 8 is assuming 4K cluster sizes and Windows 8.1 is assuming 256K cluster sizes. If you tell me how many files are on the disk, I can give you a more certain answer.

ReadyAS wrote:
Whereas I use 'du -b' command in the system shell I can see another size than Windows presents: 352 868 872 447

That size is the same as is displayed by Windows 8 and Windows 8.1 on the "Size:" line.

ReadyAS wrote:
We have 2014 and such basic problems with calculate the size of files??? It's very irritating. Now we can't be sure wchich value out of the above is correct.

It depends on what you mean by "correct". If you want to know the sum of the actual file sizes of all your files, the Windows "Size:" value (for both Win8 and Win8.1) is the correct one. If you want to know exactly how much space on disk is being used, the Windows 8 number is probably correct.

fastfwd wrote:

ReadyAS wrote: 1. Under Windows 8: Size: 328 GB (352 863 936 767) Size on disk: 328 GB (352 903 155 712) 2. Under Windows 8.1: Size: 328 GB (352 863 936 767) Size on disk: 331 GB (355 647 881 216) So still there is difference in size on disk. Could you explain me why, please? The smallest unit of space that can be allocated on your drives is called a "cluster" or "allocation unit". The size of a cluster varies from one drive to another, although it is typically around 4K bytes. With a 4KB cluster size, even a one-byte file will require 4KB of disk space. You can see this for yourself: Create a text file containming a single character, then look at its properties in Windows. It'll be shown as something like "Size: 1, Size on disk: 4096". That "size on disk" indicates that a full cluster was allocated even though only one byte of storage was needed.

I know what the cluster mean, but thanks for explanation.

fastfwd wrote:

What you're seeing with your NAS is that Windows 8 assumes one cluster size for its "Size on disk" display and Windows 8.1 assumes another. I don't know what sizes they're using, but if I had to guess from your numbers I would say that Windows 8 is assuming 4K cluster sizes and Windows 8.1 is assuming 256K cluster sizes. If you tell me how many files are on the disk, I can give you a more certain answer.

There is 80935 files in 592 folders.

fastfwd wrote:
ReadyAS wrote: Whereas I use 'du -b' command in the system shell I can see another size than Windows presents: 352 868 872 447 That size is the same as is displayed by Windows 8 and Windows 8.1 on the "Size:" line.

No, it's different: 352 868 872 447 vs 352 863 936 767 (not so much, but different)

fastfwd wrote:

ReadyAS wrote: We have 2014 and such basic problems with calculate the size of files??? It's very irritating. Now we can't be sure wchich value out of the above is correct. It depends on what you mean by "correct". If you want to know the sum of the actual file sizes of all your files, the Windows "Size:" value (for both Win8 and Win8.1) is the correct one. If you want to know exactly how much space on disk is being used, the Windows 8 number is probably correct.

The difference between W8 and W8.1 is not acceptable in my opinion, but it is Microsoft fault.

ReadyAS wrote:
There is 80935 files in 592 folders.

In that case, Windows 8 is using 1KB allocation units and Windows 8.1 is using 64KB.

ReadyAS wrote:
No, [the du -b result and the Windows Size reports are] different: 352 868 872 447 vs 352 863 936 767 (not so much, but different)

Ah, my mistake.

That difference is a mystery to me as well; I don't know enough about the Linux filesystems to know where the extra ~60 bytes per file (or ~8K per directory) is coming from.

ReadyAS wrote:
The difference between W8 and W8.1 [size on disk] is not acceptable in my opinion, but it is Microsoft fault.

I do not know for sure -- this is only a guess -- but I assume that the difference is due to Windows 8.1 being "smarter" about calculating cluster size. Rather than simply accepting the 1KB cluster size reported by the NAS, perhaps Windows 8.1 assumes that the cluster size is the GREATER of that 1KB and some block-size parameter used by SMB. (I don't know anything about SMB, so I can't say exactly what parameter that might be.) If the SMB protocol requires an acknowledgement (or a similar time-wasting action) after every block, it would make sense for Netgear to set the SMB block size to an absurdly high value in order to make transfers happen as quickly as possible... And the original, pre-OS4.2.25, Windows 8.1 size on disk that you posted -- 8498498764800 -- indicates that Windows 8.1 was indeed seeing a huge block size, somewhere around 32MB.

I guess that the SMB block size was decreased in OS4.2.25 to make the Win8.1 size on disk more accurate, but that Netgear couldn't make it as small as the actual 1KB cluster size without hurting the transfer speed too much, so they compromised at 64KB: Close to the correct size on disk, but still fast.

As I said, though, only a guess.

Thank you fastfwd for your explanations.
Allocation unit is established during the process of formatting the partition and every system should read it correctly.
Tha allocation unit is the same for specific partition so what's the problem to read it, even through SMB. It's strange.
It's very bad if system assumes another size of allocation unit that in fact is.
In my opinion there are simply a weak points in the operating systems.

This discrepancy is not about the physical allocation units on the disks. Windows 8 is calculating everything based on what the SAMBA server in the NAS reports.

So the differences are a combination of the assumptions Windows 8 is making about the the SMB server (in its calculations), and the details of what SAMBA is reporting. Netgear already stated that SAMBA "fudges" some values. I believe that is to help overall interoperability, though the size reports are clearly not exact.

The actual file size is of course what is reported through du. That is looking at the native file system, and is not filtered through SAMBA to an OS that has no idea of what the real file system is.

I just loaded on a Pro6, the 4.2.26 - but still am having the file size issue in a much grander scale. I have only 630gb total used (5x1tb drive in dual redundancy), yet after in windows 2003 I check file space on the folders on the NAS - it shows 930,000 files, and 17.1TB. As it counts away, when it gets near just over 700,000 files - it jumps from 20gb to 17.1TB. This is causing some havoc with our crashplan load as well - when we backup to the cloud - it shows 17.1TB as well. Is this bug still in the latest version?