NTFS 原来那么强，可以把 12G 的文件，变成 140M。

[tool2d]

我以前只知道 NTFS 可以打开压缩模式，但我不知道的是，就算不打开压缩，NTFS 也能把大文件变小。

在 android studio 下创建了一个 12G 的虚拟机，结果一看磁盘占用，才 140M 。

感觉白白赚了 10G 空间，爽到。

[pupboss]

我要是没记错的话。。创建虚拟机，可以选择一次性分配所有磁盘空间，和按照实际使用空间分配，好像跟 NTFS 没啥关系

[ytll21]

这个。。。槽点太多了，无从说起啊。。。

[youshangdemajia]

这个会不会是 .img 的功能？

[ho121]

这应该是 sparse file 吧，很多文件系统都有类似的。

[tool2d]

@pupboss 这是 NTFS 特有技能，叫稀疏文件（ FILE_ATTRIBUTE_SPARSE_FILE ），我也是才知道。

能自动压缩 0 字节的大片文件块。

[killeder]

你创建个 1T 的压缩率更高

[kkocdko]

NTFS 特有么。。。你是拿什么来对比的呢，是拿着 FAT 来对比的吧。

[microxiaoxiao]

这也不是它独有的吧 ext 系列是不是有个空洞文件的概念

[debuggerx]

"大多数现代的文件系统支持稀疏文件，包括大多数 Unix 变种和 NTFS 。"

[tool2d]

@kkocdko 我的移动硬盘是 exFAT ，就不支持。

而且这种文件要复制后维持小磁盘占用，还需要专门 API ，用普通复制粘贴还不行。

[weak]

虚拟的 120G 是虚假的 120G 动态磁盘 用多少占多少，虚拟机里面看的是 120G 而已

[zcybupt2016]

虚拟机的磁盘是动态分配的...😓

[DefoliationM]

qemu qcow2 也有😅

[liaohongxing]

没听过哪种压缩算法能把 12G 压成 140M ，最好的 zstd 7z 都不行。

[wxf666]

@tool2d 不算啥新特性吧。。

Linux 命令 fallocate 说，ext4 、xfs 等文件系统，不光支持稀疏文件，还支持任意位置直接插入 /删除数据（--collapse-range ，--insert-range ）

我没用过，看这介绍也挺神奇的

[qsnow6]

算算压缩率就知道不可能，压缩完后只有原体积的 0.01%？？？


赞同 @zcybupt2016 说的动态分配

[lifansama]

@liaohongxing 被压缩的位置全是 0😂

[mxT52CRuqR6o5]

电驴客户端里就有稀疏文件相关的选项

[YSMAN]

动态的吧， 空间还没有占用 ps:xfs

[mxT52CRuqR6o5]

讲动态分配的，我 vmware 实践了一下，vmware 的动态分配可不会把还未分配的空间展示在宿主机磁盘文件的 size 上
前几楼都说了稀疏文件 sparse file 了，害搁这动态分配呢

[ipwx]

只是声称这个文件有 120G 但是没有分配存储块而已。

[lululau]

user in host in ~/tmp/hole-files via Rb v3.0.0
❯ dd if=/dev/zero bs=1 seek=9000000000000 count=1 of=hole.txt
输入了 1+0 块记录
输出了 1+0 块记录
1 字节已复制，0.00207946 s ，0.5 kB/s

user in host in ~/tmp/hole-files via Rb v3.0.0
❯ l
总计 4.0K
-rw-r--r-- 1 user user 8.2T 8 月 29 日 15:35 hole.txt

user in host in ~/tmp/hole-files via Rb v3.0.0
❯ du -sh
8.0K .

[moult]

@liaohongxing
12G 压成 140M 还是很好做到的
比如： dd if=/dev/zero of=test bs=1M count=10240
生成的 10G 的文件，普通的 ZIP 压缩压出来也就几十 M
但没有任何实际意义

[aloxaf]

@tool2d #5 https://en.wikipedia.org/wiki/Comparison_of_file_systems#Allocation_and_layout_policies

[GrayXu]

@tool2d 谢谢 LZ 让我知道原来 exFAT 是不支持稀疏文件的。
就想知道除了跨平台场景，exFAT 到底是谁在用

[nothingistrue]

@pupboss #1
@weak #11
@zcybupt2016 #12
@YSMAN #19
@ipwx #21
Size 11.7 GB ，Size on disk 138MB 。12G 资源已经分配了，后面是磁盘系统实际占用 138MB ，这个跟虚拟磁盘无关。

[mystrylw]

exFAT 不但不支持稀松文件，文件簇默认还是 128kb ，记得有一次往移动硬盘里拷贝了一堆小文件，瞬间满了。。

[yanqiyu]

太正常的 trick 了，linux 上
truncate -s 100T test 直接就可以创建一个声称大小是 100 T 的文件（哪怕你的盘没那么大）

你要去 du 就会发现这个文件不占空间
@moult 这种很好压缩的文件配合透明压缩存储会很舒适，但这个和稀疏文件是两个领域了

[libook]

exFAT 是一个除了兼容性其他方面都比较拉的文件系统，其可靠性完全不被建议用在任何重要场景（基本也就 U 盘比较适合用了）。
现代主流的文件系统（包括 NTFS ）都挺牛批的，要不然也不会流行到现在。

其实一些其他主流文件系统也都支持类似的透明压缩机制，当文件有连续空白空间存在的时候都可以实现题主在 NTFS 上的这种效果，当然他们更多价值在于一些非空白数据的压缩上面，用 Unix/Linux 的话可以了解一下 Btrfs 、ZFS 等。

[ButcherHu]

这个只是能看到稀疏文件的宣称大小吧

[butanediol2d]

@mystrylw 簇大小这个是格式化的时候定的吧，Windows 的格式化工具会根据分区大小决定簇大小，大硬盘 Windows 甚至会把簇大小加到 512kb 。

[1423]

支持 op ，楼上的大多应该根本没用过 ntfs 压缩

[baleeny]

我记得之前我在 mac 上装的 docker 也是这个样子。。有个显示 64GB 的 docker 文件，实际磁盘占用很少。

[germain]

在 SSD 上务必关掉 NTFS Compression ，任何对压缩的文件的写操作都是一个完全解压缩的过程，特别你这种 11G 到 100 多 M 的“压缩”， 会极度加速你 SSD 报废的过程。

[proxychains]

qemu-img info xx.qcow2.
你看到的只是他虚拟机的实际大小. 里面填点东西再看大小

[zlowly]

我也是最近才发现 Mysql/MariaDB 的 innodb 开启的 Page Compression ，也是用到了文件系统的这种 sparse file 特性，而象 ext3 和 ntfs 这样都老文件系统也一早有这种特性了。

[akira]

这个和 ntfs 没啥关系吧。。

你随便填点东西进这个虚拟机就知道了

[Yangz]

啊，我第一次知道，学到了 ww

[beijiaoff]

@germain 改写 NTFS 压缩文件不会傻到先把未压缩文件写磁盘上，然后再压缩完写入替换之前的。这个可以设计试验验证，简单搜了一下也是有的。

[mmdsun]

试了下手动开启：随便找个文件夹，右键属性，常规，高级，勾选压缩内容已节约磁盘空间。

不过压缩率没楼主这么高，应该是两个东西吧 ？
《 The NTFS File System File Compression 》
https://docs.microsoft.com/en-us/windows/win32/fileio/file-compression-and-decompression

[mmdsun]

@mmdsun

也找到了 sparse-files：
https://docs.microsoft.com/en-us/windows/win32/fileio/sparse-files

[Huelse]

@akira #37 这个就是 NTFS 的技术之一 https://docs.microsoft.com/en-us/windows/win32/fileio/sparse-files

[nanmu42]

学到了，谢谢。

[deorth]

建议换 ZFS

[vanton]

不想多说什么了，简直无话可说😓😓

[mayli]

V2ex 应该添加标签过滤器功能
添加个 菜鸡 标签，现在贴吧化严重…

[yuzo555]

2 楼的回复收到那么多感谢，有点无话可说...

楼上但凡说虚拟机动态分配的，你们有没有认真看楼主发的图片呢？
Size 和 Size on disk 区别这么明显没看到吗？

[efaun]

槽点太多 +1

[huangmingyou]

dd if=/dev/zero of=10T bs=1 count=1 seek=1024000000 也可以弄一个声称 10T 的文件，然后不占用空间。

[HeyWeGo]

老哥最近出镜率有点高啊，都是硬件相关的帖子

[AirTag]

这么多人说是虚拟机的扩展分配功能.
没看到截图里的 Size 和 Size on disk 么

[shakoon]

我前几年有台 WinSvr 的服务器，上面跑的 DB2 数据库，也是用了 NTFS 的压缩，2T 的磁盘实际存储了进 6T 的数据。
还有一个经验就是，对于文件超过 10GB 的非压缩文件，如果更改为压缩后，有较大概率在压缩过程中报错，然后文件处于“部分压缩”状态，虽然也能用，但是没有节约到预期的空间。另外压缩时尽量关闭所有可能读写到要压缩文件的程序。

[sampeng]

这么大压缩比例，如果能做到任意文件大小都能这么高的压缩比例。。。。。。商业价值比比尔盖茨还要大。想想任意真 4k 电影 2-30 个 G ，只要 100M 就能传输完，我的天。视听领域翻天覆地的变化。
再想想游戏领域，10Mb 的画面只需要 90k 的带宽就能完成。虚拟现实指日可待

所以，他这个算法是<硅谷>里面主角那个用撸 x 的灵感制造出来的吗？

[tpxcer]

只能说你里面没多少东西

[levywang]

槽点太多，手动狗头

[Motionall]

诶嘿

[nutting]

违反信息论

[tool2d]

@Motionall
@sampeng
@nutting

https://docs.microsoft.com/zh-cn/windows/win32/fileio/sparse-files-and-disk-quota

这是微软官方的功能，别搞得我好像无中生有。大概只有 0.001%的软件会用到的专用文件 WinAPI ，你们没听过也正常。

[Zepp]

我有一计，可授予楼主：把 NTFS 换成 APFS ，保准回复褒贬反转。

正经回答版：认真看看楼主贴出来的图，是文件管理器的文件属性显示大小 12G ，而不是在虚拟机软件里看到 12G ，你们再仔细想想？

[debuggerx]

https://developer.apple.com/documentation/foundation/file_system/about_apple_file_system#2990507
https://wiki.archlinux.org/title/sparse_file

NTFS 支持稀疏文件 √
这是 NTFS 特有技能 ×
NTFS 那么强 ???

[tool2d]

@debuggerx 都是抄袭 NTFS 的，NTFS 是差不多 30 年前发明的，别的系统推出，都比他要晚。

[dog82]

感觉按需扩容，跟 ntfs 没关系

[JohnBull]

@tool2d 打有狗那年，ext2 就支持文件空洞，是 POSIX 规定的的标准技能了

[ipwx]

@nothingistrue "Size 11.7 GB ，Size on disk 138MB 。12G 资源已经分配了，后面是磁盘系统实际占用 138MB ，这个跟虚拟磁盘无关。"
----

对不起真的和虚拟磁盘有关。

香农老爷子已经明确告诉你了，信息的压缩比是有极限的。12G=>138MB ，显然大部分数据位都是 0 ，所以才能把那部分 0 的位置给压缩出来。这恰恰是虚拟磁盘才会有的特性。

@tool2d 这部分评论也适用于楼主。不信楼主你在虚拟系统里面随便放个 10GB 的视频文件再删掉，然后你再看看 NTFS 能给你压缩到多大。

----

从这个意义上，“它只是声称 12G” 一点毛病都没有。不论是 NTFS 层面声称 12G （但不占用），或者预留出 12G （占用）。反正真正原因是没有写入非 0 数据所以才看上去有这么牛逼的压缩比。

[debuggerx]

BSD FFS: 1983
VxFS: 1991
EXT: 1992
EXT2: 1993.1
……
NTFS: 1993.7

@tool2d 谁抄袭谁？

[tool2d]

@ipwx “你在虚拟系统里面随便放个 10GB 的视频文件再删掉，然后你再看看 NTFS 能给你压缩到多大。”

肯定就是 10G ，这点还是清楚的。以前虚拟机的方法都是按需分配，用多少容量分配多少。现在是先分配，然后磁盘上全是洞洞，就感觉很有意思。

[nothingistrue]

@ipwx #64 你为何对 Size 这么大误解，文件的 Size 就是在文件系统上的已经申请出来的大小。预定义但没申请的磁盘，这个是只能程序自己保留的，这也不是虚拟磁盘的特性，任何一个程序都能这么干。

[tool2d]

@debuggerx NTFS 是有专用稀疏文件 api ，而 linux 在 EXT2 之前也就只有一个 inode ，都要手工 hack 。严格意义上 EXT3 开始正式导入 API 。

我去 github 搜了一下，SEEK_HOLE 是很后面才正式加入的。

[nothingistrue]

@ipwx #64 扇自己一巴掌，Size on disk 才是磁盘占用空间。但是这个 12 G ，仍然是 NTFS 文件系统的事。

[qsnow6]

所谓的动态分配和用 0 填充不就是一个意思吗？不然能维持这么高的压缩比？没必要杠

[nothingistrue]

@tool2d Hyper-V 的 VHDX 动态磁盘，应该有助于区分虚拟磁盘的动态分配，跟 NTFS 文件系统的稀疏文件。如果你有 Hyper-V 的话，创建一个 VHDX 动态虚拟磁盘，然后把虚拟机内磁盘大小、宿主机上文件的 Size 、宿主机上文件的 Size on disk 都列出来，应该就能终结此贴的争论了。

[mxT52CRuqR6o5]

@nothingistrue 一个需要文件系统提供能力，另一个完全不需要文件系统提供什么能力，完全靠自己的业务代码就能实现

[ipwx]

？好怪，我不知道 @nothingistrue 一本正经地想要纠正我啥。

按照这个形式，这个案例确实是声称了文件有 12G ，确实没有分配物理的存储块啊？不管是 NTFS 层面的“压缩”手段，还是 NTFS 的稀疏文件，还是 Linux 啥神奇 Hack ，不都是实现这个效果的某种手段嘛。

我也没有深入各个文件系统不同的实现方式，

[mxT52CRuqR6o5]

OP 的重点明显在于稀疏文件上
『哦，原来文件系统还会提供这种能力』
别搁那儿动态分配了

[lengyuqu]

ntfs 都要 30 年的古董文件系统了，互联网真是太神奇了

[nothingistrue]

@ipwx #73 文件系统跟虚拟磁盘动态分配，是两码事。Size 12G ，Size on disk 137M ，这是文件系统干的事，不是虚拟磁盘动态分配干的事。我只是说出这些事实而已。

[ipwx]

@nothingistrue ？我一开始就没说是虚拟磁盘干的事情啊。。。

“只是声称这个文件有 120G 但是没有分配存储块而已。”——虽然笔误写成了 120G 。我这里说的是操作系统没分配（物理）存储块，这有问题吗？

[lhhtyid1]

@youshangdemajia 不可能，绝不可能🐶

[chxf]

问题不会答，只会看热闹了。。。。

[beyondex]

NTFS 还有一个 MFT / USN 特性，这也是 Everything 能对 NTFS 磁盘实现全屏秒搜的原因。

[idealhs]

@beyondex 为什么我用 everything 搜 SMB 出来的 ext4 和 xfs 也是秒搜呢

[nothingistrue]

家里的 VHDX 虚拟磁盘，动态扩充类型，最大大小即虚拟机中看到的大小 127GB ，当前文件大小 77.29GB 。而在宿主机的文件属性上，大小和占用空间均为 77.2GB 。

终结吧

[v2tudnew]

@idealhs 你说的是文件夹那个功能吧？和 NTFS 和 REFS 不一样，文件夹的不是即时刷新结果。

[tuimaochang]

你说南山上的猴子，他说勾子上的瘤子

[windyboy]

借宝地问个题外话
MS 更新文件系统的可能性还有多少？感觉 windows 世界不太可能推出类似 ZFS 的文件系统了吧

[litguy]

@windyboy ZFS for windows 今年就要 release 了啊，openZFS 3.0 今年重大更新的 feature

[qrobot]

@sampeng #53L 有没有一种可能， 你传输过来的 4k 电影本身就是压缩过才只要 2-30G

[sampeng]

@qrobot 我说的是真的。不是那种低码率的。

[qrobot]

@sampeng 我也说的是真的，4k 的电影本身传输的时候就经过算法压缩了， 例如 MPEG-4 编码等等。 压缩后才只要 2-30G

[zhanggang807]

说个事儿，相反的 docker 有个文件占的特别大，但实际并没有那么大

[sampeng]

@qrobot 2-30G 是的。。我刚看成 2-3G 了。。。。
2-30G 。如果真有 100 倍压缩算法存在。想想就刺激

[ytmsdy]

当年 xcha 用矿池挖的时候，就有人利用这个特性。就写入一个文件头，文件的其他内容都是 0 ，然后一块 500G 的硬盘能搞出几十 T 的 xcha 盘，活生生从矿池里面薅了好多羊毛，最多的一个人伪装了 5P 还是 50P 的文件。

[windyboy]

@litguy windows 安装的时候可以用 root zfs 吗？

[Yinghuo]

精简模式。。。。。。

[litguy]

@windyboy 显然不是给这个准备的