Google-drive-ocamlfuse: Mount randomly drops

[jrarseneau]

Hello,

I've been using google-drive-ocamlfuse for a few weeks now and every few days or so my mount will randomly drop. I have a gdfuse.log and curl.log file (the curl file is 17GB unfortunately).

Here's some info about my environment:

OS: Ubuntu 16.04
Kernel: 4.8.0-41-generic
google-drive-ocamlfuse version: 0.6.17
Installed from PPA

Mount options:
-cc -debug -o allow_other,ro,atomic_o_trunc,large_read,default_permissions,nonempty

Config file:

apps_script_format=json
apps_script_icon=
async_upload=true
cache_directory=
client_id=REDACTED
client_secret=REDACTED
connect_timeout_ms=5000
curl_debug_off=false
data_directory=
delete_forever_in_trash_folder=false
docs_file_extension=true
document_format=odt
document_icon=
download_docs=false
drawing_format=png
drawing_icon=
form_format=zip
form_icon=
fusion_table_format=desktop
fusion_table_icon=
keep_duplicates=false
large_file_read_only=true
large_file_threshold_mb=16
log_directory=
lost_and_found=false
low_speed_limit=0
low_speed_time=0
map_format=desktop
map_icon=
max_cache_size_mb=512
max_download_speed=0
max_memory_cache_size=10737418240
max_retries=8
max_upload_chunk_size=1099511627776
max_upload_speed=0
memory_buffer_size=8388608
metadata_cache_time=60
presentation_format=pdf
presentation_icon=
read_ahead_buffers=5
read_only=true
shared_with_me=false
spreadsheet_format=ods
spreadsheet_icon=
sqlite3_busy_timeout=5000
stream_large_files=true
umask=0o002
verification_code=

Here's the last few lines of the gdfuse.log file:

[8269.628471] TID=908128: END: Loading resource /Redacted/path/to/file (trashed=false) from db: Found (id=3768, state=ToDownload)
[8269.628490] TID=908128: BEGIN: Getting metadata from context
[8269.628499] TID=908128: END: Getting metadata: Valid
[8269.628505] TID=908128: BEGIN: Loading resource /Redacted/path/to/file (trashed=false) from db
[8269.629081] TID=908129: read /Redacted/path/to/file [4096 bytes] 90501120 0
[8269.629207] TID=908129: BEGIN: Getting metadata from context
[8269.629212] TID=908129: END: Getting metadata: Valid
[8269.629216] TID=908129: BEGIN: Loading resource /Redacted/path/to/file (trashed=false) from db
[8269.629299] TID=908128: END: Loading resource /Redacted/path/to/file (trashed=false) from db: Found (id=3768, state=ToDownload)
[8269.629572] TID=908129: END: Loading resource /Redacted/path/to/file (trashed=false) from db: Found (id=3768, state=ToDownload)
[8269.629589] TID=908129: BEGIN: Getting metadata from context
[8269.629594] TID=908129: END: Getting metadata: Valid
[8269.629597] TID=908129: BEGIN: Loading resource /Redacted/path/to/file (trashed=false) from db
[8269.629786] TID=908129: END: Loading resource /Redacted/path/to/file (trashed=false) from db: Found (id=3768, state=ToDownload)
[8269.629807] TID=908129: Buffer pool free buffers: 0
[8269.629945] TID=908129: Memory cache size: 10521754909
[8269.629950] TID=908129: Releasing memory buffer (remote id=0B7BUKwy7Xqr0QkFzRXhXc0doY3c, index=207, buffer id=785)
[8269.629955] TID=908129: BEGIN: Acquiring memory buffer (remote id=0B7BUKwy7Xqr0amtidlNvUktZNWs, index=10)
[8269.629959] TID=908129: END: Acquiring memory buffer (remote id=0B7BUKwy7Xqr0amtidlNvUktZNWs, index=10, size=6616808, buffer id=785)
[8269.629965] TID=908129: BEGIN: Stream resource (id=3768, offset=83886080, finish=90502887, length=6616808)

Any idea why this is happening? Anything else I can provide to help troubleshoot?

Thanks!

[ne0ark]

You really don't need large_read with 16.04. You can use auto_cache.

[jrarseneau]

I should add that my primary use is for Plex, so I'm streaming multi-gigabyte files regularly. Plex also has an intensive media scanner that index/analyzes the files quite often (all that to say that there is a lot of activity).

@ne0ark I've used large_read with other FUSE systems (primarily node-gdrive-fuse) and never had drops.

[ne0ark]

@jrarseneau mout.fuse uses libfuse if you do man fuse you will see large_read is deprecated. Also you might want to check google api console to see that you are not hitting 100 sec per user limit which is set to 1000.

[jrarseneau]

@ne0ark I'm only peaking about 3req/s so no where near the limits.

My error ratio is 0.18% though, which seems a bit high.

[astrada]

@jrarseneau: I don't think I need curl.log to fix this issue (so, the next time, if you want, you can remount just with -verbose that logs only to gdfuse.log). Can you please send your gdfuse.log to alessandro.[email protected]? Thanks!

[jrarseneau]

Logs sent!

Thanks!

[jrarseneau]

@astrada

Any updates to this? Have you had a chance to review the logs? I have had the mount drop a few times this week since sending you the logs last weekend.

Thanks!

[astrada]

Unfortunately this issue is not easy for me to reproduce. It's not an error that gets logged, but it's probably a deadlock that stops the process execution without leaving clear traces.

[ne0ark]

@astrada you can replicated it if you install https://github.com/Storj/storjshare-daemon and point it to mounted drive.

[jrarseneau]

This past weekend had about 8-10 drops. What was odd is these drops were both clustered in 2 instances where it dropped about 4 times in 5 minutes.

[bbviking]

I've got exactly the same issue and i'm using it for plex. It also seems to delete the folder which it was mounted to, until i reboot and the folder comes back. A shame really considering this is by far the best performing solution for mounting google drive for streaming on plex. But for me it seems to be far more frequent, about every 5-10 minutes

[astrada]

I'm working on it. I think I know where the problem is, but since I cannot reproduce plex workload, I'm not 100% sure. In the next few days, I'm going to push an experimental patch that needs to be tested. If you tell me how you installed this application (via PPA or OPAM), I will post instructions on how to install this experimental version.

[ne0ark]

@astrada PPA :)

[jrarseneau]

Same. PPA

And thanks for this!

[bbviking]

Yeah it's ppa for me to, thanks for the possible fix I'm looking forward to it :)

[lcasey001]

Haven't had the same frequency as the others above using OPAM, not sure if that makes a difference or not but willing to test the OPAM version here.

[haljordan2814]

In for PPA version. thanks for looking into this

[bbviking]

Does anybody know of a temporary solution? like for detecting when it breaks you are able to unmount the drive and quickly remount. Tried using inotify-tools but it isn't being set off when the drive breaks.

[brancomat]

@buttpain my 2 cents:
it's not always easy to define a broken status: with a large number of files (or a cache that needs some cleaning) some operations could take a large amount of time.

Back when I had some mountpoint hang issues, my alternatives were either running a command (ls or whatever) in timeout (setting a reasonable amount of time) or something like mount|grep google-drive-ocamlfuse.
In both cases you can trap the output and try launching a fuserumount -u $PATH && google-drive-ocamlfuse $PATH if something is wrong (or simply try a -cc to clean the mountpoint cache)

YMMV, it might not be a bright idea if some other process is trying to write on that mountpoint (you could enter a state in which you unmount the path and for some reason the remount fails and the other process starts writing on the (now very local) mount path filling that partition. (been there, done that)

[bbviking]

Thanks for the response brancomat, actually got a reaaallllyyy ghetto solution working just a couple hours ago.

ls -l /var/lib/plexmediaserver/media/plex/log.txt
if [ -rw-r--r-- 1 root root 20904 Apr 4 17:34 /var/lib/plexmediaserver/media/plex/log.txt ]; then
echo OK
else
fusermount -z -u /var/lib/plexmediaserver/media/ & google-drive-ocamlfuse -label me /var/lib/plexmediaserver/media/ -o allow_other,auto_cache
fi

That script checks the properties of a log.txt file created on my google drive, and if it gets backs the properties of the log file then nothing will happen. But if it doesn't get back the properties then the drive gets unmounted and then immediately remounted. Now to have it be running constantly I had this command in the /etc/rc.local file

sudo -H -u root screen -d -m watch -n1 sh /etc/init.d/boot.sh

This means that every second my script that I made will be run, checking if the log file on the mounted drive is still accessible, and if not unmount, remount.

[astrada]

With opam you can test the new beta version with:

opam pin add google-drive-ocamlfuse https://github.com/astrada/google-drive-ocamlfuse.git#beta

To restore the stable version:

opam pin remove google-drive-ocamlfuse

In the next days, I'm going to publish this beta version to the beta PPA.

[jrarseneau]

Testing with opam, was quite easy to switch and I wanted to provide feedback as quick as possible.

Just mounted it now, so will post back when/if it drops.

[bbviking]

Would really like to test it out, but i can't seem to get opam to work on my vps.

[astrada]

I've just published this new version to my beta PPA (https://launchpad.net/~alessandro-strada/+archive/ubuntu/google-drive-ocamlfuse-beta).

[bbviking]

Unfortunately this doesn't fix the issue, I analyse my library in plex and before it can finish all my movies become unavailable.

[astrada]

Can you please email me your log files? Thanks

[bbviking]

will do when my 24 hour api ban ends. But from what I remember from when I checked before there was nothing in the log which seemed to indicate that anything had gone wrong which seemed very odd.

[jrarseneau]

@buttpain

This may be a separate issue? If as you state above, your "media becomes unavailable", and then you indicate you had a 24 hour ban, this would explain why your media is unavailable.

Now this may be related to something google-drive-ocamlfuse is doing, but I'm not entirely convinced it's the same issue as this thread?

This thread is about the google-drive-ocamlfuse process dying unexpectedly. The process is killed, the mount is dropped. It is not about files becoming unavailable or bans.

[bbviking]

Oh no, the 24 hour ban happened because I tried too many time to update my plex library, after I tested google-drive-ocamlfuse and started using rclone mount instead.

[jrarseneau]

Ah ok.. I'm still running on the initial mount from a few days ago, hasn't dropped yet. But I have gone a week before without a drop.

[bbviking]

Yeah when I'm just streaming content off of plex it's totally fine. But issues arise when ever I attempt to analyse, or update the library

[hjone72]

I found that having -debug on caused my curl.log to get so large that ocaml crashed.

Thread 20284 killed on uncaught exception Sys_error("No space left on device")
Thread 20286 killed on uncaught exception Sys_error("No space left on device")
Thread 20287 killed on uncaught exception Sys_error("No space left on device")
Thread 20283 killed on uncaught exception Sys_error("No space left on device")
Thread 20285 killed on uncaught exception Sys_error("No space left on device")

[astrada]

@hjone72: Yes -debug dumps every byte exchanged with the server. Using -verbose should be enough for troubleshooting this particular issue.

[hjone72]

@astrada, thank you. I've added your beta repository and run sudo apt-get upgrade is there any way to ensure that I am running your latest version? I am still facing an unmount issue.

[astrada]

@hjone72, google-drive-ocamlfuse -version should return 0.6.18 (that's the new beta version).

[hjone72]

@astrada Definitely running the beta. While the mount in foreground mode -f it randomly unmounts displaying a message Fatal error: out of memory.. I've got a script running that remounts it so I've lost the logs this time, but next time it drops i'll post them.

[bbviking]

I forgot to post this a couple days ago, but the latest beta uses an insane amount of RAM. Filling up all 8GB of the RAM i have on my VPS and causing it to shutdown by streaming one file.

[dany20mh]

@hjone72 What’s your script for running the mount back again if it drop?

[astrada]

@buttpain: Which values have you set up in max_memory_cache_size, memory_buffer_size, and read_ahead_buffers?

@jrarseneau: Are you experiencing abnormal memory usage? Anyone else?

[jrarseneau]

@astrada My memory usage is fine (~1-1.5GB, but that's based on my config), here are the settings I'm using for the above configs.

No crashes yet, however I have had to restart my server due to a glitch (not related) so my counter is restarted since yesterday the 9th.

max_memory_cache_size=1073741824
memory_buffer_size=8388608
read_ahead_buffers=5

[hjone72]

@dany20mh, its a modification of this one. https://gist.github.com/jrarseneau/e634ca4b71c3281b6f57779c7957ba34

@astrada, Mine is using 1.6GiB and my config is set to the following.

max_memory_cache_size=504857600
memory_buffer_size=8388608
read_ahead_buffers=5

My understanding was the max_memory_cache_size was an absolute max?
I haven't had a crash in nearly 12 hours now, but as soon as I do I'll grab the logs.

[astrada]

My understanding was the max_memory_cache_size was an absolute max?

Yes, it should be, but that's about the memory cache. Anyway, did you notice an increase of memory usage between this version and 0.6.17?

[hjone72]

@astrada, It is hard to say as I wasn't running version 0.6.17 for very long. sorry.

[ne0ark]

Seems like something funky is going on:

140G    /root/.gdfuse/storj/cache

My config:

max_cache_size_mb=20480

~/.gdfuse/storj/cache# ls -lath
total 140G
drwx------ 3 root root 4.0K Apr 11 14:05 ..
drwx------ 2 root root 264K Apr 11 14:05 .
-rw-r--r-- 1 root root 2.8M Apr 11 14:05 cache.db
-rw-r--r-- 1 root root 3.5M Apr 11 13:17 0B1Kk_ENv1qSGb3RYaTFnVGlTcDA
-rw-r--r-- 1 root root 1.0T Apr 11 09:12 0B1Kk_ENv1qSGNDRsRUk4SHYteGM
-rw-r--r-- 1 root root 1.0T Apr 11 00:26 0B1Kk_ENv1qSGaHRxMnh0UzhyajQ
-rw-r--r-- 1 root root 1.0T Apr 11 00:21 0B1Kk_ENv1qSGZk5ack1fSnZVZms
-rw-r--r-- 1 root root 1.0T Apr 10 23:28 0B1Kk_ENv1qSGVFh2ZFdmQWVGcFk
-rw-r--r-- 1 root root 1.0T Apr 10 23:28 0B1Kk_ENv1qSGQkFqc0dfdndXWHM



md5-679dab239e3c271a00664405d63d8e99



fuse    uid=0,gid=0,auto_cache,default_permissions,allow_other,atomic_o_trunc

@astrada any clue why its using more then allowed?

[hjone72]

@astrada, Mount was stable almost all day. Then it crashed three times in two hours. I've got the three log files but they are quite large (1GB, 207MB, 66MB). How would you like me to share them?

[astrada]

@hjone72: gzip should shrink them a bit. Then you could just email them to me ([email protected]) or share them to me on Drive or Dropbox, whatever you prefer. Does it work for you? Thanks

[astrada]

@ne0ark: if your mount dropped unexpectedly, there could be unreferenced files in the local cache that will not get cleaned up. Otherwise, if you can reproduce the issue after remounting with -cc -verbose, could you send me your gdfuse.log, so that I can investigate the issue? Thanks.

[hjone72]

@astrada, I've emailed you a link to my logs. :)

Thanks!

[ne0ark]

@astrada I also send you a log with IO error. Would you be able to check it? It seems like cache is still skipping some parts.

Thanks

[jrarseneau]

Hi

Any movement on this @astrada ?

[astrada]

Not really. Did you experienced issues?

[jrarseneau]

Yes, but not drops (yet), but I've rebuilt my server due to a hard drive failure.

I'm sending you the logs of an issue I'm having that's crashing some applications that try to perform actions on a mounted folder (did not happen in 0.6.17).

[dany20mh]

For me, I had more drop with the new beta version and as soon as I revert back to the released version, so far it’s smooth and I haven’t notice any drop yet.

[astrada]

@dany20mh: What kind of drops? Do you get "Fatal error: out of memory" too?

[ml3000]

I am getting the out of memory error constantly.

[haljordan2814]

@ml3000 What version of software, what os, what hardware?

[ml3000]

I am using Ubuntu 16.04, Within VMware Workstation. The host has 12GB of
ram. The VM is now assigned 4GB. When watching the System Monitor the ram
usage starts to creep up but then fails before long.

The Ubuntu machine by itself usually runs at around 1.5GB. I upped the RAM
in the machine to 6GB which did not fix the issue. The ram utilization that
time didn't even get to 50%

It was failing about 20 minutes into any video but I found out if I do a
library scan I can get it to fail 100% of the time consistently.

On Mon, Apr 24, 2017 at 6:41 PM, gts24 [e-mail] wrote:

@ml3000 https://github.com/ml3000 What version of software, what os,
what hardware?

—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://github.com/astrada/google-drive-ocamlfuse/issues/281#issuecomment-296867634,
or mute the thread
https://github.com/notifications/unsubscribe-auth/Aagkf2QFPTgQtZfBjezz5fvF70YrBxBrks5rzU9kgaJpZM4MpSjm
.

--
~ Matt Lindsay
208.820.1236

[gbdoin]

We're also getting the OOM error, about 2 times/day. Like others in this thread, this mount is used for Plex.

Operating System: CentOS Linux 7 (Core)
Kernel: Linux 3.10.0-514.10.2.el7.x86_64
40GB RAM VPS
max_memory_cache_size=10737418240
memory_buffer_size=1048576 (but actually changed that one without saving old value before posting)
read_ahead_buffers=5

[astrada]

@gabo77: Have you tried reducing max_memory_cache (e.g. to 1073741824 = 1GB)? Do you still get OOM errors?

[ml3000]

Yes I do. I changed it to 1GB and still get the error.

On Apr 25, 2017 7:24 AM, "Alessandro Strada" [e-mail]
wrote:

@gabo77 https://github.com/gabo77: Have you tried reducing
max_memory_cache (e.g. to 1073741824 = 1GB)? Do you still get OOM errors?

—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://github.com/astrada/google-drive-ocamlfuse/issues/281#issuecomment-297046691,
or mute the thread
https://github.com/notifications/unsubscribe-auth/Aagkfy2FdtltUouOR9SeHkqucI5POqW-ks5rzgIYgaJpZM4MpSjm
.

[astrada]

I've prepared a shell script to monitor memory usage of google-drive-ocamlfuse. It logs memory stats (every 5 seconds) to /tmp/gdfuse.mem.log. If you try it, after you get an OOM error, you could send the log file to my email ([email protected]), so that I can see how much memory was allocated at the time the program crashed.

[gbdoin]

Before posting, I reduced max_memory_cache_size to 5GB. I've also set an alarm to be notified if the server runs OOM. Your script is now running, I will keep you updated.

I'm running version 0.6.17

[ml3000]

I went ahead and send you the logs. Also, currently I am running 0.6.17, I
did try 0.6.18 with the same results.

On Tue, Apr 25, 2017 at 8:16 AM, 3psus [e-mail] wrote:

Before posting, I reduced max_memory_cache_size to 5GB. I've also set an
alarm to be notified if the server runs OOM. Your script is now running, I
will keep you updated.

I'm running version 0.6.17

—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://github.com/astrada/google-drive-ocamlfuse/issues/281#issuecomment-297063755,
or mute the thread
https://github.com/notifications/unsubscribe-auth/Aagkf3qLxS1Lj9ARP7z33spn_WFPxXmsks5rzg5OgaJpZM4MpSjm
.

--
~ Matt Lindsay
208.820.1236

[animosity22]

Hmm. I hit an Out of Memory last night. My server has 32GB of memory and I have a ~16GB max memory set. First time I saw this item pop up and I had plenty of memory left on the system:

I use netdata/grafana and capture all those items already:
http://imgur.com/u01rztT - App Memory
http://imgur.com/rz7BhLZ - System Memory from the same time

I was rescanning my TV section last night after fixing a unionfuse mount when the issue occurred. Definitely a lot of access and some 403s, but not too bad. I was running maybe 1-2% rate limit errors on ~20k API calls.

[astrada]

@animosity22: it looks like (from feedback I got from different users) a plex scan puts a lot of memory pressure on the app, so it takes a bit of trial/error to find the max memory setting that fits your server memory under that kind of load. (Or, if you know you have to do a full scan, you could reduce temporarily your max_memory_cache_size. The only drawback is that anytime you change that setting you have to unmount/remount your Drive.)

[animosity22]

I'll try to reduce it down a little and see if that helps out. I wasn't seeing any 'out of memory' issue from a server though with the bigger numbers. I went for the if I have the memory, use it for this, which maybe was too much?

I've seen no issues during normal scans or playback as that works like a champ.

@jrarseneau - are you doing a "refresh" for your libraries when you see issues? My normal "Scan" libraries run insanely fast once my refresh is done. I do a few things to make sure media is analyzed and run some stats so you can see that info. I use ocamlfuse ->rclone encrypted mount -> unionfus (local storage RW/ rclone mount RO).

[mattbator]

I'm seeing the same issue as @buttpain - occasionally the mount will disappear and leaves the directory it was mounted to in a strange place (see attached image). Not seeing anything in the gdfuse.log that would indicated it crashed - it ends with a BEGIN: Loading resource message, nothing regarding running out of memory, space aliens or heartburn.

I'm on 0.6.17. Anecdotally I'll say the mount is most stable when I'm just streaming media via Plex, I believe all of the issues I've seen have been when new media is being uploaded to Google Drive (via rclone move) - though I suspect it's more the scanning after a file has been uploaded rather than the uploading itself. I have all scheduled Plex scans disabled and when I add new media I have Plex Media Scanner only scan the directory containing the new file, so at most it would only be touching 24 files on a scan.

[animosity22]

@mattbator - if you check dmesg, do you see a crash message for it?

[astrada]

@mattbator: OOM errors will not be logged, because the OS kills the process before it can write anything to the log. And the weird state you get is caused by the crash, so that the app doesn't unmount cleanly your directory (you should run fusermount -u to restore the mountpoint state).

[mattbator]

I had already rebooted, will try to capture any relevant entries from dmesg the next time it happens.

[animosity22]

@jrarseneau - In reading through the mount options, what does:
atomic_o_trunc - what does this do?

large_read seems to be not there and no reason to use:

   large_read
              Issue  large  read  requests.   This  can improve performance for some filesystems, but can also degrade performance. This
              option is only useful on 2.4.X kernels, as on 2.6 kernels requests size is automatically determined  for  optimum  perfor‐
              mance.

I use auto_cache on mine instead.

[jrarseneau]

@animosity22

I don't do manual Plex refreshes. I have the setting to scan only on library changes and it only scans the folder affected.

I also no longer use large_read.

I have not gotten a drop in over a week with 0.6.17, but after a bit, I do get this weird issue where the files on google drive can't be read properly as an ls -l provides:

?????????? ? ? ? ? ? Redacted - S03E03 - Redacted.mkv

I am not seeing OOM errors here, but I am now running the script. I cannot use 0.6.18 as it wrecks havoc on my system with Plex, Sonarr and Radarr throwing errors about not being able to modify files on the UnionFS mount (even though the mount hasn't changed from 0.6.17 to .18) so not sure what's going on, but hope that 0.6.18 doesn't go live with that change as I'll have to stick to .17

[astrada]

@jrarseneau: have you tried setting large_file_read_only=false with version 0.6.18? This way all your files should be modifiable.

[raidzx]

I am running into this same issue. Seems to happen after scans in plex, not sure what the error is when it crashes but I never went over 50% system ram usage.

[astrada]

I've just uploaded a new beta version (0.6.19) that should fix a problem caused by timeouts during streaming. In version 0.6.18 if you got a connection timeout streaming a block, and the same block was waiting to be read by another thread, you got a deadlock that stopped the process, making the mountpoint unresponsive.

[animosity22]

@astrada - I've only had like 1 drop in the last week or so , but I'll give the beta a try and see how that works.

[astrada]

@animosity22: thanks!

[jrarseneau]

Is the beta on the PPA?

[astrada]

@jrarseneau: yes, it is

[raidzx]

Unfortunately 0.6.19 doesn't seemed to have fixed the problem. Plex scans did seem to last a bit longer this time but it still crashed after a 30 min scan.

[astrada]

@raidzx: if you get out of memory errors, you should reduce max_memory_cache_size. If it's another problem, please remount with -verbose and send the log file to my email, thanks! The issue I fixed made the mountpoint unresponsive, it didn't crash the application.

[animosity22]

@raidzx - what's your library mainly made of the size? I ran through ~13k TV shows and ~1.5k Movies without an issue. I also have Verizon Fios Gigabit so I see ~400-500Mbs when I did my full scans so it definitely pulled down some data.

[EnorMOZ]

I am not seeing 0.6.19 via opam.

$ /usr/local/bin/google-drive-ocamlfuse -version
google-drive-ocamlfuse, version 0.6.18
Copyright (C) 2012-2017 Alessandro Strada
License MIT

$ opam pin add google-drive-ocamlfuse https://github.com/astrada/google-drive-ocamlfuse.git#beta
[NOTE] Package google-drive-ocamlfuse is already git-pinned to https://github.com/astrada/google-drive-ocamlfuse.git#beta.
       This will erase any previous custom definition.
Proceed ? [Y/n] Y

[google-drive-ocamlfuse] https://github.com/astrada/google-drive-ocamlfuse.git#beta updated
[google-drive-ocamlfuse] Installing new package description from https://github.com/astrada/google-drive-ocamlfuse.git#beta



md5-679dab239e3c271a00664405d63d8e99



$ opam list google-drive-ocamlfuse
# Available packages for system:
google-drive-ocamlfuse  0.6.17 (pinned)  A FUSE filesystem over Google Drive



md5-679dab239e3c271a00664405d63d8e99



$ opam upgrade
Everything as up-to-date as possible (run with --verbose to show unavailable upgrades).

[astrada]

@DTrace001: opam list still shows version 0.6.17, because that is the last version in the official repository, but if you run google-drive-ocamlfuse -version you should see 0.6.19. If not, run opam reinstall google-drive-ocamlfuse.

[EnorMOZ]

I see the issue now. It installed it under a different path. Running 0.6.19 now

[raidzx]

@astrada I have e-mailed you my log with -verbose. Please let me know if there is anything else I can do to help you track this down.

Thanks!

[halolordkiller3]

@astrada so for some reason I still don't see 6.19. Here is what I have done.
`opam pin add google-drive-ocamlfuse https://github.com/astrada/google-drive-ocamlfuse.git#beta
[NOTE] Package google-drive-ocamlfuse is already git-pinned to https://github.com/astrada/google-drive-ocamlfuse.git#beta.
This will erase any previous custom definition.
Proceed ? [Y/n] y

[google-drive-ocamlfuse] https://github.com/astrada/google-drive-ocamlfuse.git#beta updated
[google-drive-ocamlfuse] Installing new package description from https://github.com/astrada/google-drive-ocamlfuse.git#beta

google-drive-ocamlfuse needs to be installed.
The following actions will be performed:
∗ install google-drive-ocamlfuse 0.6.17*
Do you want to continue ? [Y/n] n
`

[astrada]

@halolordkiller3 : opam still shows version 0.6.17, because that is the latest version in the official repository, but, after installing the beta version, if you run google-drive-ocamlfuse -version you should see 0.6.19. If not, run opam reinstall google-drive-ocamlfuse.

[SteelyNinja]

Hi, just found this thread and I am having the same issues with drops on scans. (running 0.6.19) now.
I will capture a verbose log and see what it says....

The mount is fine during normal playing, but on scan there seems t be a lot more activity and the mount drops.

• Edit - logs sent

[JAC2703]

Hi,

I'm having the same issue and it's almost certainly down to high memory use. It seems that memory use shoots up to about 86% (of 3GB) within moments of initiating a scan.

I'm running version .19 from the beta PPA repo.

Config as follows:
connect_timeout_ms=5000 curl_debug_off=false data_directory= delete_forever_in_trash_folder=false docs_file_extension=true document_format=odt document_icon= download_docs=true drawing_format=png drawing_icon= form_format=zip form_icon= fusion_table_format=desktop fusion_table_icon= keep_duplicates=false large_file_read_only=false large_file_threshold_mb=32 log_directory= lost_and_found=false low_speed_limit=0 low_speed_time=0 map_format=desktop map_icon= max_cache_size_mb=30240 max_download_speed=0 max_memory_cache_size=419430400 max_retries=80 max_upload_chunk_size=1099511627776 max_upload_speed=0 memory_buffer_size=10485760 metadata_cache_time=360 presentation_format=pdf presentation_icon= read_ahead_buffers=12 read_only=false shared_with_me=false spreadsheet_format=ods spreadsheet_icon= sqlite3_busy_timeout=5000 stream_large_files=true umask=0o022 verification_code=

[Soulplayer]

I have the exact same problem but I can't seem to update to the beta...

[asdub]

Anyone figure this out yet?
Having the exact same issue. Version 6.21

[astrada]

Should be fixed in the latest version.

[GhyslainBruno]