我应该在拔下USB驱动器之前先将其卸载吗?


45

当您不卸载而拔出USB驱动器时,您的操作系统会警告您有关此设备操作的可怕程度(我在OSX上)。

我通常会遵循建议,在拔出插头之前先卸装,但是很多次(成千上万次)的情况是,在完成任务后,我只是拔下了插头(高清存储,手机等),而我从没注意到损坏的数据设备。
我很幸运,还是可以不理会这个烦人的警告?


2
由于我的数据完全是轶事,所以没有发布答案。我一直是一个系统管理员,然后约15年的软件开发人员和很多朋友是在同行业中,我不记得一个人从拔下USB设备,而无需卸载抱怨数据丢失。只需使用一些常识即可。复制/移动内容时,请勿将其拉出。
Nifle

@Nifle就是我在说的:)(实际上,我已指定“在我的任务结束时”)
systempuntoout 2010年

1
我想提供一个额外的轶事故事-在Uni实验室中,(很显然)人们会插入USB随身碟进行工作。我们没有相关的卸载权限(不要问..),在第一个词出现之后,出现了几个看起来很重要的大标志,告诉人们不要使用键盘上的USB端口,这是因为它们一直在破坏摇杆(我我个人至少知道四起事件)。但是,基本单元中的单元以相同的方式使用(没有卸载权限)似乎很好!
DMA57361 2010年

1
@ DMA57361,如果您没有卸载权限(我想知道您是如何首先安装的,那么……不好,不好的管理员),您仍然可以运行sync,等待几秒钟,然后拔下电源。
user39559 2010年

2
另一个奖项?谁是松饼雅黄油?;-)在这里,还有另一票...
Sky Sanders 2010年

Answers:


42

要么您很幸运从来没有损坏过数据,要么很不幸运从未注意到您的数据已损坏。

当您执行应在磁盘上写入的操作时,大多数操作系统会将写入操作放入队列中。他们不时刷新队列。(我在这里将其称为队列,但实际上操作可能会乱序执行,操作系统会在速度更快时给出最终结果相同的结果。)这可以使写入操作快得多,这都是因为系统会尝试在没有更好的事情要做时执行它们,因为它可以智能地对它们进行分组。

如果您在编写所有内容之前碰巧拔下设备的电源,则可能会丢失最新数据。更糟糕的是,如果操作系统无法按顺序执行操作,则可能会使设备进入不一致状态,并且丢失的数据可能超过最新数据。

对于可移动设备,某些操作系统进入更为保守(但较慢)的模式,以降低与在设备卸载之前拔出设备相关的风险。

添加
乱序操作有时不只是速度问题。廉价的闪存介质(在硬件级别上不进行扇区重新分配)对您可以在任何给定扇区上写入的次数有所限制。如果您天真地将所有更改写进去,这会杀死(V)FAT文件系统(可移动驱动器最常见的情况)中包含文件分配表的扇区或典型现代文件系统中的日志。(例如,请参见Linux Kernel邮件列表上的讨论sync。)在这里,每次写入文件时不更新FAT或日志不仅会带来很大的性能提升,而且对硬件的使用寿命也有好处。

直到最近,Linux仍在sync(写所有更改时)和async(在方便时写)之间做出选择。最新版本引入了flush用于FAT文件系统的选项,该选项介于两者之间(一旦磁盘变为非活动状态,则刷新所有延迟的写入);在Ubuntu 10.04中默认为启用。

另外,卸载可移动驱动器可确保没有应用程序打开文件。如果您没有在拔出前卸载,则直到太晚之前您都不会注意到是否有未保存的数据。在文件打开时卸载在文件系统级别(操作系统可能已将某些操作排队,直到关闭文件)和应用程序级别(例如,如果应用程序放置了锁定文件,它将不会)都增加了损坏的机会。被删除)。


3
sync安装!:D
BloodPhilia

使用日志文件系统时,这仍然是一个问题吗?
NReilingh 2010年

1
@NRei是的。如果在写入过程中出现问题,日志文件系统只会防止数据损坏。它不能防止由于根本没有进行写入而导致的损坏或数据丢失,因为在操作系统开始写入数据之前拔出了驱动器。
2010年

@BloodPhilia:sync有时候伤害不只是性能,请参阅我的编辑。
吉尔(Gilles)“所以,别再邪恶了”,2010年

2
同意-到目前为止,systempuntoout很幸运。由于在卸下闪存驱动器之前不进行卸载,因此我已经失去了很多工作。您可以将所有所需的内容保存在应用程序中,但是如果对写操作进行缓冲,那么在重要的地方就不会发生。你只会被这个烧死一次。
布莱斯

5

您面临的主要风险是书写延迟。由于各种原因,系统在通知数据时并不总是将数据写入磁盘,而是将其保存在内存中。卸载时,请确保将所有内容写入磁盘(并确保当前未使用磁盘)。您可能会知道当前是否正在写入磁盘,但是您可能没有意识到您的操作系统尚未写入您之前要求写入的所有内容。

频率取决于您的系统以及对USB驱动器的处理方式。如果卸载通常很慢,并且您可以听到驱动器发出的写入噪音,则您可能应该继续卸载。如果卸载始终是即时的,请随时跳过此步骤,后果自负。


4
我相信大多数操作系统都会为可移动驱动器禁用这种延迟写入。
杰夫·阿特伍德

@Jeff,那肯定是处理USB驱动器的明智方法。有没有办法检查?在Windows 7中?
2010年

@torbengb:实际上,这并不总是明智的-请参阅我编辑的答案
吉尔(Gilles)'所以

我的USB(如果我进入策略选项),默认情况下使用“快速删除”,在说明中说不需要“安全删除”。另一个选项是“最佳性能”,它不是默认值,但是需要您安全删除。因此,对于大多数情况,默认设置为快速删除,这意味着无需安全删除。
ComputerLocus

@Fogest,是的,但这也特定于Windows;OP正在使用OSX。当然,我确定OSX会执行类似的操作。
Synetech 2013年

4

我认为没有人解决过读写访问的问题。如果您没有将任何内容复制到闪存驱动器或打开要写入的文件,则可以安全地将其删除-如果我仅将文件从闪存驱动器复制到计算机,则通常不会是时候卸下它了。但是,如果我将文件复制到闪存驱动器,那么我确实采取了eatra步骤-是的,由于写入后过早删除闪存驱动器,导致文件损坏。


3

我在赌场工作,许多老虎机制造商现在使用USB拇指驱动器将bin文件(游戏和操作系统)安装到老虎机上。

固件损坏的老虎机可能会奖励数千美元,甚至可能不会奖励数千美元,这是极大的动机,以确保该USB驱动器上的数据完整性不会被损坏。Compliance / Regulator仍会对其进行检查,但仍然节省了第一次就可以进行的工作。

在公司环境中,数据丢失可能会造成数百万美元的损失,并且您个人可能会损失掉一些无法替代的东西。

我当然会确保卸载,安全删除或使用任何术语来确保任何带有数据的USB设备都可以安全删除。


1
但是,复制mp3来收听,并不是很多。
cgp

3

在大多数情况下,不系安全带驾驶汽车是安全的。但是当事情变得混乱时,您要感谢您使用它。

是的 即使在大多数情况下只是安全地卸下USB驱动器而无需卸载它,绝对不建议这样做。


3

当写入驱动器时,我已经看到过早地将其卸除而导致损坏。虽然操作系统不会正常保存未写入的数据,但是XP至少会接受备份的写入请求。

我曾有人将文件复制到闪存驱动器上,一旦复制完后在屏幕上立即将文件交给我-文件已损坏。

在某些东西也已经完成复制到闪存驱动器之后,我已经看到写入灯闪烁了几秒钟。


2

如果系统正在磁盘上执行文件操作,则有可能损坏数据。由于它从未发生在您身上,因此您很幸运。使用常识来确定您的操作系统是否有机会执行操作。(驱动器中是否有正在打开/使用的程序/文件?驱动器上是否有缓存?索引了吗?操作系统是否在其中存储临时文件?)


2

轶事证据,不是证据,但由于USB断开连接,我的数据损坏了,但这仅发生在Blackberry手机上。


2

相信我,是的。

您可能没有什么可以访问USB驱动器,但实际上是什么。这样,我已经丢弃了3个外部备份硬盘,并且丢失了近2 TB的数据。

始终在拔出插头之前先卸下。


哇3 HDD真是倒霉。
systempuntoout 2010年

3
@systempuntoout:“一旦有趣,它就傻了两次,值得一击打三遍。” 在头几起事件之后,您可能想要比“倒霉”看起来更深。
克里斯·伯吉斯

1

卸下它是安全的(如果您完全偏执),但是如上所述,数据丢失主要是由于写入延迟所致。

但是还有另一件事,那就是我的WD Essentials便携式驱动器。如果我只是在没有干净安装的情况下拔下电源插头,则下次将其插入时,驱动器将变为只读状态。我必须重新启动驱动器中的PC,以使其再次可写..绝对令人讨厌!


0

Windows 10系统上的另一种情况是,当系统处于休眠状态时,物理上卸下了(此处为64 Gb,没有readyboost)闪存驱动器。从休眠状态启动系统软件后,对闪存棒上任何更改的文件进行移动或复制可能会导致文件或目录损坏以及无法读取的错误。
要绕过该错误(以及产生一个或两个chk片段的必要chkdsk操作,并“恢复”原本非常健康的驱动器),我们尝试right_click_on_drive_to_eject或卸下该存储棒。很好,但是当用户随后在“设备”中禁用/启用该驱动器时,该驱动器将不会出现在任何资源管理器窗口中,并且在“ 磁盘管理”中仍显示为“ 无介质”。完全重新连接设备的唯一方法是简单地物理断开并重新连接设备。
因此,最好先拔下设备,然后再拔出电源。

By using our site, you acknowledge that you have read and understand our Cookie Policy and Privacy Policy.
Licensed under cc by-sa 3.0 with attribution required.