磁盘大小觉得inode大小
Most of the time, the values for ‘Size’ and ‘Size on disk’ will be very close to matching when checking a folder or file’s size, but what if there is a huge discrepancy between the two? Today’s SuperUser Q&A post looks at the answer to this confusing problem.
在大多数情况下，检查文件夹或文件的大小时，“大小”和“磁盘大小”的值将非常接近匹配，但是如果两者之间存在巨大差异怎么办？ 今天的SuperUser Q＆A帖子探讨了这个令人困惑的问题的答案。
Today’s Question & Answer session comes to us courtesy of SuperUser—a subdivision of Stack Exchange, a community-driven grouping of Q&A web sites.
今天的“问答”环节由SuperUser提供，它是Stack Exchange的一个分支，该社区是由社区驱动的Q＆A网站分组。
问题 (The Question)
SuperUser reader thelastblack wants to know why there is such a huge difference between ‘Size’ and ‘Size on disk’ for a folder on his phone’s SD card:
超级用户阅读器thelastblack想知道为什么手机SD卡上的文件夹的“大小”和“磁盘大小”之间有如此巨大的差异：
As you can see below, there is so much difference between the ‘Size’ and ‘Size on disk’ fields for this folder. Why is that?
如下所示，此文件夹的“大小”和“磁盘大小”字段之间有很大差异。 这是为什么？
I know that ‘Size on disk’ should be a little more than ‘Size’ because of allocation units in Windows, but why is there that much difference? Could it be because of the large number of files?
我知道由于Windows中的分配单位，“磁盘大小”应该比“大小”大一点，但是为什么会有这么大的差异？ 可能是因为文件数量大吗？
BTW, this folder is on my Android phone’s SD card. Inside this, my maps app stores its cached maps, and the app gets its maps from Google Maps.
顺便说一句，此文件夹在我的Android手机的SD卡上。 在此内部，我的地图应用程序存储了其缓存的地图，该应用程序从Google Maps获取其地图。
Looking at the screenshot, there is definitely a huge discrepancy between ‘Size’ and ‘Size on disk’, so what has happened here to cause this?
查看屏幕截图，“大小”和“磁盘大小”之间肯定存在巨大差异，那么这里发生了什么原因呢？
答案 (The Answer)
SuperUser contributor Bob has the answer for us:
超级用户贡献者Bob为我们提供了答案：
I will be assuming that you are using the FAT/FAT32 file system here, since you mention this is an SD card. NTFS and exFAT behave similarly with regards to allocation units. Other file systems might be different, but they aren’t supported on Windows anyway.
我将假定您在这里使用FAT / FAT32文件系统，因为您提到这是SD卡。 NTFS和exFAT在分配单位方面的行为类似。 其他文件系统可能有所不同，但是Windows仍然不支持它们。
If you have a lot of small files, this is certainly possible. Consider this:
如果您有很多小文件，这肯定是可能的。 考虑一下：
- 50,000 files 50,000个文件
- 32 KB cluster size (allocation units), which is the max for FAT32 32 KB群集大小(分配单位)，这是FAT32的最大值
Ok, now the minimum space taken is 50,000 * 32,000 = 1.6 GB (using SI prefixes, not binary, to simplify the maths). The space each file takes on the disk is always a multiple of the allocation unit size – and here we’re assuming each file is actually small enough to fit within a single unit, with some (wasted) space left over.
好的，现在最小占用空间为50,000 * 32,000 = 1.6 GB(使用SI前缀而不是二进制，以简化数学)。 每个文件在磁盘上占用的空间始终是分配单元大小的倍数–在这里，我们假设每个文件实际上足够小以适合单个单元，并且剩余一些(浪费)空间。
If each file averaged 2 KB, you’d get about 100 MB total – but you’re also wasting 15x that (30 KB per file) on average due to the allocation unit size.
如果每个文件平均2 KB，则总共将获得100 MB的空间，但由于分配单元的大小，平均浪费了15倍(每个文件30 KB)。
In-Depth Explanation
深入说明
Why does this happen? Well, the FAT32 file system needs to keep track of where each file is stored. If it were to keep a list of every single byte, the table (like an address book) would grow at the same speed as the data – and waste a lot of space. So what they do is use “allocation units”, also known as the “cluster size”. The volume is divided into these allocation units, and as far as the file system is concerned, they cannot be subdivided – those are the smallest blocks it can address. Much like you have a house number, but your postman doesn’t care how many bedrooms you have or who lives in them.
为什么会这样？ 好了，FAT32文件系统需要跟踪每个文件的存储位置。 如果要保留每个字节的列表，则表(如地址簿)将以与数据相同的速度增长-并浪费大量空间。 因此，他们要做的是使用“分配单位”，也称为“集群大小”。 卷被划分为这些分配单位，就文件系统而言，它们不能被细分-这些是它可以处理的最小块。 就像您有门牌号码一样，但邮递员并不在乎您有多少间卧室或住在其中的人。
So what happens if you have a very small file? Well, the file system doesn’t care if the file is 0 KB, 2 KB, or even 15 KB, it’ll give it the least space it can – in the example above, that’s 32 KB. Your file is only using a small amount of this space, and the rest is basically wasted, but still belongs to the file – much like a bedroom you leave unoccupied.
那么，如果文件很小，会发生什么？ 嗯，文件系统不在乎文件是0 KB，2 KB还是什至15 KB，它将为它提供最小的空间-在上面的示例中为32 KB。 您的文件仅使用了少量的空间，其余部分基本上被浪费了，但仍属于该文件–就像您闲置的卧室一样。
Why are there different allocation unit sizes? Well, it becomes a trade-off between having a bigger table (address book, e.g. saying John owns a house at 123 Fake Street, 124 Fake Street, 666 Satan Lane, etc.), or more wasted space in each unit (house). If you have larger files, it makes more sense to use larger allocation units – because a file doesn’t get a new unit (house) until all others are filled up. If you have lots of small files, well, you’re going to have a big table (address book) anyway, so may as well give them small units (houses).
为什么会有不同的分配单位大小？ 好吧，这是权衡取舍的选择：拥有更大的桌子(例如通讯录，例如说约翰在假街123号，假街124号，撒旦巷666号等处拥有房屋)，或者在每个单元(房屋)中浪费更多的空间。 如果您有较大的文件，则使用较大的分配单位会更有意义-因为在所有其他文件都填满之前，文件不会获得新的单位(房屋)。 如果您有很多小文件，那么无论如何，您都将有一个大桌子(地址簿)，因此最好给它们提供小单元(房子)。
Large allocation units, as a general rule, will waste a lot of space if you have lots of small files. There usually isn’t a good reason to go above 4 KB for general use.
通常，如果您有很多小文件，则大的分配单元将浪费大量空间。 通常，通常没有充分的理由超过4 KB。
Fragmentation?
碎片化？
As for fragmentation, fragmentation shouldn’t waste space in this manner. Large files may be fragmented, i.e. split up, into multiple allocation units, but each unit should be filled before the next one is started. Defragging might save a little space in the allocation tables, but this isn’t your specific issue.
至于碎片，碎片不应以这种方式浪费空间。 大文件可能会被分割成多个分配单元，也就是将其拆分为多个分配单元，但是每个单元都应在下一个分配单元开始之前被填充。 碎片整理可能会在分配表中节省一些空间，但这不是您的特定问题。
Possible Solutions
可能的解决方案
As gladiator2345 suggested, your only real options at this point are to live with it or reformat with smaller allocation units.
正如gladiator2345所建议的那样 ，此时，您唯一的选择是使用它，或者使用较小的分配单元重新格式化。
Your card might be formatted in FAT16, which has a smaller limit on table size and therefore requires much larger allocation units in order to address a larger volume (with an upper limit of 2 GB with 32 KB allocation units). Source courtesy of Braiam. If that is the case, you should be able to safely format as FAT32 anyway.
您的卡可能采用FAT16格式，这对表大小有较小的限制，因此需要更大的分配单位才能处理更大的卷(对于32 KB分配单位，上限为2 GB)。 来源由Braiam提供 。 如果真是这样，您仍然应该能够安全地将其格式化为FAT32。
Have something to add to the explanation? Sound off in the comments. Want to read more answers from other tech-savvy Stack Exchange users? Check out the full discussion thread here.
有什么补充说明吗？ 在评论中听起来不错。 是否想从其他精通Stack Exchange的用户那里获得更多答案？ 在此处查看完整的讨论线程 。
翻译自: https://www.howtogeek.com/180369/why-is-there-a-big-difference-between-size-and-size-on-disk/
磁盘大小觉得inode大小