Not in Windows 10/11. You can still “eject” if it makes you feel better, but it’s basically redundant. They reworked the support for removable media so they are always ready to remove except during active read/write operations.
Read/write operations can happen in the background at any moment as long as the drive is mounted, so that’s not terribly comforting.
Anyway, Windows has always avoided deferring writes on removable media, for as long as it’s been capable of deferring writes at all. That’s not new in Windows 10.
Linux has a mount option, sync, to do the same thing. Dunno if any desktop environments actually use it, but they could. Besides being slower, though, it has the downside of causing more write operations (since they can’t be batched together into fewer, larger writes), so flash drives will wear out faster. I imagine Windows’ behavior has the same problem, although with Windows users accustomed to pulling out their drives without unmounting, I suppose that’s the lesser of two evils.
On Windows, I often simply took out the USB drive without “safely removing” it. The data was there 99% of the time. On Linux, if I’m not mistaken, unmounting the drive before disconnecting is what actually writes data to it.
I don’t think Linux literally waits for you to unmount the drive before it decides to write to it. It looks like that because the buffering is completely hidden from the user.
For example say you want to transfer a few GB from your SSD to a slow USB drive. Let’s say:
it takes about half a minute to read the data from the SSD
it takes ten minutes to write it to the USB
the data fits in the spare room you have in RAM at the moment
In this scenario, the kernel will take half a minute to read the data into the RAM and then report that the file transfer is complete. Whatever program is being used will also report to the user that the transfer is complete. The kernel should have already started writing to the drive as soon as the data started being read into the RAM, so it should take another nine and a half minutes to complete the transfer in the background.
So if you unmount at that point, you will have to wait nine and a half minutes. But if you leave it running and try to unmount ten minutes later it should be close to instant. That’s because the kernel kept on writing in the background and was not waiting for you to unmount the drive in order to commit the writes.
I’m not sure but I think on Windows the file manager is aware of the buffering so this doesn’t happen, at least not for so long. But I think you can still end up with corrupted files if you don’t safely remove it.
Unmounting removable drives after writing to then is crucially more important than on Windows
It’s pretty important on Windows too, though. Always “eject” or “safely remove hardware” before unplugging!
Not in Windows 10/11. You can still “eject” if it makes you feel better, but it’s basically redundant. They reworked the support for removable media so they are always ready to remove except during active read/write operations.
Read/write operations can happen in the background at any moment as long as the drive is mounted, so that’s not terribly comforting.
Anyway, Windows has always avoided deferring writes on removable media, for as long as it’s been capable of deferring writes at all. That’s not new in Windows 10.
Linux has a mount option,
sync, to do the same thing. Dunno if any desktop environments actually use it, but they could. Besides being slower, though, it has the downside of causing more write operations (since they can’t be batched together into fewer, larger writes), so flash drives will wear out faster. I imagine Windows’ behavior has the same problem, although with Windows users accustomed to pulling out their drives without unmounting, I suppose that’s the lesser of two evils.How so?
On Windows, I often simply took out the USB drive without “safely removing” it. The data was there 99% of the time. On Linux, if I’m not mistaken, unmounting the drive before disconnecting is what actually writes data to it.
I don’t think Linux literally waits for you to unmount the drive before it decides to write to it. It looks like that because the buffering is completely hidden from the user.
For example say you want to transfer a few GB from your SSD to a slow USB drive. Let’s say:
In this scenario, the kernel will take half a minute to read the data into the RAM and then report that the file transfer is complete. Whatever program is being used will also report to the user that the transfer is complete. The kernel should have already started writing to the drive as soon as the data started being read into the RAM, so it should take another nine and a half minutes to complete the transfer in the background.
So if you unmount at that point, you will have to wait nine and a half minutes. But if you leave it running and try to unmount ten minutes later it should be close to instant. That’s because the kernel kept on writing in the background and was not waiting for you to unmount the drive in order to commit the writes.
I’m not sure but I think on Windows the file manager is aware of the buffering so this doesn’t happen, at least not for so long. But I think you can still end up with corrupted files if you don’t safely remove it.
That can be configured with the
syncoption ofmount.Or just
syncbefore pulling it.Really? I’ve literally never done this but I suppose I really only use my USB for dd’ing a distro.
deleted by creator
Yeah, but you just describe 2 features on specific apps that don’t need to be enabled by default.
deleted by creator