How can I completely evict(remove) the inode from memory and access the disk next time?

How can I completely evict(remove) the inode from memory and access the disk next time?

[Daegyu Han]

Hi linux file system experts,

I'm so sorry that I've asked again the general question about Linux
file systems.

For example, if there is a file a.txt in the path /foo/ bar,
what should I do to completely evict(remove) the inode of bar
directory from memory and read the inode via disk access?

A few weeks ago. I asked a question about dentry and Ted told me that
there is a negative dentry on Linux.

I tried to completely evict(remove) the dentry cache using FS API in
include/fs.h and dcache.h, and also evict the inode from memory, but I
failed.

The FS API I used is:
dput() // to drop usage count and remove from dentry cache
iput() // to drop usage count and remove from inode cache.

To be honest, I'm confused about which API to cope with my question.

As far as I know, even though metadata is released from the file
system cache, it is managed as an LRU list.

I also saw some code related to CPU cacheline.
When I look at the superblock structure, there are also inodes, dcache
lists, and LRUs.

How can I completely evict the inode from memory and make disk access
as mentioned above?

Thank you in advance

Re: How can I completely evict(remove) the inode from memory and access the disk next time?

[Theodore Y. Ts'o]

On Wed, Oct 02, 2019 at 05:30:21PM +0900, Daegyu Han wrote:
> Hi linux file system experts,
> 
> I'm so sorry that I've asked again the general question about Linux
> file systems.
> 
> For example, if there is a file a.txt in the path /foo/ bar,
> what should I do to completely evict(remove) the inode of bar
> directory from memory and read the inode via disk access?

There is no API to do this from userspace.  The only way to do this is
to unmount the entire file system.

From the kernel, it's *way* more complicated than this.  Making a
shared-disk file system requires a lot more changes to the kernel
code.  You might want to take a look at ocfs2.  This was a file system
that started using the ext3 file system code, and **extensive**
kernel-level code changes were made to make it be a shared-disk file
system.

						- Ted
						

Re: How can I completely evict(remove) the inode from memory and access the disk next time?

[Daegyu Han]

Thank you for your consideration.

Okay, I will check ocfs2 out.

By the way, is there any possibility to implement this functionality
in the vfs layer?

I looked at the dcache.c, inode.c, and mm/vmscan.c code and looked at
several functions,
and as you said, they seem to have way complex logic.

The logic I thought was to release the desired dentry, dentry_kill()
the negative dentry, and break the inodes of the file that had that
dentry.

Can you tell me the detailed logic of the dentry and inode caches that
I'm curious about?
If not, can you give me a reference paper or book?

Best regards,
Daegyu

2019-10-02 21:46 GMT+09:00, Theodore Y. Ts'o <tytso@mit.edu>:
> On Wed, Oct 02, 2019 at 05:30:21PM +0900, Daegyu Han wrote:
>> Hi linux file system experts,
>>
>> I'm so sorry that I've asked again the general question about Linux
>> file systems.
>>
>> For example, if there is a file a.txt in the path /foo/ bar,
>> what should I do to completely evict(remove) the inode of bar
>> directory from memory and read the inode via disk access?
>
> There is no API to do this from userspace.  The only way to do this is
> to unmount the entire file system.
>
> From the kernel, it's *way* more complicated than this.  Making a
> shared-disk file system requires a lot more changes to the kernel
> code.  You might want to take a look at ocfs2.  This was a file system
> that started using the ext3 file system code, and **extensive**
> kernel-level code changes were made to make it be a shared-disk file
> system.
>
> 						- Ted
> 						
>

Re: How can I completely evict(remove) the inode from memory and access the disk next time?

[Eric W. Biederman]

Daegyu Han <dgswsk@gmail.com> writes:

> Thank you for your consideration.
>
> Okay, I will check ocfs2 out.
>
> By the way, is there any possibility to implement this functionality
> in the vfs layer?

The vfs does support this.  It is just the filesystems have to do their
part as well.

> I looked at the dcache.c, inode.c, and mm/vmscan.c code and looked at
> several functions,
> and as you said, they seem to have way complex logic.
>
> The logic I thought was to release the desired dentry, dentry_kill()
> the negative dentry, and break the inodes of the file that had that
> dentry.

That fundamentally doesn't work when writes are cached (as the vfs
does).

> Can you tell me the detailed logic of the dentry and inode caches that
> I'm curious about?
> If not, can you give me a reference paper or book?

Look at the revalidate method in the vfs.

Eric

Re: How can I completely evict(remove) the inode from memory and access the disk next time?

[Al Viro]

On Wed, Oct 02, 2019 at 05:30:21PM +0900, Daegyu Han wrote:
> Hi linux file system experts,
> 
> I'm so sorry that I've asked again the general question about Linux
> file systems.
> 
> For example, if there is a file a.txt in the path /foo/ bar,
> what should I do to completely evict(remove) the inode of bar
> directory from memory and read the inode via disk access?
> 
> A few weeks ago. I asked a question about dentry and Ted told me that
> there is a negative dentry on Linux.
> 
> I tried to completely evict(remove) the dentry cache using FS API in
> include/fs.h and dcache.h, and also evict the inode from memory, but I
> failed.
> 
> The FS API I used is:
> dput() // to drop usage count and remove from dentry cache
> iput() // to drop usage count and remove from inode cache.
> 
> To be honest, I'm confused about which API to cope with my question.
> 
> As far as I know, even though metadata is released from the file
> system cache, it is managed as an LRU list.
> 
> I also saw some code related to CPU cacheline.
> When I look at the superblock structure, there are also inodes, dcache
> lists, and LRUs.
> 
> How can I completely evict the inode from memory and make disk access
> as mentioned above?

In general you simply can't.  Not if there is anyone who'd opened the file
in question.  As long as the sucker is opened, struct inode *WILL* remain
in memory.

What are you trying to achieve?

Re: How can I completely evict(remove) the inode from memory and access the disk next time?

[Theodore Y. Ts'o]

On Wed, Oct 02, 2019 at 11:42:47PM +0900, Daegyu Han wrote:
> Thank you for your consideration.
> 
> Okay, I will check ocfs2 out.
> 
> By the way, is there any possibility to implement this functionality
> in the vfs layer?
> 
> I looked at the dcache.c, inode.c, and mm/vmscan.c code and looked at
> several functions,
> and as you said, they seem to have way complex logic.
> 
> The logic I thought was to release the desired dentry, dentry_kill()
> the negative dentry, and break the inodes of the file that had that
> dentry.

The short version is that objects have dependencies on other objects.
For example, a file descriptor object has a reference to the dentry of
the file which is open.  A file dentry or directory dentry object
references its parent directory's dentry object, etc.  You can not
evict an object when other objects have references on it --- otherwise
those references become dangling pointers, Which Would Be Bad.

There are solutions for remote file systems (network, clustered, and
shared disk file systems).  So the VFS layer can support these file
systems quite well.  Look at ceph, nfs, ofs2, and gfs for examples for
that.  But it's *complicated* because doing it in a way which is
highly performant, both for remote file systems, and as well as
supporting high-performance local disk file systems, is a lot more
than your very simple-minded, "just kill the dentry/inode structures
and reread them from disk".

Are you trying to do this for a university class project or some such?
If so, we're not here to do your homework for you.  If you want a
practical solution, please use an existing shared-disk or networked
file system.

Best regards,

					- Ted

Re: How can I completely evict(remove) the inode from memory and access the disk next time?

[Daegyu Han]

Thank you for your answer.

I'm so sorry I asked my personal project question here.
Yes, I will use a shared disk file system.

Best regards,
Daegyu

2019-10-03 4:39 GMT+09:00, Theodore Y. Ts'o <tytso@mit.edu>:
> On Wed, Oct 02, 2019 at 11:42:47PM +0900, Daegyu Han wrote:
>> Thank you for your consideration.
>>
>> Okay, I will check ocfs2 out.
>>
>> By the way, is there any possibility to implement this functionality
>> in the vfs layer?
>>
>> I looked at the dcache.c, inode.c, and mm/vmscan.c code and looked at
>> several functions,
>> and as you said, they seem to have way complex logic.
>>
>> The logic I thought was to release the desired dentry, dentry_kill()
>> the negative dentry, and break the inodes of the file that had that
>> dentry.
>
> The short version is that objects have dependencies on other objects.
> For example, a file descriptor object has a reference to the dentry of
> the file which is open.  A file dentry or directory dentry object
> references its parent directory's dentry object, etc.  You can not
> evict an object when other objects have references on it --- otherwise
> those references become dangling pointers, Which Would Be Bad.
>
> There are solutions for remote file systems (network, clustered, and
> shared disk file systems).  So the VFS layer can support these file
> systems quite well.  Look at ceph, nfs, ofs2, and gfs for examples for
> that.  But it's *complicated* because doing it in a way which is
> highly performant, both for remote file systems, and as well as
> supporting high-performance local disk file systems, is a lot more
> than your very simple-minded, "just kill the dentry/inode structures
> and reread them from disk".
>
> Are you trying to do this for a university class project or some such?
> If so, we're not here to do your homework for you.  If you want a
> practical solution, please use an existing shared-disk or networked
> file system.
>
> Best regards,
>
> 					- Ted
>