Slashdot Mirror
Slashdot Asks: Do You Need To Properly Eject a USB Drive Before Yanking it Out? (daringfireball.net)
In a story earlier this week, Popular Science magazine explored an age-old topic: Do people need to safely eject a USB stick before they pull it from their computer? The magazine's take on it -- which is, as soon any ongoing transfer of files is complete, it is safe to yank out the flash drive -- has unsurprisingly stirred a debate. Here's what the magazine wrote: But do you really need to eject a thumb drive the right way? Probably not. Just wait for it to finish copying your data, give it a few seconds, then yank. To be on the cautious side, be more conservative with external hard drives, especially the old ones that actually spin. That's not the official procedure, nor the most conservative approach. And in a worst-case scenario, you risk corrupting a file or -- even more unlikely -- the entire storage device. To justify its rationale, the magazine has cited a number of computer science professors. In the same story, however, a director of product marketing at SanDisk made a case for why people should probably safely eject the device. He said, "Failure to safely eject the drive may potentially damage the data due to processes happening in the system background that are unseen to the user."
John Gruber of DaringFireball (where we originally spotted the story), makes a case for why users should safely eject the device before pulling it out: This is terrible advice. It's akin to saying you probably don't need to wear a seat belt because it's unlikely anything bad will happen. Imagine a few dozen people saying they drive without a seat belt every day and nothing's ever gone wrong, so it must be OK. (The breakdown in this analogy is that with seat belts, you know instantly when you need to be wearing one. With USB drives, you might not discover for months or years that you've got a corrupt file that was only partially written to disk when you yanked the drive.)
I see a bunch of "just pull out the drive and not worry about it" Mac users on Twitter celebrating this article, and I don't get it. On the Mac you have to do something on screen when you eject a drive. Either you properly eject it before unplugging the drive -- one click in the Finder sidebar -- or you need to dismiss the alert you'll get about having removed a drive that wasn't properly ejected. Why not take the course of action that guarantees data integrity? What are your thoughts on this? Do you think the answer varies across different file systems and operating systems?
John Gruber of DaringFireball (where we originally spotted the story), makes a case for why users should safely eject the device before pulling it out: This is terrible advice. It's akin to saying you probably don't need to wear a seat belt because it's unlikely anything bad will happen. Imagine a few dozen people saying they drive without a seat belt every day and nothing's ever gone wrong, so it must be OK. (The breakdown in this analogy is that with seat belts, you know instantly when you need to be wearing one. With USB drives, you might not discover for months or years that you've got a corrupt file that was only partially written to disk when you yanked the drive.)
I see a bunch of "just pull out the drive and not worry about it" Mac users on Twitter celebrating this article, and I don't get it. On the Mac you have to do something on screen when you eject a drive. Either you properly eject it before unplugging the drive -- one click in the Finder sidebar -- or you need to dismiss the alert you'll get about having removed a drive that wasn't properly ejected. Why not take the course of action that guarantees data integrity? What are your thoughts on this? Do you think the answer varies across different file systems and operating systems?
one should always eject before pulling out
No mention of the OS or file system. Assuming Windows - there's a setting for "Quick Removal," which disables write caching and makes it so "you can disconnect the device safely", and another for "Better Performance," which doesn't and may cause grief.
"National Security is the chief cause of national insecurity." - Celine's First Law
I can't count the number of times I've tried to eject a USB drive, and Mac OS tells me it's "unable to eject the drive because it's in use."
Usually it's because Preview.app held onto some file descriptor for its stupid thumbnail of recent documents - not the list in the file menu, the one that pops up when you right-click on Preview in the Dock.
Apple used to promote the idea that the user is in charge. When I click "eject," the damn thing should eject!
What is "âoesyncâ"? [1]
Even if you do type sync before ejecting, that doesn't keep some other process from opening and writing another file on the volume in the seconds between when you type sync and when you actually pull the plug. To prevent the possibility of corruption, you need to unmount the volume (and possibly remount it read-only) before disconnecting the drive.
[1] Rhetorical.
I used to write a lot of 8GB+ file system images to 16GB SanDisk devices using an Ubuntu 14.04 system. The caching it did was immense. The dd or the cp command finished in less than 60 seconds but when I did a umount command on the volume it would block for about 5 whole minutes or more while the cache emptied.
These particular USB drives have a blue activity LED on them so it wasn't hard to figure out what was going on.
In that use case yanking the USB would have been a big no no.
Depends how many places "confirmed" saved data can be cached in RAM.
Spinning hard drives have their own cache, which isn't written to the actual disk until either the cache is "full enough" or you instruct it to do so.
This data will be lost if you power the device down before the cache is flushed to disk, after the drive reported the data saved.
Flash sort of depends, an SSD for example tends to do the same thing, but there are different ways it can go about it.
Older SSDs can only write 4k blocks, it wasn't possible to write less data.
So to write for example 300 bytes, the controller has to pull in a 4k block to its RAM, edit those 300 bytes, and write out the entire 4k block again.
Pull power before this is done and your 300 bytes are gone.
"Removable" USB flash drives, the better ones at least, tend to not report data as saved before it really is, just to help avoid this problem. There is little hope for a non-technical person to know what their particular flash drive is doing however, and not even obvious to technical people either.
On top of that, your OS likely caches data to be written to any disk in RAM, completely independent of what the disk itself is doing.
If one is absolutely certain how all of these caches function, and can be completely assured all data is written in a method that doesn't rely on the disk claiming it is or isn't, then in that case it would be safe to power down the device.
For average and above average users, that will just not be true.
Even for experts, outside of a small set of cases like highly customized and tuned systems, it may be true the expert knows what is going on, but would tell you from that knowledge it wouldn't be safe and is a silly risk to take, with a high cost of data loss in exchange for a couple of seconds of time saved.
Hell, even I am still in the habit of issuing three 'sync' commands in a row before an unmount command, and that's despite the knowledge the unmount command will do a 'sync' call of its own!
But as this advice is for average or below people, as bad as it is, isn't the worst things commonly done.
Average or below people rarely even make backups, which has a far higher cost when (never IF) a drive fails. Corrupting a couple files on a single USB drive compared to not having any backups is like complaining your car only has 5 airbags instead of 6 while driving it off of a cliff...
Ever think of testing this for yourself?
It's easy. Create a half a dozen or more files of random numbers or use existing large files. I created six files of a million random integers in Python. End result, six files of about 6.9MB each. Create an md5 checksum file when you make them.
Copy them to a USB stick, and then yank the stick right when the light stops blinking. Plug the USB stick back in. Watch and learn. Easily reproducible phenomenon are:
* Not all files even appear when the stick is plugged back in
* Some of the files might appear, but give I/O errors and won't even be complete
* A Few might pass the checksum integrity test
I'm on Linux Mint, but I have seen the results on other OSes as well. The OS caches the data to be written sometime, presumably to speed up file operations. There's a reason why eject exists.
"What lies behind us, and what lies before us are tiny matters compared to what lies within us." Ralph Waldo Emerson
What is "ÃoesyncÃ"? [1]
A sign that Slashdot's text handling is pathetic.
"You're right," Fisheye says. "I should have set it on 'whip' or 'chop.'"
Because all it does is change the choice to "Do I eject the drive properly, or do I check to make sure "quick removal" is enabled and then yank the drive?" Unless you already know it's been set (i.e. you personally set it previously for this drive for this instance), the latter takes more time than ejecting.
The #1 cause I've seen for corruption of data/partition information on USB flash and external HDDs is yanking it out too quickly, just before the copy has finished. In theory a journaling filesystem like NTFS should be immune to damage from this. But for some reason it occasionally seems to corrupt the partition table making the entire contents of the drive inaccessible unless you're skilled enough to repair it manually (usual cause seems to be the partition type number got changed).
That's a 10 minute or so repair process if you know what you're doing. If you don't, it's probably 30-60 minutes downloading the tools and stumbling around trying to figure it out. And if you obeyed Windows when it popped up the "You need to format this disk before you can use it" message when you plugged the drive in again, and formatted it, now you're looking at several hours for file recovery with no guarantee you'll be able to recover everything. (They really need to add a second line to that message saying that formatting will destroy any existing data.)
All this risk and time wasted just to save a few seconds by not ejecting. So I advise people to always eject the drive before yanking it. The seatbelt analogy is very appropriate. It takes very little time to do, but the rare consequences if you don't do it can be devastating.