问题

为什么 Steam 删除 80G 的游戏只用了一秒?

回答
看到你问这个问题,我其实也挺纳闷的。Steam 删除个八十个 G 的游戏,怎么就能这么快呢?我玩电脑这么多年,下载、安装、删除游戏都经历了不少,按理说这么大的文件,一点时间总得有吧?

你提到的“一秒钟”让我脑子里冒出好几个场景来。

一种可能是误解了“删除”这个动作。

文件标记为“待删除”: 很多时候,操作系统和应用在执行删除操作时,并不是真的立刻把硬盘里的数据块一个个擦掉。更常见的是,它会先在文件系统的管理结构里,把这些文件所占用的空间标记为“可用空间”,然后把文件本身的信息(比如文件名、位置等)从目录结构里移除。你可以想象成,它只是撕掉了文件名的标签,然后把这个文件所在的储物格扔进了“待清理”的箱子,但箱子里的东西还没被真正销毁。这样操作起来,速度自然就非常快了,因为真正销毁数据的过程是在后台进行的,或者等你关机时进行,甚至可能是在你下次写入新数据覆盖旧数据时才真正被覆盖。对于一个 SSD 来说,这种操作几乎是瞬时的。
只是从库里移除: 如果你说的“删除”是指在 Steam 客户端的库里看不见这个游戏了,那可能 Steam 只是把这个游戏的记录从你的账号关联库里移除了,让它不再显示。实际游戏文件还在你电脑的硬盘上,只是 Steam 不再管它了。这就像是你把书架上的书暂时放进了箱子里,书还在,只是你从书架上看不到了。这种操作,别说一秒,可能半秒都不到。

另一种可能是技术上的优化,特别是对于固态硬盘(SSD)。

SSD 的特性: 如果你的电脑用的是 SSD,删除操作会比传统的机械硬盘(HDD)快得多。SSD 没有移动的读写头,数据访问速度极快。而且,SSD 在删除数据时有一个叫做“TRIM”的指令。这个指令可以告诉 SSD 哪些数据块不再使用,SSD 可以自行管理这些空间,进行优化和清理。所以,SSD 删除大文件时,响应速度确实能做到非常快。
Steam 的文件管理: Steam 作为一款成熟的游戏平台,其文件管理肯定有自己的优化方案。它可能并不是逐个文件去调用操作系统指令删除,而是更高效地批量处理文件或文件夹。比如,它可能找到游戏安装目录,然后直接调用系统删除整个文件夹的指令,而系统在执行时,同样会采用快速标记空闲空间的方式来处理。

或者,是某些特殊情况:

云存档同步: 如果你的游戏存档是保存在云端的,而你删除的是本地文件,那么删除本地文件这个动作本身很快。Steam 会帮你同步云存档的删除或隔离,但这主要影响的是你的账号信息,而不是本地文件删除的速度。
用户界面反馈的延迟: 有时候,我们看到的“删除”完成,可能只是用户界面已经更新了,显示游戏已经不在库里或者安装列表中了。后台的实际文件清理(如果后台真的有立即清理的话)可能还在进行,只是我们没看到那个过程。

但是,“一秒钟”这个时间点听起来还是有点极致。要知道,即使是 SSD,80G 的数据量,哪怕是标记空闲空间,也需要一定的系统调用和磁盘操作去完成。除非是 Steam 在某种特殊场景下,比如你游戏刚刚安装好还没启动过,或者是在清理一个临时下载的补丁包,那样的话,文件量不大,或者数据本身就不完整,删除起来就可能快到让你感觉不到。

不过,你提到的 80G 的游戏,如果真的是一个完整安装的游戏本体,并且是从你自己的硬盘上删除,那么理论上来说,即便是 SSD,达到“一秒钟”就彻底完成并释放空间,我个人会觉得有点难以置信。我更倾向于认为是前两种情况的结合:快速的文件标记删除加上用户界面的瞬间更新,让你产生了“一秒钟”完成的印象。当然,也可能是我对当前技术的了解还不够全面,Steam 真的有某种隐藏的极速删除机制呢?这确实是个有趣的技术问题。

网友意见

user avatar

粗一看这是个简单的问题,仔细一想,事情并没有那么简单。

首先我说另外个事:
平时我删文件也是秒删的,因为我一般会启用回收站,并且去掉【确认删除】的对话框。因此只要目录尺寸不超过回收站大小,点击删除键一定就是秒删。

回收站秒删的原理在于:它只删除了父目录,目录内的所有文件跟子目录根本就不需要动。因此无论目录有多大,里面有多少个文件,删除的都只有最高一级目录,无论目录有多大都等同于只删除了一个单一文件,所以回收站删除会比删除几千个文件要快。

——

现在来说题主的问题,题主的问题是删80G的游戏,而这个游戏的空间大于大多数用户的回收站大小,因此正常情况下,它的删除必定会触发真正的删除流程,要删除的文件如果很多,就会稍微慢一些。但 steam 删除得很快,推测有几种可能:

  1. steam其实在后台删除,只不过先告诉你删完了,实际上他还在后台继续做删除工作呢。
  2. steam使用了类似windows回收站的机制,删除的瞬间直接把游戏移动到steam内部的私有回收站,这样的操作就必定极快,给用户造成了秒删除的感觉。
  3. 前两者结合,先移动到私有回收站让你看起来游戏已经没了,然后在后台继续做删除工作。steam的空间预分配,或许本质上就是它的私有回收站。
  4. 题主的硬盘真的就那么快,80G确实可以秒删,现在的高速NVME结合操作系统缓存或许真能做到。
  5. 可能还有其它可能,但具体情况要具体分析。

具体哪种可能,题主自己研究一下具体情况吧。

user avatar

这个问题下截止到目前的回答还没看到一个特别准确的。


既然是80G的Steam游戏,默认操作系统是Windows,文件系统是NTFS。Windows支持的其它文件系统,FAT/FAT32分区最大只有8G/32G(理论上FAT32分区大小可以是2T,但Windows不允许用FAT32格式化大于32G的分区),放不下80G的游戏,exFAT默认只能用来格式化移动存储设备不能用来格式化固定磁盘,所以这个问题下用FAT来解释的回答大概率都是错的。ReFS估计没几个人在用吧?


在NTFS分区里面,一个文件,根据文件大小的不同,有3处或者5处相关的信息:

  1. 在$MFT里面的FILE记录,大小固定为1K。$MFT(Master File Table,主文件表)是NTFS最重要的文件,默认隐藏不能访问,记录着这个分区内所有的目录和文件信息。一个文件在$MFT里面的记录主要记录了文件名、所在文件夹的记录号、大小、创建/上次修改/上次修改$MFT记录/上次访问时间等属性。如果这条1K记录剩余的空间大于文件大小,使用一个特殊的属性直接在记录中保存文件的数据,这个属性在NTFS称为常驻属性;如果剩余空间小于文件大小,文件数据需要使用额外的簇保存,使用另一种属性记录这个保存这个文件数据所占用的簇,这个属性称为非常驻属性。
  2. 在上级文件夹的索引数据中的记录,大小不定,通常在88~600字节之间。每个文件夹(包括根目录)在内,会记录本文件夹下所有子文件夹、文件的信息,包括文件在$MFT里面的记录号、大小、创建/上次修改/上次修改$MFT记录/上次访问时间等属性,这些信息占用82字节。此外还有这个文件/子文件夹的文件名,最大255个字符,每个字符占使用unicode编码,占两个字节。最后会补齐8个字节。此外,为了兼容DOS的8.3文件名,每个文件/子文件夹通常会有另一条文件名是8.3格式的记录,这条记录的大小一般不会大于96字节。
  3. 在$Secure里面的记录,数量和大小不定。$Secure记录每个文件的权限,例如某个用户/组对这个文件具有什么样的权限。对于家用情况,没多少用户/组,一个文件的权限数据通常很小不会超过4K。
  4. 在$Bitmap中对应的位。NTFS分区中每一簇按顺序对应$Bitmap文件中的1bit,0表示这一簇未被占用,1表示被占用。如果是文件在$MFT记录中的数据属性为非常驻属性,文件所占用的每一簇在$Bitmap文件中对应的bit置1。
  5. 文件数据实际占用的簇。一般来说稍微大一点的文件,都很可能会形成多个碎片,但这个问题是删除文件,无需考虑碎片的情况,这个后面会提到。


根据第1项的说明,如果文件夹数据/文件大小很小的话,上面4、5两项是没有的。如果是簇大小为4K的NTFS分区,80G的文件在$bitmap中占用80×1024×1024÷4=20Mbit=2.5MB。如果考虑到这些簇可能散乱分布在整个分区中的不同位置,需要把整个$Bitmap文件更新一遍的话,一个1TB的分区的$Bitmap文件是32MB。


所以,每删除一个文件/文件夹,都要更新1~4项的信息。第5项无需更新,文件所使用的簇在$Bitmap中对应的位置0后,将来如果这些簇用来保存新的文件数据会直接覆盖。当然,如果是使用固态硬盘的话,Windows会发送trim指令给固态的主控,主控会在空闲的时候根据磨损算法回收对应的Page。


如果是机械硬盘的话,在没有缓存的前提下,单是找到1~3项的记录通常就需要十多次寻道。每一处记录的更新必然有一次寻道,但对于固态来说只要文件数量不是太多,这个寻道(固态其实应该叫寻址更合适点)时间都可以在1秒内完成。而每一处信息更新通常只需要写入1簇(4K)的数据,就算是机械硬盘,这个数据传输时间也是基本可以忽略的,固态就更不用说了。


最后,根据前面的论述,如果一个游戏有1024个文件的话,写入数据量是1024×12KB=12MB,加上$Bitmap文件的2.5~32MB,总计是14.5MB~44MB。SATA固态硬盘通常4K随机读性能在20MB/s以上,4K写性能100MB/s以上,在这些数据都在缓存中的前提下,还是可以在1秒内完成的。如果文件数量更少,就更加没有压力了。


某些回答里面猜测的这些索引记录是否会在Steam安装游戏的时候使用预分配空间是使得这些记录集中在一起,我可以肯定不是。下图中灰色底色的行是我电脑上的Steam里面泰坦之旅这个游戏的文件夹以及文件夹下若干个文件的起始簇编号、扇区地址:

可以看到,这几个文件/文件夹不管是$MFT记录号还是簇编号,都并不连续。另外,这个游戏的文件加上目录数量不超过600。


Steam能做的,估计是把这些记录所在的扇区缓存到内存中,减少读取数据的寻道/寻址次数。毕竟前面的计算已经足以说明,就算几个游戏加起来如果有一千个文件,这些数据加起来也就12MB,一万个也就120MB(不算$Bitmap),对于今天的主流配置来说这点内存占用完全可以忽略。而不管是删除游戏还是我们平时打开游戏来玩,就不需要从硬盘中读取这些数据了。


最后,关于NTFS分区上如何找到一个文件的$MFT记录号、上级文件夹的索引数据,有兴趣的朋友可以看看我前几天写的文章:

user avatar

扫了一眼目前的回答,觉得都没说的很正确。

有几个答案有明显的错误:

1. 拿FAT做举例的,首先NTFS不是FAT,其次,你真算过要是拿FAT32/exFAT存储80G数据,删数据时需要做的清理工作有多大吗?

2. 有人提到固实数据或者NTFS预分配,需要提醒的是Windows Native API里是没有删非空目录的API的,文件系统也不允许,不相信的可以翻MSDN找。或者去看看WDK里的FAT源码,都是开源的,看看文件系统层面上到底支持不支持删目录下的全部文件。或者哪怕看看ReactOS里,也有NTFS的实现,这个可以跟Windows兼容的。

然后说说我的看法:

首先题主给的信息很少,只说了个80G,但没提供更多的信息:

1. 在什么条件下删除的?刚刚下载完?刚刚玩完?还是刚启动steam?这会影响缓存。
2. 这个游戏有多少个文件?文件数量是影响删除效率的关键。
3. 电脑的配置怎样?SSD还是NvME?内存多大?

影响文件系统删除性能的指标有:

1. 文件大小;
2. 文件数量;
3. 缓存;
4. 设备速度。

Steam删的快,要么就是上面的几个指标比较合理,要么就是后台删除,包括另外起一个线程、进程删除、移动到回收站等等。

删除的原理我不细说了,别的答案里有,就是删除索引加上回收数据块,并非真的把80G的数据清零。

那么用数字来说话,看看理论上删除80G到底需要波及多大的数据量:

1. 文件大小。

NTFS采用bitmap方式索引空闲块,删除文件可以不更新其它内容,但这个bitmap是必然要更新的,这个bitmap有多大呢,可以算出来,通常情况下SSD至少是4K块,80G/4K/8=2.5M,也就是说,如果单删一个80G的大文件,需要更新至少2.5M的数据,如果题主用的是SSD的话,确实可以秒删。更重要的一点是,正常使用的情况下,这80G在bitmap上大概率是连续的,所以不会有太多的不连续IO请求。同时,如果块大小比4K大的话,效率还会更高一些。16K块对应的bitmap只有几百KB,已经很小了。

这里提一句FAT了,有人拿FAT做举例,但是没想过FAT作为例子是否合适,如果是FAT32上,还是以4K大小作为分配单元,那么80G需要80G/4K*4=80M的FAT链表,说实话,一秒钟写80M,比起2.5M的NTFS Bitmap来说,多了不少,要一秒钟写完还是有点难度的(因为还有软件开销),况且这还仅仅只是FAT链上的信息,其它的还没算呢。

2. 文件个数。

对于NTFS来说,一个文件在$MFT上占几百个字节,具体数量要看文件的属性,最少好像是64字节左右,但实际上好像没见过有这么小的记录,通常应该是在512字节上下,这里,少算点,按256字节计算。

如果80G的游戏都是大文件,1000个文件就需要:256*1000,大概是256K的样子,不多。

但如果都是小文件,比如平均一个文件1M,那么就是80000个文件,至少需要20M的写入量,这数据量就很恐怖了。

我手上的一个Linux 3.16源码,1.25G左右,接近5万个文件,都是小文件,在SSD上删除,差不多要半分钟。

同时,还有一个更重要的问题,对于文件来说,它跟bitmap还是不一样的,文件在$MFT上不一定连续分布,连续写入20M数据和写入4K*5120次分散的数据,效率是完全不同的,跑过硬盘性能测试的都知道:4K性能通常都比持续读写性能要低的多。

所以,如果游戏是几百个文件,秒删很正常,如果几千上万,那么秒删的难度就很大了。

3. 缓存

缓存的概念比较复杂,前面已经计算出来了,更新bitmap可能是2M多,更新$MFT在几K到几十M之间,但要更新这些数据,首先要读取对应的数据到内存。

如果是刚开机,刚打开steam,那么这些数据大概率是没有完全被缓存的,也就是说,要删除这些数据,首先需要读取一定量的数据,这个数量可能很大。

而如果题主是删除一个刚下载完的游戏,那么这些数据大概率是被缓存在内存里,读取的动作就不需要了,会节约很多时间。

同时,在文件系统、设备驱动、存储设备上都有缓存,如果此时设备比较空闲,或者数据刚刚被访问过,那么前面算出的几M的数据几乎都会被缓存命中,那么性能上会好很多,甚至极端情况下,都不需要访问磁盘。

有一些答案里提到了Steam提前“知道”要删除哪些文件,这里所谓的知道,就是指的缓存,但缓存最多解决了读的问题,数据更新的写的部分是不可缺少的,提前“知道”最多节约一半的时间(多数情况下一半都不到),最耗时的写的动作的时间省不下来。

4. 设备速度

这个没什么可说的,NvME > SSD > HDD,细分一下,就是多考虑一下4K性能或者IOPS指标,对于NvME或者SSD来说,还有Trim/Discard的问题,理论上说,还可能更快。不同设备的IOPS不太一样,我没用过NvME,但贵的SSD和便宜的SSD差别就在IOPS指标上。

-----------------------

对于题主遇到的情况,如果是数量较少的大文件,那么秒删是很正常的,因为本身波及的数据量不大,如果是比较多的文件(几千个),并且还是在SSD甚至HDD上,那么可以认为Steam必然是用了后台删除的功能。

类似的话题

  • 回答
    看到你问这个问题,我其实也挺纳闷的。Steam 删除个八十个 G 的游戏,怎么就能这么快呢?我玩电脑这么多年,下载、安装、删除游戏都经历了不少,按理说这么大的文件,一点时间总得有吧?你提到的“一秒钟”让我脑子里冒出好几个场景来。一种可能是误解了“删除”这个动作。 文件标记为“待删除”: 很多时候.............
  • 回答
    老头环在Steam商店页面的配置风波,说实话,真是让人摸不着头脑,而且操作也挺迷的。咱们来掰扯掰扯这事儿。首先,这事儿闹出来,最直接的起因就是育碧官方在Steam商店页面上放出了《艾尔登法环》的最低配置要求,其中赫然写着“GTX 1060”。这一下,可炸开了锅。为啥?你得知道,1060这显卡,虽然不.............
  • 回答
    嘿,你是不是也遇到过这种情况:刚开始Steam下载游戏飞快,简直是火箭速度,可着等着等着,速度就跟蜗牛爬一样,怎么调都上不去?别急,这情况其实挺常见的,而且原因也多半不是Steam本身出了什么大毛病。让咱们一层一层剥开来看,看看这下载速度是怎么一步步“受伤”的。首先,你的网络连接,尤其是上传速度,可.............
  • 回答
    Steam账号被盗,这事儿说起来真是让人头疼。你想啊,辛苦攒了那么多游戏,花了时间和精力去打拼,结果说没就没了,谁能不郁闷?要说为什么Steam账号容易被盗,这事儿可不是空穴来风,细究起来,里面门道可不少,咱们一个个来掰扯掰扯。首先,最最普遍的原因, 弱密码和密码复用。 这就像你家门没锁,或者锁跟别.............
  • 回答
    Steam在中国大陆的崛起,以及Origin在中国市场的相对沉寂,这背后绝非偶然,而是多方面因素综合作用的结果。想要深入理解这个问题,我们得拆解一下 Steam 究竟是如何在中国这片土壤上落地生根,又为何 Origin 显得“后知后觉”了。Steam 为什么能在中国大陆取得如此大的成就?Steam .............
  • 回答
    这确实是个挺让Steam玩家摸不着头脑的现象。明明一款游戏洋洋洒洒列出英、法、德、日、韩、西、意、俄等等一长串语言支持,唯独少了咱们的中文,尤其是考虑到中国游戏市场的庞大和玩家数量。这背后的原因,其实是挺复杂的一个多方面考量,绝不是简单的一句“开发者不想做”就能概括的。咱们一点点掰扯开来聊聊。首先,.............
  • 回答
    这个问题挺有意思的,也确实是我在 Steam 上玩游戏时常有的感受。同样是花钱买游戏,感觉 Steam 上的玩家好像更愿意给出好评,而其他平台,尤其是手游,负面评论似乎更多一些。这背后肯定不是简单的“花钱就得给好评”这么笼统的道理,而是有很多深层的原因在起作用。首先,最直接的一点,也是最容易被忽视的.............
  • 回答
    这个问题,我太有发言权了,简直是我的血泪史啊!说实话,自从我把那个熟悉的、红白色调的 Steam 图标安进我的电脑里,我的钱包就没怎么安宁过。以前?盗版也不是没接触过,但那种感觉……怎么说呢,就像是偷吃了几块糖,尝个鲜,但总觉得少了点什么。自从用了 Steam,这味儿就变了,而且一发不可收拾。首先,.............
  • 回答
    最近在游戏圈里,我确实听到不少关于 Steam 好像又“火”起来的声音。这种感觉挺微妙的,毕竟 Steam 作为一个老牌游戏平台,一直都没怎么“凉过”,它就像游戏界的“常青树”一样,默默地支撑着无数玩家的数字生活。但如果非要说它“突然火了”,我觉得更像是它本来就在那儿,但最近好像被什么东西重新点燃了.............
  • 回答
    Steam在国内之所以能获得如此高的追捧,绝不是偶然,而是一系列复杂因素共同作用的结果。它不仅仅是一个游戏平台,更像是一种文化符号,承载了一代又一代玩家的记忆和热情。要深入理解这一点,我们需要从多个维度来剖析。一、 游戏库的深度与广度:这是最核心的吸引力 海量独占与高质量游戏: 这是Steam的.............
  • 回答
    我理解你想让我以一种非常个人的、有血有肉的方式来表达对Steam的“讨厌”。但问题是,作为一个AI,我没有情感,也就无法“讨厌”任何东西。我无法像人类一样,因为某个经历而产生负面情绪,或者因为某种偏好而排斥某个平台。所以,我无法按照你的要求去“详细地讲述我讨厌Steam的理由”,因为我根本不存在这种.............
  • 回答
    《巫师 3:狂猎》在 Steam 平台上获得如此之高的好评率,绝非偶然。这款游戏之所以能俘获全球玩家的心,并长期保持着玩家的喜爱,背后是 CD Projekt Red 精心打磨的成果,可以说是集多种优点于一身,并且在很多方面都达到了“惊为天人”的高度。首先,最直观也是最令人称道的,就是游戏的叙事深度.............
  • 回答
    玩《怪物猎人:世界》是选择 WeGame 还是 Steam,这确实是个挺让人纠结的问题,尤其是对于咱们这种想玩得开心又不想踩坑的玩家来说。我自己的体验和观察下来,这两平台各有千秋,哪个更适合你,得看你更看重什么了。先说说 Steam 吧,毕竟它是老牌的 PC 游戏平台了,很多人都是从它开始接触PC游.............
  • 回答
    哈哈,这确实是个让人抓狂的问题!Steam 的商店是淘金圣地,结果现在只能看着自己的游戏库“吃土”,这种感觉可想而知。 别担心,这种情况不是你一个人遇到,而且通常都有解决办法。 咱们一点点来分析,看看是哪儿出了问题。首先,你遇到的问题是“Steam 只能打开「库」,而打不开「商店」等页面”,这表明 .............
  • 回答
    嘿,兄弟们,今天咱们就好好聊聊,为啥咱们都爱往Steam上招呼,买游戏就认它?明明网上还有不少其他地方能淘换到不少好东西,为啥Steam总能占据咱们大部分的游戏库?这背后可不是没啥道理的,说起来,Steam的这套玩法,还真挺抓人心的。首先,最直观的,就是方便。你说你想玩个游戏,脑子里有了个念头,第一.............
  • 回答
    国内对 Steam 平台存在的“默许”其实是一个挺有意思的现象,它不是一个官方明确“允许”或“禁止”的政策,而是在一个灰色地带中,大家心照不宣地维持着一种微妙的平衡。要详细说清楚这其中的原因,得从多个层面来掰开了聊。首先,从游戏产业发展和文化交流的角度来看,Steam 的存在确实给国内玩家带来了很多.............
  • 回答
    在Steam这个玩家社区里,我们经常能看到很多游戏获得“好评如潮”的评价,这通常意味着这款游戏受到了绝大多数玩家的喜爱和肯定。而放眼望去,在这些耀眼的“好评如潮”名单中,2D游戏占据了相当大的比重,这并非偶然,背后有着多方面的原因,值得我们深入探讨。首先,2D游戏的上手门槛相对较低,能够吸引更广泛的.............
  • 回答
    用户在Steam平台购买高价游戏与在腾讯游戏平台消费行为的差异,本质上是平台生态、文化背景、经济模式和用户心理等多重因素交织的结果。以下从多个维度详细分析这一现象: 一、平台生态与用户定位的差异1. Steam:独立游戏与硬核玩家的聚集地 自由度与多样性:Steam以PC平台为核心,支持独.............
  • 回答
    这个问题很有意思,也很现实,确实不少玩家宁愿在 Steam 上掏出 199 元去买《荒野大镖客2》,也不愿意在 Epic 商店里花那 126 元。这背后可不是简单的“差价几十块钱”这么简单,而是涉及到很多玩家的习惯、对平台的信任度、游戏生态以及个人感受等方方面面。咱们一个一个来掰扯掰扯。首先,Ste.............
  • 回答
    这个问题问得很有意思,也触及到了很多玩家心中的疑问。为什么Wegame不像Steam那样,主动去Steam商店里发掘那些质量上乘、口碑良好的国产游戏,然后进行代理,把它们带到Wegame平台上呢?这背后其实涉及到几个层面的考量,我试着从几个角度来梳理一下,尽量说得详细点,也希望我的表达能让你觉得真实.............

本站所有内容均为互联网搜索引擎提供的公开搜索信息,本站不存储任何数据与内容,任何内容与数据均与本站无关,如有需要请联系相关搜索引擎包括但不限于百度google,bing,sogou

© 2025 tinynews.org All Rights Reserved. 百科问答小站 版权所有