Re: [take 3] pohmelfs: call for inclusion

[Evgeniy Polyakov <zbr@ioremap.net>]

On Wed, Mar 21, 2012 at 09:54:32PM +0000, Al Viro (viro@ZenIV.linux.org.uk) 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