Deliberate forgetfulness

classic Classic list List threaded Threaded
3 messages Options
Reply | Threaded
Open this post in threaded view
|

Deliberate forgetfulness

Sebastian Unger
Hi Guys,

I'm writing a fuse file system (obviously ;-) and since I like to write unit tests for all my software, I want to do so for this as well. I've got a fairly good coverage, but I struggle to write unit tests that exercise the inode forget code paths. I'm using the low-level API.

Basically I need to somehow get the kernel to issue the forget signal for a previously looked up inode. I have read somewhere on this mailing list that the kernel issues forgets under any of these three conditions:
  1. The inode is deleted and it is not open
  2. Pressure on the cache
  3. The file-system is unmounted.
As far as I can tell, 3) does not actually pass the forget on to the user code and I haven't had any ideas on how to cause 2 to happen reliably without too much undue impact on the rest of the system (after all running unit tests shouldn't be that intrusive and should be rock-stable).

The first option sounded promising, but so far I haven't had any luck with it either. I do get the unlink operation for a file for which I answer with fuse_reply_err(req, 0) but I do not get any forgets for the file's inode afterwards. I'm certain the file is not open at this point.

Has anybody else come across something that might help here?

Cheers,
Seb

------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, SlashDot.org! http://sdm.link/slashdot
--
fuse-devel mailing list
To unsubscribe or subscribe, visit https://lists.sourceforge.net/lists/listinfo/fuse-devel
Reply | Threaded
Open this post in threaded view
|

Re: Deliberate forgetfulness

Sebastian Unger
Ok, never mind. I must simply be too tired. I forgot to add the op_forget function to the ops structure.

On 8 October 2016 at 22:08, Sebastian Unger <[hidden email]> wrote:
Hi Guys,

I'm writing a fuse file system (obviously ;-) and since I like to write unit tests for all my software, I want to do so for this as well. I've got a fairly good coverage, but I struggle to write unit tests that exercise the inode forget code paths. I'm using the low-level API.

Basically I need to somehow get the kernel to issue the forget signal for a previously looked up inode. I have read somewhere on this mailing list that the kernel issues forgets under any of these three conditions:
  1. The inode is deleted and it is not open
  2. Pressure on the cache
  3. The file-system is unmounted.
As far as I can tell, 3) does not actually pass the forget on to the user code and I haven't had any ideas on how to cause 2 to happen reliably without too much undue impact on the rest of the system (after all running unit tests shouldn't be that intrusive and should be rock-stable).

The first option sounded promising, but so far I haven't had any luck with it either. I do get the unlink operation for a file for which I answer with fuse_reply_err(req, 0) but I do not get any forgets for the file's inode afterwards. I'm certain the file is not open at this point.

Has anybody else come across something that might help here?

Cheers,
Seb


------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, SlashDot.org! http://sdm.link/slashdot
--
fuse-devel mailing list
To unsubscribe or subscribe, visit https://lists.sourceforge.net/lists/listinfo/fuse-devel
Reply | Threaded
Open this post in threaded view
|

Re: Deliberate forgetfulness

Nikolaus Rath
In reply to this post by Sebastian Unger
On Oct 08 2016, Sebastian Unger <[hidden email]> wrote:
> Hi Guys,
>
> I'm writing a fuse file system (obviously ;-) and since I like to write
> unit tests for all my software, I want to do so for this as well. I've got
> a fairly good coverage, but I struggle to write unit tests that exercise
> the inode forget code paths. I'm using the low-level API.
>
> Has anybody else come across something that might help here?

If you can run your tests as root, then /proc/sys/vm/drop_caches is your
friend. See eg. https://linux-mm.org/Drop_Caches


Best,
-Nikolaus

--
GPG encrypted emails preferred. Key id: 0xD113FCAC3C4E599F
Fingerprint: ED31 791B 2C5C 1613 AF38 8B8A D113 FCAC 3C4E 599F

             »Time flies like an arrow, fruit flies like a Banana.«

------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, SlashDot.org! http://sdm.link/slashdot
--
fuse-devel mailing list
To unsubscribe or subscribe, visit https://lists.sourceforge.net/lists/listinfo/fuse-devel