Skip to contentSkip to conversation

When is export_operations.get_parent triggered?

DISCUSSION Luis de Bethencourt 3 participants 5 messages Nov 5, 2016 – Nov 8, 2016

Subsystems (3)
lore
Share & tools
lore
#0 lore raw

Hi all,

I recently played with adding the basics to make befs exportable via NFS [0].

I want to implement the get_parent member of the export_operations struct as well, but I can't seem to trigger this member being called. I have implemented a solution which I feel is wrong [1], but want to be able to test it before moving forward.

When is this member triggered? Any advice?

Thanks,
Luis

[0] https://lkml.org/lkml/2016/11/5/40
[1] https://github.com/luisbg/linux-befs/commit/a7d92c746469f1bd60dd1c905587915ecf9884f5

#1 lore raw
Quoted 10 lines · Luis de Bethencourt

Hi all,

I recently played with adding the basics to make befs exportable via NFS [0].

I want to implement the get_parent member of the export_operations struct as well, but I can't seem to trigger this member being called. I have implemented a solution which I feel is wrong [1], but want to be able to test it before moving forward.

When is this member triggered? Any advice?

This is required when a filehandle for a directory arrives, but the directory is not in the dcache.
NFSD needs to find dentries for the directory, the parent, the grandparent etc all the way up to the root.

The simplest way to trigger this is to mount the filesystem onto a different machine, 'cd' into a fairly deep directory, then reboot the server (or unexport, unmount, remount, re-export).
Now 'ls -l' on the client. That should trigger calls to ->get_parent.

->get_parent() is a log like performing a lookup of "..".

NeilBrown

#2 lore raw
Quoted 18 lines · NeilBrown
Quoted 10 lines · Luis de Bethencourt

Hi all,

I recently played with adding the basics to make befs exportable via NFS [0].

I want to implement the get_parent member of the export_operations struct as well, but I can't seem to trigger this member being called. I have implemented a solution which I feel is wrong [1], but want to be able to test it before moving forward.

When is this member triggered? Any advice?

This is required when a filehandle for a directory arrives, but the directory is not in the dcache.
NFSD needs to find dentries for the directory, the parent, the grandparent etc all the way up to the root.

Quoted 9 lines

The simplest way to trigger this is to mount the filesystem onto a different machine, 'cd' into a fairly deep directory, then reboot the server (or unexport, unmount, remount, re-export).
Now 'ls -l' on the client. That should trigger calls to ->get_parent.

->get_parent() is a log like performing a lookup of "..".

NeilBrown

Nice!

This makes a lot of sense. I just rebooted the server and saw the get_parent being called. Before I was mistakenly trying without a reboot, but thanks to your explanation now understand this better, the directory was still in the dcache and it was using this instead.

Thank you Neil,
Luis

#3 lore raw
Quoted 29 lines · Luis de Bethencourt
Quoted 18 lines · NeilBrown
Quoted 10 lines · Luis de Bethencourt

Hi all,

I recently played with adding the basics to make befs exportable via NFS [0].

I want to implement the get_parent member of the export_operations struct as well, but I can't seem to trigger this member being called. I have implemented a solution which I feel is wrong [1], but want to be able to test it before moving forward.

When is this member triggered? Any advice?

This is required when a filehandle for a directory arrives, but the directory is not in the dcache.
NFSD needs to find dentries for the directory, the parent, the grandparent etc all the way up to the root.

Quoted 9 lines

The simplest way to trigger this is to mount the filesystem onto a different machine, 'cd' into a fairly deep directory, then reboot the server (or unexport, unmount, remount, re-export).
Now 'ls -l' on the client. That should trigger calls to ->get_parent.

->get_parent() is a log like performing a lookup of "..".

NeilBrown

Quoted 6 lines

Nice!

This makes a lot of sense. I just rebooted the server and saw the get_parent being called. Before I was mistakenly trying without a reboot, but thanks to your explanation now understand this better, the directory was still in the dcache and it was using this instead.

I've also tested get_parent with "echo 2>/proc/sys/vm/drop_caches", after first creating a 2000-deep subdirectory heirarchy (to stress performance, and to make sure dcache had enough entries that drop_caches would reliably drop what I wanted). And I used the filehandle syscalls directly, to take nfsd out of the equation. See deep-fh-lookup in
git://linux-nfs.org/~bfields/fragments.git for my kludgey script. OK, rebooting may be easier.

--b.

#4 lore raw
Quoted 45 lines · J. Bruce Fields
Quoted 29 lines · Luis de Bethencourt
Quoted 18 lines · NeilBrown
Quoted 10 lines · Luis de Bethencourt

Hi all,

I recently played with adding the basics to make befs exportable via NFS [0].

I want to implement the get_parent member of the export_operations struct as well, but I can't seem to trigger this member being called. I have implemented a solution which I feel is wrong [1], but want to be able to test it before moving forward.

When is this member triggered? Any advice?

This is required when a filehandle for a directory arrives, but the directory is not in the dcache.
NFSD needs to find dentries for the directory, the parent, the grandparent etc all the way up to the root.

Quoted 9 lines

The simplest way to trigger this is to mount the filesystem onto a different machine, 'cd' into a fairly deep directory, then reboot the server (or unexport, unmount, remount, re-export).
Now 'ls -l' on the client. That should trigger calls to ->get_parent.

->get_parent() is a log like performing a lookup of "..".

NeilBrown

Quoted 6 lines

Nice!

This makes a lot of sense. I just rebooted the server and saw the get_parent being called. Before I was mistakenly trying without a reboot, but thanks to your explanation now understand this better, the directory was still in the dcache and it was using this instead.

I've also tested get_parent with "echo 2>/proc/sys/vm/drop_caches", after first creating a 2000-deep subdirectory heirarchy (to stress performance, and to make sure dcache had enough entries that drop_caches would reliably drop what I wanted). And I used the filehandle syscalls directly, to take nfsd out of the equation. See deep-fh-lookup in
git://linux-nfs.org/~bfields/fragments.git for my kludgey script. OK, rebooting may be easier.

Quoted 2 lines

--b.

Very interesting approach, stressing it.
Will add it to my repertoire.

Thanks,
Luis