6 ms·

If he could get the drive eject button to unmount the SD card, this would actually be more functional that current tech. It bugs me that unmounting SD cards /

by dcw303 11y ago

If he could get the drive eject button to unmount the SD card, this would actually be more functional that current tech. It bugs me that unmounting SD cards / USB drives and physically removing it are two seperate actions. It's a regression in usability after floppies and CD-ROMs.

GigabyteCoin 11y ago
What a great point. I am so paranoid now about removing USB drives after I accidentally removed one while it was still writing to the drive (which I had no idea because there was no LED on the drive) and it bricked the entire device. I generally wait until my computer has shutdown completely now before removing any important drives, just to be sure.
- ossreality 11y ago
  lol, push eject, wait a few seconds for the notification, remove device. oh right, you're probably using windows.
- derefr 11y ago
  Generally if I'm worried about completing a write, I'll just open a Terminal and type `sync` (with a `&& sudo purge` on OSX), and then, as soon as that returns, yank the drive. I don't even bother to unmount it; what would unmounting add, if the OS can recognize that the device is gone and clean up its mount tables? Is there some filesystem that waits until unmount to recalculate indexes or something? (Okay, sure, the OS could tell me the disk is in use because I've got an overlay filesystem mounted on top of it, and would I kindly wait forever for that to stop being the case. But screw you, OS, I need this USB. Just send the FUSE server or SMB daemon or whatever a SIGPIPE.)
  - andrewaylett 11y ago
    Filesystems often have a 'dirty' flag which is cleared as the very last write when unmounting cleanly, to let the OS know whether the filesystem might need to be checked before mounting it next time. Also, unmounting helps you to be confident that nothing's started doing more IO since you ran sync.
  - whyagaindavid 11y ago
    I use this bash script to a umount with a shortcut key. Using KDE. (bad formatting in hn) #!/bin/bash for i in `ls /media/$USER` do cd /media/$USER umount $i done ls /media/$USER |grep -v cdrom0 |grep -v cdrom> /tmp/disk_status file=/tmp/disk_status if [ ! -s $file ]; then kdialog --passivepopup "Nothing Mounted " 1 else kdialog --passivepopup "Mounted devices: `cat /tmp/disk_status`" 2 fi
kalleboo 11y ago
I remember when Apple had the soft-eject floppy drives that would only eject after the disk was properly unmounted, and then they even did soft-eject PCMCIA slots. I was surprised when their SD card slots weren't soft-eject.
- stormbrew 11y ago
  This was great until your Mac decided that it didn't want to unmount that disk for some reason. And then you got out a paperclip.
  - PhasmaFelis 11y ago
    I actually remember frantically searching through my uncle's Mac manual after I inserted a corrupt boot disk (or possibly not a boot disk at all) and then couldn't get the thing to boot, which meant I couldn't use the soft eject. Fortunately the paperclip trick was in there.
  - minikites 11y ago
    Before resorting to a paper clip, the trick was to reboot while holding the mouse button. This still works today with CDs if the CD is damaged and the OS gets caught up trying to read it.
- derefr 11y ago
  The external-USB "Superdrive" optical drive is still soft-eject, when it's got a rewritable CD in there.
- WWLink 11y ago
  I don't remember soft eject slots, my powerbook g4 had a button, and I think the expresscard slots on later macbooks just used the same kinda mechanism sd cards use.
josteink 11y ago
> If he could get the drive eject button to unmount the SD card, this would actually be more functional that current tech. It bugs me that unmounting SD cards / USB drives and physically removing it are two seperate actions. To be fair, this was always a problem, also with old computers and OSes. There was no link between pressing eject and magical things happening in the machine to commit data. The data was simply already committed so there was no need to have any additional layers of security. The difference between then and now is that new computers have enormous amounts of memory and use it to provide write-back caching. This means the OS can tell applications that data is committed when it's not. This is an OS level decision which is done for performance and has nothing to do with the physical eject-buttons on your devices. You may call this a small nit, but I think it's an important one. The eject-button on old machines would suffer the exact same problems if it used an OS which offered write-back cache. You could say old Macs didn't have this problem, which is true. But it didn't have an eject-button. It relied on the OS doing that. And then instead you had the problem of people not being able to get their disks out of their machines if the OS for some reason refused to release it (or that users didn't realize they had to drag the disk-icon to trash).
- timthorn 11y ago
  The eject-button on old machines /did/ suffer the exact same problems - removing the disk whilst the activity LED was illuminated rarely ended well!
  - viraptor 11y ago
    I just remembered that even hard drives at some point had similar issues. Remember to park your heads before power off!
    - josteink 11y ago
      Good catch! I had completely forgotten about that one. For those completely oblivious to this: This was actually not about getting data written to disk, but to physically protect the drive from its own mechanical construction. The "park" command would cause the harddrive to move its magnetic read and write-heads away from the internal platters, so that when it was powered down and the disks stopped spinning, the platters would not be damaged or experience needless tear and wear. Yeah, I'm glad we no longer have to do that exercise.
digi_owl 11y ago
I really wish there had been a bigger push towards some kind of standardized packet writing for DVDRW (CDRW had this issue with a one use calibration track), so that they could behave more like floppies (drag and drop file transfers etc). The media itself is fully passive, while a SD card or thumbdrive have logic sitting between the USB interface and the raw flash. Thus optical media can be "rescued" by simply getting a new drive. And you really need to mistreat a optical disc to make it completely unreadable. Or perhaps someone could buy the minidisc tech off Sony and resurrect magnet-optical storage?
- ashmud 11y ago
  Light reading about optical disc packet writing for anyone new the subject: https://en.wikipedia.org/wiki/Mount_Rainier_%28packet_writing%29 https://en.wikipedia.org/wiki/Mount_Rainier_%28packet_writin...
rikkus 11y ago
On Windows, they're mounted sync by default, so you can just remove them. Of course, if you do so while it's writing, you'll have a problem - though this was the same with floppies. Windows used to require you to 'eject' but doesn't any more, which I think is due to the above. Please correct me if I'm wrong.
- zamalek 11y ago
  It is only required if you enabled write-caching for removable media. As far as I know this has never been enabled by default.
  - JupiterMoon 11y ago
    By windows. I'm not sure what parted/gparted defaults to.
    - digi_owl 11y ago
      I think they go with a write cache. I recall some distros tried to mount USB drives with the sync option back in the early days of USB media. Problem was that this, in combo with FAT, would basically kill cheap drives lacking wear leveling. This because every write action was accompanies with a allocation table update. And thus whatever flash cells housed that table would see a massive amount of writes. Actually i think the mount man file still have a warning about this in the sync option entry.
      - JupiterMoon 11y ago
        So this implies that even in windows one needs to safely unmount external media that were originally formatted using parted/gparted?
        pjc50 11y ago
        No, the write caching is a function of whatever's reading the thing, not the format.

by dcw303 11y ago

GigabyteCoin 11y ago

What a great point. I am so paranoid now about removing USB drives after I accidentally removed one while it was still writing to the drive (which I had no idea because there was no LED on the drive) and it bricked the entire device. I generally wait until my computer has shutdown completely now before removing any important drives, just to be sure.

ossreality 11y ago
lol, push eject, wait a few seconds for the notification, remove device. oh right, you're probably using windows.
derefr 11y ago
Generally if I'm worried about completing a write, I'll just open a Terminal and type `sync` (with a `&& sudo purge` on OSX), and then, as soon as that returns, yank the drive. I don't even bother to unmount it; what would unmounting add, if the OS can recognize that the device is gone and clean up its mount tables? Is there some filesystem that waits until unmount to recalculate indexes or something? (Okay, sure, the OS could tell me the disk is in use because I've got an overlay filesystem mounted on top of it, and would I kindly wait forever for that to stop being the case. But screw you, OS, I need this USB. Just send the FUSE server or SMB daemon or whatever a SIGPIPE.)
- andrewaylett 11y ago
  Filesystems often have a 'dirty' flag which is cleared as the very last write when unmounting cleanly, to let the OS know whether the filesystem might need to be checked before mounting it next time. Also, unmounting helps you to be confident that nothing's started doing more IO since you ran sync.
- whyagaindavid 11y ago
  I use this bash script to a umount with a shortcut key. Using KDE. (bad formatting in hn) #!/bin/bash for i in `ls /media/$USER` do cd /media/$USER umount $i done ls /media/$USER |grep -v cdrom0 |grep -v cdrom> /tmp/disk_status file=/tmp/disk_status if [ ! -s $file ]; then kdialog --passivepopup "Nothing Mounted " 1 else kdialog --passivepopup "Mounted devices: `cat /tmp/disk_status`" 2 fi

kalleboo 11y ago

I remember when Apple had the soft-eject floppy drives that would only eject after the disk was properly unmounted, and then they even did soft-eject PCMCIA slots. I was surprised when their SD card slots weren't soft-eject.

stormbrew 11y ago
This was great until your Mac decided that it didn't want to unmount that disk for some reason. And then you got out a paperclip.
- PhasmaFelis 11y ago
  I actually remember frantically searching through my uncle's Mac manual after I inserted a corrupt boot disk (or possibly not a boot disk at all) and then couldn't get the thing to boot, which meant I couldn't use the soft eject. Fortunately the paperclip trick was in there.
- minikites 11y ago
  Before resorting to a paper clip, the trick was to reboot while holding the mouse button. This still works today with CDs if the CD is damaged and the OS gets caught up trying to read it.
derefr 11y ago
The external-USB "Superdrive" optical drive is still soft-eject, when it's got a rewritable CD in there.
WWLink 11y ago
I don't remember soft eject slots, my powerbook g4 had a button, and I think the expresscard slots on later macbooks just used the same kinda mechanism sd cards use.

josteink 11y ago

> If he could get the drive eject button to unmount the SD card, this would actually be more functional that current tech. It bugs me that unmounting SD cards / USB drives and physically removing it are two seperate actions. To be fair, this was always a problem, also with old computers and OSes. There was no link between pressing eject and magical things happening in the machine to commit data. The data was simply already committed so there was no need to have any additional layers of security. The difference between then and now is that new computers have enormous amounts of memory and use it to provide write-back caching. This means the OS can tell applications that data is committed when it's not. This is an OS level decision which is done for performance and has nothing to do with the physical eject-buttons on your devices. You may call this a small nit, but I think it's an important one. The eject-button on old machines would suffer the exact same problems if it used an OS which offered write-back cache. You could say old Macs didn't have this problem, which is true. But it didn't have an eject-button. It relied on the OS doing that. And then instead you had the problem of people not being able to get their disks out of their machines if the OS for some reason refused to release it (or that users didn't realize they had to drag the disk-icon to trash).

timthorn 11y ago
The eject-button on old machines /did/ suffer the exact same problems - removing the disk whilst the activity LED was illuminated rarely ended well!
- viraptor 11y ago
  I just remembered that even hard drives at some point had similar issues. Remember to park your heads before power off!
  - josteink 11y ago
    Good catch! I had completely forgotten about that one. For those completely oblivious to this: This was actually not about getting data written to disk, but to physically protect the drive from its own mechanical construction. The "park" command would cause the harddrive to move its magnetic read and write-heads away from the internal platters, so that when it was powered down and the disks stopped spinning, the platters would not be damaged or experience needless tear and wear. Yeah, I'm glad we no longer have to do that exercise.

digi_owl 11y ago

I really wish there had been a bigger push towards some kind of standardized packet writing for DVDRW (CDRW had this issue with a one use calibration track), so that they could behave more like floppies (drag and drop file transfers etc). The media itself is fully passive, while a SD card or thumbdrive have logic sitting between the USB interface and the raw flash. Thus optical media can be "rescued" by simply getting a new drive. And you really need to mistreat a optical disc to make it completely unreadable. Or perhaps someone could buy the minidisc tech off Sony and resurrect magnet-optical storage?

ashmud 11y ago
Light reading about optical disc packet writing for anyone new the subject: https://en.wikipedia.org/wiki/Mount_Rainier_%28packet_writing%29 https://en.wikipedia.org/wiki/Mount_Rainier_%28packet_writin...

rikkus 11y ago

On Windows, they're mounted sync by default, so you can just remove them. Of course, if you do so while it's writing, you'll have a problem - though this was the same with floppies. Windows used to require you to 'eject' but doesn't any more, which I think is due to the above. Please correct me if I'm wrong.

zamalek 11y ago
It is only required if you enabled write-caching for removable media. As far as I know this has never been enabled by default.
- JupiterMoon 11y ago
  By windows. I'm not sure what parted/gparted defaults to.
  - digi_owl 11y ago
    I think they go with a write cache. I recall some distros tried to mount USB drives with the sync option back in the early days of USB media. Problem was that this, in combo with FAT, would basically kill cheap drives lacking wear leveling. This because every write action was accompanies with a allocation table update. And thus whatever flash cells housed that table would see a massive amount of writes. Actually i think the mount man file still have a warning about this in the sync option entry.
    - JupiterMoon 11y ago
      So this implies that even in windows one needs to safely unmount external media that were originally formatted using parted/gparted?
      - pjc50 11y ago
        No, the write caching is a function of whatever's reading the thing, not the format.