[linux-cifs-client] Re-exporting cifs mount over NFSv4

[Paul TBBle Hampson]

On Sat, Mar 08, 2008 at 09:59:14AM -0500, Christoph Hellwig wrote:
> On Fri, Mar 07, 2008 at 05:53:28PM +1100, Paul TBBle Hampson wrote:
>> I discovered the problem. In late October 2007, the exportfs
>> interface was changed [1], and cifs was not updated during the
>> update. (export.c was last touched non-trivially in early October)

> That's because the existing export code was not enough already and
> I'd rather let it not work at all than as dangerously half-working
> as it was before..

Fair enough. I was afraid that was the case. I did think it a little odd
that the only code needed to enable export was a get_parent that
returned the same failure as the default get_parent.

>> cifs currently is missing the one mandatory method fh_to_dentry in
>> the export_operations structure, so the exportfs code rejects it as
>> an exportable filesystem.

> It also needs at least a get_parent and a fh_to_parent if it wants
> to support subtree_check.  The former is currently marked optional
> but it actually is required for proper operation.  I will fix the
> documentation and add a check for it in my next batch of nfs exporting
> patches.

I noted that, but for the purposes of this attempt, I am using
no_subtree_check.

fh_to_parent is also marked optional, I believe.

>> I dunno if anyone's planning to fix this, I think I'll have a go
>> just pointing it at generic_fh_to_dentry (as this seems to be the
>> intended behaviour under the old API) and see if that works or if
>> it sets our machines on fire.

> I don't think this is correct.  As far as I can see cifs does not
> use stable inode numbers to identify object.  The file handles need
> to encode some form of identifaction that get back to an object in
> all cases, e.g. after dentry and inode cache are flushed or even if
> the exporting system crashed.

I was kinda of hoping that's what the serverino option did, provide
stable inode numbers (from the CIFS server). I was basing that on the
complete use of fallbacks in the old code, rather than any actual
evidence or understanding of the code.

I have to go read through things more thoroughly. I suspect that there's
prolly a better thing to identify with than serverino-based inodes
floating around in the cifs client code, given it doesn't use iget or
iput at all apart from the root inode.

This is my first visit to the fs/ tree, in case it's not obvious, so
it'll be slow going, if I make any progress at all.

Thanks for the feedback. ^_^

-- 
-----------------------------------------------------------
Paul "TBBle" Hampson, B.Sc, LPI, MCSE
Very-later-year Asian Studies student, ANU
The Boss, Bubblesworth Pty Ltd (ABN: 51 095 284 361)
Paul.Hampson at Pobox.com

Of course Pacman didn't influence us as kids. If it did,
we'd be running around in darkened rooms, popping pills and
listening to repetitive music.
 -- Kristian Wilson, Nintendo, Inc, 1989

License: http://creativecommons.org/licenses/by/2.1/au/
-----------------------------------------------------------
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
Url : http://lists.samba.org/archive/linux-cifs-client/attachments/20080309/763012c6/attachment.bin