Re: Reconsidering exportable UBIFS

[NeilBrown <nfbrown@novell.com>]

[-- Attachment #1: Type: text/plain, Size: 2608 bytes --]


(added linux-nfs@vger.kernel.org)

On Tue, Apr 05 2016, Richard Weinberger wrote:

> Hi!
>
> Currently UBIFS is not exportable.
> I'm not sure whether it is completely impossible or if I just miss a detail.
> So I've some questions.
>
> Documentation/filesystems/nfs/Exporting states that the only required function
> is fh_to_dentry().
> This function should on UBIFS be implementable using generic_fh_to_dentry().
> While UBIFS reuses in theory inode numbers we can ignore i_generation as
> the flash chip is long dead before we start reusing inodes. Same as for JFFS2.
> But the same document states also that fh_to_parent() and get_parent() are optional
> but strongly recommended.
> What does this mean? Will NFS work but puppies die and turn into
> zombies?

Not puppies, just kittens.

If you don't provide these functions, then exporting with
"subtree_check" won't work.  That is no great loss except that people
might find the failure confusing.


>
> Implementing get_parent() is a little unpleasant.
> UBIFS's on-flash layout does not support querying the parent.
> We could change UBIFS's struct ubifs_ino_node, but I'd change the
> on-flash layout only as last resort.
>
> The biggest problem I see is that UBIFS does not really support telldir()
> and seekdir().
> Directory offsets in UBIFS are plain hash values, so telldir()/seekdir() won't
> correctly work if UBIFS faces hash collisions.
> Currently UBIFS implements a hack which stores the UBIFS dent object into
> file->private_data such that consecutive readdir()s are guaranteed to work.
> A comment on UBIFS's readdir states:
>  * This means that UBIFS cannot support NFS which requires full
>  * 'seekdir()'/'telldir()' support.
>
> Is this still true? Maybe we can have NFS even if it is not perfect in
> terms of performance.

How big are your hashes?
ext3 messed up their readdir/telldir design too so they don't have
guaranteed unique keys.
When using 32bit hashes you can definitely get problems with
collisions.  I have not heard of problems with 64bit hashes.

I may have the details slightly wrong, but as I recall non-uniqueness of
cookies only causes a problem when the last cookie returned in a READDIR
reply matches the first cookie returned in reply to the next readdir.
So non-uniqueness is only a problem when it aligns badly.

NeilBrown


>
> Artem, did I miss another show stopper? :-)
>
> Thanks,
> //richard
> --
> To unsubscribe from this list: send the line "unsubscribe linux-fsdevel" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 818 bytes --]