Why insync write so much in my SSD?

#1

I was getting a hard time figuring why my SSD is being “abused” and I figured the majority is insync updating database, but I don’t know why as there is no data being changed in the path… I started analyzing results with ksyslog:

Selection_001.png1914×196 30.3 KB

And so I logged the access with fatrace and is pretty abusive, ~2 minutes produced a near 4MB where insync dominates write operations, can’t it be reduced?

update:

This appear to be a quite ephemeral file to be in /var/tmp, a directory that should not be ram mounted as it is intended for files that live after reboot:

…
01:50:49.532206 insync(2568): W /var/tmp/etilqs_cwXDXJzU56oTcqM (deleted)
01:50:49.532248 insync(2568): W /var/tmp/etilqs_cwXDXJzU56oTcqM (deleted)
01:50:49.532261 insync(2568): W /var/tmp/etilqs_cwXDXJzU56oTcqM (deleted)
01:50:49.532274 insync(2568): W /var/tmp/etilqs_cwXDXJzU56oTcqM (deleted)
01:50:49.532287 insync(2568): W /var/tmp/etilqs_cwXDXJzU56oTcqM (deleted)
01:50:49.532299 insync(2568): W /var/tmp/etilqs_cwXDXJzU56oTcqM (deleted)
01:50:49.532311 insync(2568): W /var/tmp/etilqs_cwXDXJzU56oTcqM (deleted)
01:50:49.532323 insync(2568): W /var/tmp/etilqs_cwXDXJzU56oTcqM (deleted)
01:50:49.532335 insync(2568): W /var/tmp/etilqs_cwXDXJzU56oTcqM (deleted)
01:50:49.532381 insync(2568): W /var/tmp/etilqs_cwXDXJzU56oTcqM (deleted)
…

Should it not be more appropriated to use /tmp ? It is safer to users to mount it in RAM for example.

1 Like
#2

tagging our engineers @dipesh @lpugoy @jimperio and they will get back to you.

#3

@Romulo_Benedetti: Thanks for the report, I’ll take a look at it. Was Insync syncing files during this period?

#4

there is months I did not change my google drive data.

When it first start it massively write without syncing:

Selection_001.png915×536 37.6 KB

it takes 1min+ doing this

and so it frequently do something from time to time, doing spikes

#5

@Romulo_Benedetti: I see. Have you encountered it with older versions? Do you have a lot of files in your account, around 10,000? Does it only happen when Insync is starting up, or does it happen continuously while Insync is running?

#6

I have a lot of files on my Drive account and Insync takes a long time before syncing begins. It’s expected though as I imagine the app would check through all the folders to see changed/new/deleted files so that they can be synced. The app has no way of knowing about changes made when the app was not running so this is going to happen. So for the first few minutes after starting the app, the hard disk is accessed like crazy.

#7

Please pay attention to my post and images, I’m concerned about write access…

#8

Thanks for the attention, a lot more, 114,000.
The intense write that I stated at last, yes, has 2 or 3 minutes of duration after insync is started, I logged write accesses with fatrace and can confirm they are InSync access. Small writes as I stated first, occurs frequently.

My preoccupation is that I have practically nothing shared, and what is shared is not edited so I don’t get why InSync need to change so much the database over time.

#9

The heavy (very heavy) disk access when Insync starts is my only grief with the software. Insync’s data folder is on my programs/boot drive and kills my system’s performance for the almost two hours of startup comparisons. Would really like the option to place the data file on a secondary drive to free up the load on my primary.

#10

I really would like that, if temporary files really are ephemeral, on Linux they have to be stored in /tmp, unless you really need it to survive reboot.

I’m not sure, but it appear it is rebuilding the entire database in my case, every restart of the program, this is more serious in my view, as it represents 1.5 GB in my case.

I’m planning to sync all my FS on near future if viable.

#11

@Mike_Kucerik: You might want to try moving the folder ~/.config/Insync to your secondary drive and add a symlink to it in its original location.

@Romulo_Benedetti: I’m still taking a look at your issue but just a note regarding syncing your whole FS. That is not supported for now as it might cause issues with files that Insync cannot modify and with symlink cycles, among others.

#12

Ok thanks, at the moment I’m not using InSync to avoid SSD abuse and huge differentials on file system snapshots.

#13

Hi, same for me !! when starting my computer, it takes very long time… (same on 2 ubuntu computers)

#14

yes, it’s rebuilding the entire database in my case… about 115Go in my case !!

#15

I’m just waiting when they will point us a version that did not behave like this, I simply can’t use it at the moment, it increased alone near 2 points in my wear leveling the last month I believe.

#16

@Romulo_Benedetti: Please try setting the SQLITE_TMPDIR environmental variable to /tmp before running Insync. This seems to work in my case.

#17

I setted the environment and started insync from the same shell process, still it writes on /var/log. This variable apparently did not exist or is empty before I set it.

#18

@Romulo_Benedetti: Hmm, how did you set the environmental variable? What Linux distribution and version are you using, and what Insync version? Also please try setting the TMPDIR environmental variable as well.