Ask Your Question
0

partial failure of PUT or DELETE

asked 2013-06-26 11:34:07 -0500

I understand the process of Put or Delete is like this the proxy sends an object PUT to three object servers and as long as at least 2 of the servers respond with 2xx, the PUT is considered a success. If one fails, replication will repair that copy when it gets to it. If more than two nodes fail, then it comes to a failure. But if one node successes, it's likely that it will put the new object on its disk and it's possible that the replicator will copy this new object to all nodes. According to the code, I haven't seen any transaction or rollback operations to suspend this kind of problem. Anybody could tell me in which place it controls this problem? Thank you!

edit retag flag offensive close merge delete

9 answers

Sort by ยป oldest newest most voted
0

answered 2013-06-26 16:47:29 -0500

torgomatic gravatar image

The relevant code is in swift/proxy/controllers/obj.py, and the PUT method starts around line 750.

Note that the only way your scenario will occur is if the connection count drops below quorum right at the very end of the file, so that one backend gets the last bytes of the request but the other two don't. If the connection count drops below quorum in the middle of an upload, it's aborted immediately.

edit flag offensive delete link more
0

answered 2013-06-27 01:35:38 -0500

Thank you for your answer Samuel. As you mentioned, if the connection count drops below quorum right at the very end of the file, then what happened? Will the problem occur? And what about the delete method? It seems that object server will firstly delete the file and report a success status. But if partial failure occurs, what happen?

edit flag offensive delete link more
0

answered 2013-06-27 01:42:22 -0500

I mean is it a way to solve the problem if connection drops below quorum right at the very end of file?

edit flag offensive delete link more
0

answered 2013-06-27 01:49:32 -0500

The upload process is using the greenthread, so it's very likely that the connection with a good status will finish first, and if at this time partial failure occurs, does swift rollback this operation? Thank you.

edit flag offensive delete link more
0

answered 2013-06-27 16:09:12 -0500

torgomatic gravatar image

To the best of my knowledge, if you manage to hit that exact case, then you'll get a failure response but the object will be successfully created in 1 spot. There's no rollback.

edit flag offensive delete link more
0

answered 2013-07-17 07:26:16 -0500

It means it's possible that a client creates or deletes something in only 1 place but due to the quorum and get a response of failure. And it will actually complete that job in the final due to the rsync job?

edit flag offensive delete link more
0

answered 2013-07-17 18:12:06 -0500

torgomatic gravatar image

Assuming the 1 disk with the object doesn't fail, that's correct.

edit flag offensive delete link more
0

answered 2013-07-31 07:59:09 -0500

Thanks for your answer Samuel. Now I understand this mechanism . But can you tell me the reason why? Is there any benefits of doing like this? It may be very confusing from the client side.

edit flag offensive delete link more
0

answered 2013-07-31 08:13:07 -0500

By the way I want to ask, why swift doesn't provide a client side library. It seems that the proxy server's burden is too high. It has to handle the request from the user, parse it and then send to the storage server and receive the response from them and finally send it to client. In my opinion, proxy server may become the center point of the whole system. It should only reply the client the location of the file to the user, and user will send the request to storage server directly. Why swift is not doing like this?

edit flag offensive delete link more

Your Answer

Please start posting anonymously - your entry will be published after you log in or create a new account.

Add Answer

Get to know Ask OpenStack

Resources for moderators

Question Tools

1 follower

Stats

Asked: 2013-06-26 11:34:07 -0500

Seen: 23 times

Last updated: Jul 31 '13