You are not logged in.
Pages: 1
Topic closed
Hi,
I'm running arch+gnome shell as DE.
When I connect a USB mass storage device (Flash drive, my phone etc.) to my PC it's auto-mounted.
But when I transfer a "lagre" file lets say 700mb the tranfer is complete in few seconds.
This is strange because my flash drive is slow and should write somthing like 5 mb/s.
this is the output from "mount" command to the flash drive:
/dev/sdd on /run/media/liran/12E8-6571 type vfat (rw,nosuid,nodev,relatime,uid=1000,gid=100,fmask=0022,dmask=0077,codepage=cp437,iocharset=iso8859-1,shortname=mixed,showexec,utf8,flush,errors=remount-ro,uhelper=udisks2)
Is this OK? Is there anything I shoul'd change? And if so where I need to make the change?
Thanks ahead guys!
Offline
It's not actually transfered, it is being copied in background. I don't know why this happens on linux, but I got used to it.
LED on the stick (if yours has one) stops blinking when transfer is complete and it's enough for me.
There is a mount flag (flush I think), which enables correct progress display, but then file operations on stick are painfuly slow.
This is why you should always unmount stick before removal.
Offline
As far as I know this is because of the delayed allocation. It means, that the data is put into the RAM first and being actually written onto the hd or stick or whatever after some time or if the stick is being unmounted or if you run "sync" in a terminal.
Offline
when I transfer
Using what app?
Offline
Files/Nautilus
Offline
Yeah, the write is cached to RAM, and is writing to the flash drive in the background. This is why you should always cleanly unmount a flash drive before removing it or rebooting.
You could add the "sync" mount option, which will write synchronously, and wait until the file is written before returning, but that will make it really slow, and is generally not a good idea with a flash drive, which according to the mount man page can shorten the write life cycle of the flash drive.
Offline
No, "sync" is wrong - he's already using flush, which is correct.
Offline
Any way to correct this behavior?
Offline
No, "sync" is wrong - he's already using flush, which is correct.
The docs say flush is not as safe as sync.
I'm guessing here:
async - stuff can be read from source but hang around in memory before being written to output (makes sense usually because it can effeciently batch up any further data that might come along), and an umount or sync command should flush it to output
flush - writes records/blocks as fast as it can, emptying memory cache
sync - writes one record/block then won't fetch/read any more until the device confirms that record has been written so much slower.
I wonder if OP has a progess bar that is based on "reads" or disk light that doesn't work correctly with usb so flush and async will both report a transfer has finished when there are still data in memory not yet written?
Offline
bump.
Anyone?
Offline
bump.
Anyone?
This is not tolerated around here. There have already been a number of responses, and actually pretty informative ones at that. If you want more help, it would be best if you tried to help yourself a little bit. Do some research to see if you can find more information, then post here to see if there is a better understanding of what you are finding out. I think the "bump" would be considered an empty post. See here. If you plan to have a continuous presence in these forums, it would probably be best if you read this entire page.
Offline
Understood.
Thank you
Offline
bump.
Anyone?
devmon (part of the udevil package) lets you mount you USB drives with sync. Using sync, the transfer progress bars will be more accurate but at the cost of speed/time.
It would up to you to decide if its worth it.
Offline
Does anybody fix it?
Devmon doesn't help for me: https://wiki.archlinux.org/index.php?ti … =no#devmon
I've got the same problem as LiranV. I'm using gnome with nautilus.
Last edited by debek (2017-03-09 21:53:24)
Offline
Your problem is that you are replying to a five year old thread: https://wiki.archlinux.org/index.php/Co … bumping.22
Closing
Offline
Pages: 1
Topic closed