If you could wrap up a database, and data+sequcne of s-puts that would
be great. I don't have a VMWare environment to try it on but I can try
to replicate it. I don't know what else to try.
I don't see why a VM would make difference but elsewhere they seem to,
maybe because some file process runs on the real hardware (docker), or
may be file locking can be interfered with.
Is vg0-root shared in anyway?
Andy
On 16/04/18 15:21, Osma Suominen wrote:
Hi Andy!
Forgot to answer the VM part - yes, this is a VM running on VMWare. This
is what mount shows:
/dev/mapper/vg0-root on / type ext4
(rw,relatime,errors=remount-ro,data=ordered)
I.e. a normal ext4 filesystem on LVM.
We have plenty of VMs pretty much exactly like this and haven't
experienced any filesystem related problems that I know of.
-Osma
PS. I've been trying to reproduce this with smaller data, but so far to
no avail. But by digging the logs I noticed that the same problem
appeared also in another TDB2 database that's configured within the same
Fuseki instance on the same server. Also in that case the errors
appeared soon after loading some new triples into specific graphs,
overwriting their previous content.
One other question - is any of this docker or a VM, if so, what is
the filesystem setup?
No, this is not Docker. Ubuntu 16.04 LTS amd64 with Java 9:
openjdk version "9-internal"
OpenJDK Runtime Environment (build
9-internal+0-2016-04-14-195246.buildd.src)
OpenJDK 64-Bit Server VM (build
9-internal+0-2016-04-14-195246.buildd.src, mixed mode)
Just tell me what you really need (considering the size of the files)
and I will send them to you.
-Osma
