usb flash, drives, cameras etc

[Jerry3904]

I love the MXlinux manual. It is the best written manual on anything I have seen . Almost a tutorial on linux as well. Extremely well done.

We'll pass that on to the authors, thanks.

[cyrilus31]

I love the MXlinux manual. It is the best written manual on anything I have seen . Almost a tutorial on linux as well. Extremely well done.

We'll pass that on to the authors, thanks.

(I can't find a hilarious smiley)

[figueroa]

actually that isn't true. its very possible that the file operation as far as the OS is concerned is finished, but its actually still in a cached state waiting to be completed on the usb.

its tough to make that delay shorter without making the copy operation longer, IIRC.

Not meaning to be difficult, but I experience no delay in being able to unmount a USB flash drive after writing to it. It will unmount and/or eject as fast I can point and click once the copy operation is done.

[figueroa]

figueroa - thanks. My usb flash is a bog standard samsung bar - formatted ntfs. And I dont think I have done any messing about with settings on the usb. Encouraging to hear that the 2 minute delay to unmount is not standard behavior - I 'll need to keep working on it.

A bog standard flash drive isn't formatted NTFS. You should expect a FAT formatted flash drive to mount itself in a few seconds.

On the cameras - I tried my wife's canon powershot and my Fuji X... - shotwell seems to handle it fine, but none of the others ( i tried gthumb, rapid-photo-downloader and darktable). And the camera still does not show up at all in my spacefm file manager.

My more or less standard cameras mount themselves and show up in Thunar. one of them is a Canon EOS sxi SLR. My MX installation is near pristine.

BTW, the main (almost only) reason Thunar is sometimes slow to open is because there is a problem with a mounted drive or partition. The only reason it will open more than one instance is because it is selected more than once. This kind of thing also affects other file managers and any other program inspecting your mounts to varying degrees.

ADDED: a few cameras even present themselves as a standard flash drive. I seldom plug in the camera. I almost always pull the flash card and deal with that directly through the file manager or (usually) the terminal.

[rs55]

OK - I reformatted my 64 GB samsung bar flash to FAT32. Then I copied 11 GB of data on to it (took about 4 minutes). Then I ejected it. It then took 3 minutes and 40 seconds before it would eject.
There is definitely something that needs to be tweaked. Linux Mint does not do this. Maybe it has to do with file sizes? Buffering? No clue. Its probably some parameter that is not set correctly in the disk copy mechanism.

[rs55]

I have been running the liquorix kernel 4.20... . So for fun, I went back to the basic 4.9 kernel and tried the same operation, FAT32. The copy took 7:30 , but the eject was instantaneous.
So, there seems to be the expected behavior with kernel 4.9.

The overall time : copy+eject seems to be about the same., in all cases and with NTFS or FAT32.

So, I am going to stay with FAT32, and kernel 4.9. Its more important to me that the eject is fast.

[BitJam]

OK - I reformatted my 64 GB samsung bar flash to FAT32. Then I copied 11 GB of data on to it (took about 4 minutes). Then I ejected it. It then took 3 minutes and 40 seconds before it would eject.
There is definitely something that needs to be tweaked. Linux Mint does not do this. Maybe it has to do with file sizes? Buffering? No clue. Its probably some parameter that is not set correctly in the disk copy mechanism.

Yes, this sounds like a buffering problem. The default buffer sizes on Linux are way too large. The live-usb-maker programs run the following command to reduce the buffers to a reasonable size:

Code: Select all

sysctl vm.dirty_bytes=20000000

As a side benefit, this also increases the overall speed of transfers to usb devices by 5% to 10%. Try running that command (with sudo) before doing the copy and see if the situation improves. If it does then put the command in your /etc/rc.local file.

BTW: I use system monitors (conky and gkrellm) that show me graphs of cpu usage, disk IO, and network usage. If you are curious about stuff like this then these monitors are invaluable. Otherwise it is like driving with your windshield painted black. For example, a graph of the disk IO would have shown that the writing didn't stop when the copy command did. You would have seen it continue until the eject finally completed.

[chrispop99]

Out of interest, are you able to try other USB sticks to see if they are slow?

Transfer performance varies hugely, and is pretty much unrelated to manufacturers claims. Also, in spite of the fact that it shouldn't be the case, I have some USB 2.0 drives that perform terribly if used in USB 3.0 slots.

Chris

[rs55]

yes , I also have a 3 year old sandisk extreme pro - that runs faster than my new samsung - bar.
But still hangs around for a smoke after being ejected !

[rs55]

BitJam:
Thanks so much! That is exactly the issue I think. Been digging into this dirty-bytes business. it seems liquorix makes some drastic changes to these parameters - which explains the difference I saw.
trying out background-dirty at 100 MB and dirty at 200 MB.
My understanding of the process is as follows:
; when you initiate a disk write, the Process starts writing into ram. when it gets to 100MB ,the Flusher starts writeback
; if the ram is filled to 200MB, then the Process starts writeback directly

Now if you are operating with large amounts of data and external drives that are always attached - it makes sense to have large amounts cached and occassionally written out to disk, improving system responsiveness.
But - if you have a thumb drive, the situation is different. It is not always attached. generally you plug it in to read or write a specific file , then eject it. In this case, smaller cache makes sense.
This OS stuff is very interesting. Did I get that kinda right?