Dear Opensuse Users: I’m not sure how developers think about this, and I think this may be relatively new (i.e., since OS 11.x) but nowadays, KDE (dolphin, taskbar applet) claims a removable drive is “safe to remove” sometimes 30 seconds (or more for a big write) before it’s done writing (as observed by the characteristic pattern of the thumb drive’s activity light). Dolphin shows that the drive is unmounted (file tree disappears from Dolphin, unmounted icon appears), but you can look at the flashing activity light and note the pattern for active writing for sometimes tens of seconds afterward. I’ve had several bad writes on removable media.
For this reason I stick with thumb drives which have flashing activity lights - but SD cards don’t give you this feedback - and a lot of thumb drives are doing away with the LED activity light. Windows 7+ do a better job at this - not reporting “safe to remove” until within, say, a few seconds of the flashing on the thumb drive stopping (one of the few actual system improvements from XP => W7+ ).
I’m sure someone has noticed this, and it’s just one of those hard nuts that the hardware-driver folks haven’t cracked yet.
OS 13.1x64 HP 17-e016dx AMD 5550
…then again, maybe my drivers are set up wrong… but this is a pretty vanilla 13.1 install.
Same here. Although, UDisks should be responsible for the syncing process too IMO. It has been mentioned a number of times in KDE forums (and elsewhere), but I’m not sure if there are any active bug reports dealing with this issue.
It seems like it would be a good idea to have KDE deliberately wait until a sync command has finished… But I guess that’s tricky. I don’t know if any other distros have this kind of problem. But thanks for the tip.
1: FAT format USB devices work in a fashion I would expect. And files copy over and the action is visible in the notification area. Only one the file transfer is complete does kde notify you. And the USB can be safely removed.
NTFS USB thumbs drives (I have one for large files) behave differently, at least they do on my 13.2 box. The files copy to it apparently very quickly, but if you go to safely remove, it will not do so until the transfer is actually complete - this can be several minutes depending on the file size. However, on my Laptop, which was a clean install of 13.2, the function is as with FAT and works normally.
Even when the box issues the completed transfer incorrectly and you try to eject it, the device isn’t removed UNTIL the transfer is actually complete.
My most frequent experience is with “dd_rescue”, copying an iso to a USB. If I am copying a live Rescue iso, it almost immediately tells me it is done. But it does not give the final summary line until several minutes later. I presume that’s a wait for the sync.
Mounting a regular data external drive, I use the KDE device notifier. I sometimes see a significant delay after I click the unmount option, before it tells me that it is safe to remove. So again, I presume that it is doing a sync before telling me that it is safe.
I have not run into this problem on any machines I have, so far … or, at least that I have noticed.
However, I have a tendency to do the Dolphin right-click remove of those devices when I am busy with the next step of whatever project I am on, so I usually wind up leaving the device (SD card, USB stick, or whatever) plugged in for quite awhile after the Dolphin removal.
That, of course, would explain why I have never observed this.
I appreciate the heads up this thread gives me, though. From now on, dismount then sync for those devices.
I am running OS13.1x64 KDE and just copied 3000 .png files to a Patriot XT 64GB thumb drive and watched the little notifier go round and round for about 45 seconds (and finish). The files appeared to be in the drive when viewed in Konsole, so I clicked “Safely Remove” and was told it was safe to remove the drive. But I never saw the Patriot’s LED flash, and no apparent activity in the disk Krell on GKrellm, and so I ran sync as SU in Konsole. It took ~5 minutes to get the command prompt back. I think the LED may be burnt out, but during the sync, the disk activity got up to 500K or so per second, whereas it was zero during the “Safely Remove” and copy process. Something may not be set right in the current OS implementation of KDE with regards to large copies onto removable media across USB. Don’t know about GNOME.
On Sun 14 Dec 2014 10:16:02 PM CST, PattiMichelle wrote:
I am running OS13.1x64 KDE and just copied 3000 .png files to a Patriot
XT 64GB thumb drive and watched the little notifier go round and round
for about 45 seconds (and finish). The files appeared to be in the
drive when viewed in Konsole, so I clicked “Safely Remove” and was told
it was safe to remove the drive. But I never saw the Patriot’s LED
flash, and no apparent activity in the disk Krell on GKrellm, and so I
ran sync as SU in Konsole. It took ~5 minutes to get the command prompt
back. I think the LED may be burnt out, but during the sync, the disk
activity got up to 500K or so per second, whereas it was zero during the
“Safely Remove” and copy process. Something may not be set right in the
current OS implementation of KDE with regards to large copies onto
removable media across USB. Don’t know about GNOME.
Hi
I have the same USB device They are good… my LED works fine when
copying lots of files. I use it in the USB 3.0 port with GNOME, need to
find 3000 files to copy and see how it goes, but always run sync as
well to be safe…
How big (average size) were the png files?
–
Cheers Malcolm °¿° LFCS, SUSE Knowledge Partner (Linux Counter #276890)
SUSE Linux Enterprise Desktop 12 GNOME 3.10.1 Kernel 3.12.28-4-default
If you find this post helpful and are logged into the web interface,
please show your appreciation and click on the star below… Thanks!
>> ran sync as SU in Konsole. It took ~5 minutes to get the command prompt
>> back. I think the LED may be burnt out, but during the sync, the disk
>> activity got up to 500K or so per second, whereas it was zero during the
>> “Safely Remove” and copy process. Something may not be set right in the
>> current OS implementation of KDE with regards to large copies onto
>> removable media across USB. Don’t know about GNOME.
>
> Interesting.
My guess is that if you issue a “mount”, the stick would show as still
mounted.
–
Cheers / Saludos,
Carlos E. R.
(from 13.1 x86_64 “Bottle” at Telcontar)
Update: I’m doing a big write (scores of several-MB sized mp4 files) to a USB hard drive and all is progressing as normal (i.e., the data rate to the hard drive) as well as a 1 second sync time and rapidly able to remove after a Dolphin “safely remove” operation. So maybe either something is wrong with my thumb drive, or else thumb drives are treated differently by the USB kernel/hardware driver(s) than (spinning) 3.5" hard drives? Why would that be? But, then, I do know there seem to be two different types of thumb drive. My Sandisk Extreme USB 3.0 mounts under Windows 7 as a hard drive, not a removable medium…
Update: I guess it’s the memory stick, not the Linux drivers. It looks like that Patriot memory (NTFS formatted 64GB) had more problems than just a bad LED. I replaced it with the same make/model (not having the LED might sometime result in a problem…) and now I notice that when I “safely remove” it, it starts the process, but the spinner stays spinning for several minutes in the USB notifier (for as long as the LED keeps flashing) before reporting the drive is actually “safe to remove.” On the other stick, it used to say “Safe to remove” immediately, even though sync would take several minutes to return. (Remember that I am copying about 1000 png files.)
The copy task reports “Copying [Finished]” well-before the spinner finishes. Then it spins for a while saying “Removing…” (After the LED stops flashing.) Also, the sync command returns almost immediately after the LED stops flashing. Not sure why the Device Notifier sits there saying, “Removing…” after all activity is over and I’ve typed sync and it has returned. I let it sit for about 10 minutes - it never finished.
So apparently a stick can be “defective” in the way it interacts with the linux USB/drive subsystem but still never loose files or bytes or have trouble with formatting. Go figure.
On 2014-12-21 05:16, PattiMichelle wrote:
> So apparently a stick can be “defective” in the way it interacts with
> the linux USB/drive subsystem but still never loose files or bytes or
> have trouble with formatting. Go figure.
Check the stick identifier in lsusb. There is a number for the
manufacturer, another for the unit. Compare the old one and the new. Are
the numbers the same?
It is possible that the stick firmware is different, it had a problem,
or simply that the new model is better handled by Linux.
–
Cheers / Saludos,
Carlos E. R.
(from 13.1 x86_64 “Bottle” at Telcontar)
Apparently Patriot uses Kingston memory! Here I have both sticks plugged in, a USB wireless mouse, and a SD memory stick.
patti@linux-l8th:~> lsusb
Bus 001 Device 004: ID 13fe:5500 Kingston Technology Company Inc.
Bus 002 Device 002: ID 0bda:571c Realtek Semiconductor Corp.
Bus 003 Device 002: ID 046d:c52f Logitech, Inc. Unifying Receiver
Bus 004 Device 002: ID 13fe:5500 Kingston Technology Company Inc.
Bus 001 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub
Bus 002 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub
Bus 003 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub
Bus 004 Device 001: ID 1d6b:0003 Linux Foundation 3.0 root hub
Bus 005 Device 001: ID 1d6b:0001 Linux Foundation 1.1 root hub
Bus 006 Device 001: ID 1d6b:0001 Linux Foundation 1.1 root hub
patti@linux-l8th:~>
They are good… my LED works fine when