Shane St Savage

It looks like all of the "failed to flush user" errors refer to three files, none of which actually exist: ``` sudo docker logs loki 2>&1 | grep "failed to...

Files with those filenames in the above errors can't be created manually, but filenames with very similar names in the same directory can be created. ``` /tmp/loki # touch /tmp/loki/chunks/ZmFrZS83MzU5OTJkNzAzOWM0MDU5OjE2ZmEyYmJmZTIxOjE2ZmEyYmRkMzYzOmNjMjZlNTA1...

Ok, found it. I was also unable to create that file inside the directory mounted to `/tmp/loki` from the host (outside of the container). Finally looked in dmesg and found...

Disabled `dir_index` on the ext4 volume using ``` sudo tune2fs -O "^dir_index" /dev/sda1 ``` That caused I/O errors and a read-only file system, and after rebooting dropped into an initramfs...

@slim-bean Yep, looks like `64bit` is on. Here's the whole tunefs output: ``` $ sudo tune2fs -l /dev/sda1 tune2fs 1.43.4 (31-Jan-2017) Filesystem volume name: Last mounted on: / Filesystem UUID:...

Thank you stale bot. @slim-bean Disabling `dir_index` while using loki 1.2.0 seemed to solve this issue for us. > I'm also curious if disabling dir_index will have a performance impact...

I'm also hitting this with a remote NFS volume which already contains data. If this restriction is artificial can we consider lifting it?

> It will be great to support readonly option for anonymous volumes unless there is a valid reason to forbid this behavior? Checking back here, this feels like an easy...

Need to do some testing tomorrow to verify that third-party EDD class discovery actually works, but here's the code for review.

Ah, I missed the SaxHandler entirely. Looking at that now...