On Wed, Mar 21, 2012 at 09:54:32PM +0000, Al Viro (viro@xxxxxxxxxxxxxxxxxx) wrote: > IDGI. Again, you are getting different strings for different processes, > so that one inside a chroot generates shorter pathnames. I'm not asking > about races with rename() et.al. - it's obviously racy, but that's a http_compat ugly mount options forbids rename It cuts fair amount of functionality present for 'normal' pohmelfs > separate problem. Details, please - as far as I can tell, that code > looks like a reimplementation of dentry_path() in a curiously broken > way; what demands that particular breakage? Again, the question of > pathname stability, uniqueness, etc. is a separate story; why this specific > weirdness? Note that you are passing a to d_path() a vfsmount/dentry > pair that violates all kinds of assertions - dentry->d_sb != mnt->mnt_sb > more often than not, to start with. Details are pretty simple - we want to allow external applications to get to filesystem and grab data via single requests, since it is stateless and can not hold dentry structure. They do not connect to server which runs on top of filesystem, but insted directly to storage, which hosts raw data. Applications know they uploadede data via /whatever/path/was/to/the/file And they want to get that data from server via single 'get'. Obviously they can not store mapping from all filenames to inode number, and they can not request dozen of directory lookups, since it takes time and has to maintain state. When object was written via remounted path, then it is a problem for those who made a setup - this ugly hack only 'works' in specially crafted environment, which provides its pros and requires fair price of cons. Generic POHMELFS does not require this compatibility mode. -- 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
