[SOLVED] gvfs: USB transfer slow

[GekkoP]

Just upgraded Elektra to 3.11-2.towo-siduction-686-pae. Besides binutils, the kernel is the only thing that got upgraded.

I'm trying to copy a 769MB mp4 file on a FAT32 USB stick (USB 2.0). It's taking more than 1 hour.
USB stick works fine, also Elektra was doing fine with every USB sticks I plugged in. So, I suppose it is kernel related.

Can anyone else confirm?

[dkeg]

there are probably others here that can speak better to this, however, I would not think this is kernel related. Had you done the same prior with the previous version kernel?

Why not boot into a different kernel and copy your file to verify? Maybe the problem lies elsewhere.

[GekkoP]

Yes, as I said above, Elektra was copying files to any of my USB sticks with no issues at all. I even copied to an external hd 120GB of videos with no problem.

This on linux noob pointed me to blame the kernel.

[GekkoP]

Tell you what. I'll do tests with other kernels. Meanwhile, please remove this topic. I'll come back with reports if I'll find that USB works with different kernels.

[pidsley]

I just dist-upgraded my Coal32 from 3.11.1.towo to 3.11.2.towo, and I can't reproduce this problem. I used coreutils to copy a 771M file to a vfat USB, and both copies took 1m8s.

Did you dist-upgrade, or just upgrade the kernel? What are you using to copy the file?

(moved topic to BBQ support for now)

[GekkoP]

I did dist-upgrade. I used the command line, a "sudo cp". I'll try with Coal too.

[pidsley]

That's exactly what I did. I don't have an elektra install to test with.

I'm assuming you formatted the stick as vfat so you can transfer files to a windows box? I just tried the same thing with a stick formatted as NTFS -- the format was slower, but the copy was slightly faster (1m3s).

[GekkoP]

Yes, you are right. It's vfat because of windows. Since you haven't got this issue with this kernel I suppose I'm missing something else on Elektra. By the way, coreutils is up to date too.

(wrong topic title too, I'm sorry about that)

[pidsley]

Did you try Coal? What if you use NTFS on Elektra?

np about the forum and title -- the main reason I care is that some people get automatic updates when posts appear in "upgrade warnings"

[GekkoP]

Coal is working fine. Copy both to and from the same USB stick. I'll try with NTFS on Elektra.

[pidsley]

OK then not a kernel issue (unless it's kernel interacting with some other package). Next step is to try to figure out what's different between Coal and Elektra. gvfs? any other file-related packages? Are the sources.list.d files the same between both?

[GekkoP]

I just did a copy to NTFS, mounted with ntfs-3g. It went fast and everything's fine. So the problem is only fat, then. Now I have to go, I'll check gvfs and source.list.d later and let you know.

[GekkoP]

Once again, you're my saviour.
I purged everything gvfs related, and installed only the same packages Coal has. Now it is working at the speed I remember. Shame I can't remember what I did wrong, though. I'm pretty sure dist-upgrade has nothing to do with it, cause only kernel and binutils were upgraded.
I'll fix the topic title, since it is not kernel related. Thanks for the patience and the support, as always.

[pidsley]

You're welcome. I have never been able to figure out what gvfs does well -- it just seems to cause problems. I think it's supposed to automount drives and manage the trash. I'm still not sure that was the problem, but happy you got it solved.

GVFS is the virtual filesystem for the GNOME desktop, which allows users easy access to remote data via SFTP, FTP, WebDAV, SMB, and local data via Udev integration, OBEX, MTP and others.[1]

GVFS is the virtual filesystem for the GNOME desktop, which allows mounting local and remote filesystems as a user along with trash support. It is also used by file managers like Thunar.

Doesn't sound like something I need; no thank you.

[GekkoP]

Well, it's not automounting on my system, that's for sure :D.
I'll try removing it and see if it makes any difference.

[pidsley]

gvfs is installed on coal, but not "gvfs-backends" -- I remember that was the one that was causing problems with Thunar before (Thunar took forever to load the first time if that package was installed). I don't know if elektra has gvfs-backends; I'm checking.

Interesting; elektra does not have gvfs or gvfs-backends installed at all. If you had them, they probably got pulled in when you installed something else.

coal has gvfs, but not gvfs-backends. This might not have been the problem at all, or maybe it was. Who knows.

[machinebacon]

^ Hey Pidsley :)
gvfs-backends pulls in libgtk-3-0, IIRC, so i left the backends out from Coal and didn't add gvfs at all to the 'terminal-only' kinds of releases, because naturally people would manually mount in releases that have no GUI file manager.
Best would be to completely leave out gvfs, though you know, if I don't add it in those releases that have a GUI file manager, people complain they cannot access their SAMBA or remote machines, or automount USB, or whatever. I could post some links to existing threads, but - to save your an my stomach acid for something better - I won't, and you know why ;-)
Admittedly, the whole gvfs/dbus/policykit/udisks/logind-construct is a fucking mess. I would completely abandon all of these, and leave it to the user to fuck their brains up themselves.

[DebianJoe]

...because naturally people would manually mount in releases that have no GUI file manager.

Naturally....right?

[machinebacon]

^ Dog created humans to manually mount drives.

[GekkoP]

Well, I'll try removing all this gvfs stuff, cause I'm used to mount drives by myself. Thanks to you all I've been using CLI more and more these days and I love it. So, if gvfs is just needed for GUI, might as well throw it away.