Lizardfs: 3.10.4 - Error writing files

[alexharrington]

I recently upgraded to 3.10.4 and things seemed normal.

We're trying some new software today which writes a file to a temporary directory, and then moves it to the directory above. Both locations are on the same lizardfs mount.

This behaviour seems to trigger alot of logs from mfsmount:

Nov 11 12:44:52 i mfsmount[18710]: write file error, inode: 36846, index: 0 - error sent by master server (Chunk locked)

The software we're running then reports an error moving the file.

Any ideas what might be causing that, or if there's anything I can tune to avoid it please?

The goal for the file when created is a replication to two servers.

[DarkHaze]

This is normal behaviour when two clients try to write to the same chunk.
One of them must wait for other to finish writing to the chunk. There is no
need to tune or fix anything. We probably should remove this error message
because is grossly misleading.

11.11.2016 1:50 PM "Alex Harrington" [email protected] napisał(a):

I recently upgraded to 3.10.4 and things seemed normal.

We're trying some new software today which writes a file to a temporary
directory, and then moves it to the directory above.

This behaviour seems to trigger alot of logs from mfsmount:

Nov 11 12:44:52 i mfsmount[18710]: write file error, inode: 36846, index:
0 - error sent by master server (Chunk locked)

The software we're running then reports an error moving the file.

Any ideas what might be causing that, or if there's anything I can tune to
avoid it please?

—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub
https://github.com/lizardfs/lizardfs/issues/498, or mute the thread
https://github.com/notifications/unsubscribe-auth/AL2bA0RoOTVb8eJZWYl3Jzhy1fEqPdoWks5q9GSEgaJpZM4KvuAH
.

[alexharrington]

In that scenario what happens? Does one get an IO error and the others write succeeds? I'm struggling to work out how two clients can be accessing the same file in our scenario though. I'll go away and see if I can work it out. Thanks for the response.

[DarkHaze]

One writes and succeeded. The other one gets "error" (in this case it's
more like status) and repeats after some time and then also completes the
write.

11.11.2016 2:50 PM "Alex Harrington" [email protected] napisał(a):

I that scenario what happens? Does one get an IO error and the others
write succeeds? I'm struggling to work out how two clients can be accessing
the same file in our scenario though. I'll go away and see if I can work it
out. Thanks for the response.

—
You are receiving this because you commented.
Reply to this email directly, view it on GitHub
https://github.com/lizardfs/lizardfs/issues/498#issuecomment-259960927,
or mute the thread
https://github.com/notifications/unsubscribe-auth/AL2bA4CnGRZFZq0kFqPaiLvGVc_xPxljks5q9HKQgaJpZM4KvuAH
.

[alexharrington]

Great. Thanks for the explanation :)

[psarna]

If the software you use reports a write error as well, it probably means that one of your mounts retried writing several times (waiting for the chunk to be unlocked), but the chunk was still locked, so it eventually gave up.
You can try mounting with -o mfsioretries=60 parameter, replacing 60 with value of your choice. Default value is 30 and maybe it is too small for your use case.