Hi. On Tue, Jan 13, 2009 at 04:43:30PM -0800, Yehuda Sadeh Weinraub (yehudasa@xxxxxxxxx) wrote: > I've played a bit with pohmelfs and it looks very nice. Specifically > I was very happy with the easy configuration on both the server and > the client. Thanks a lot for giving it a try! > I understand that you manage the metadata operations asynchronously. > How do you handle multiple clients in pohmelfs? Any specific locking? There is a cache coherency protocol which is managed by the server, so effectively every access requests a lock and if another client influences the object, server will ask the first one to flush its changes to the server which will then be sent to the second client after it gets the lock. Locks are cached and not requested again when new operation happens, it will be requested only if server requested to drop the lock. > I did have some problems. I was trying to run dbench and it failed. > Also I understand that you haven't implemented all vfs interface yet > (chmod, chown, etc.). I was looking at the following code (more of at > the comments), and it explained some strange stuff that I had seen: They should be implemented already in the change attribute code. Attribute changes are flushed at writeback time or on server's demand. I will try to reproduce the problem locally, thanks for the report. Can you provide the output of the command, its parameters and the dmesg? > I understand that you handle metadata operations locally, and for > example when doing mkdir or creating a file, the file/directory is > created locally, the inode is set dirty and when a writeback occurs > everything is syncronized to the server. Isn't there some problem in > cases where there are more than one client operating on the same > directory with the same filename then? Moreover, it is possible that > client A creates a file and client B creates a directory with the same > name. Am I missing something, or is that the intended design? There are distributed locks used in the POHMELFS, and appropriate protocol maintains coherent cache on all the clients. In the example you showed, the first client will grab the parent directory lock, create a file there and then flush it to the server when the second client starts an operation. It will then detect that there is a file with given name and file the processing (or will overwrite its content, depending on the application of course). -- Evgeniy Polyakov -- To unsubscribe from this list: send the line "unsubscribe linux-fsdevel" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
