Hi Xin,
On Thu 29-03-07 10:41:01, Xin Zhao wrote:
> I know we can use device inode's radix tree to achieve the same goal.
> The only downside could be: First, by default, Linux will not add the
> data pages into that radix tree. Only when a file is opened in
Right.
> O_DIRECT, the data pages
Hi Xin,
On Thu 29-03-07 10:41:01, Xin Zhao wrote:
I know we can use device inode's radix tree to achieve the same goal.
The only downside could be: First, by default, Linux will not add the
data pages into that radix tree. Only when a file is opened in
Right.
O_DIRECT, the data pages
Hi Jan,
Many thanks for your kind reply.
I know we can use device inode's radix tree to achieve the same goal.
The only downside could be: First, by default, Linux will not add the
data pages into that radix tree. Only when a file is opened in
O_DIRECT, the data pages will be put into dev's
Hello,
> Now I want to explain the problem that leads me to explore the Linux
> disk cache management. This is actually from my project. In a file
> system I am working on, two files may have different inodes, but share
> the same data blocks. Of course additional block-level reference
>
Hello,
Now I want to explain the problem that leads me to explore the Linux
disk cache management. This is actually from my project. In a file
system I am working on, two files may have different inodes, but share
the same data blocks. Of course additional block-level reference
counting
Hi Jan,
Many thanks for your kind reply.
I know we can use device inode's radix tree to achieve the same goal.
The only downside could be: First, by default, Linux will not add the
data pages into that radix tree. Only when a file is opened in
O_DIRECT, the data pages will be put into dev's
You are right. If the device is very big, the radix tree could be huge
as well. Maybe the lookup it not that cheap. But the per-device tree
can be optimized too. A simple way I can immediately image is: evenly
split a device into N parts by the sector numbers. For each part, we
maintain a radix
Thanks a lot! Folks!
Your reply addressed my concern.
Now I want to explain the problem that leads me to explore the Linux
disk cache management. This is actually from my project. In a file
system I am working on, two files may have different inodes, but share
the same data blocks. Of course
On Wed, 2007-03-28 at 02:45 -0400, Xin Zhao wrote:
> Hi,
>
> If a Linux process opens and reads a file A, then it closes the file.
> Will Linux keep the file A's data in cache for a while in case another
> process opens and reads the same in a short time? I think that is what
> I heard before.
according to the chapter "Linux Kernel Overview" of the
kernelhacking-HOWTO the page cache holds pages associated with *open*
files:
The Page Cache
The page cache is made up of pages, each of which refers to a 4kB
portion of data associated with an open file. The data contained in a
page may
Hi,
generic_forget_inode() don't call trancate_inode_pages() if FS is still active
see the 10449 line below:
1040 static void generic_forget_inode(struct inode *inode)
1041 {
1042 struct super_block *sb = inode->i_sb;
1043
1044 if (!hlist_unhashed(>i_hash)) {
1045
Hi,
generic_forget_inode() don't call trancate_inode_pages() if FS is still active
see the 10449 line below:
1040 static void generic_forget_inode(struct inode *inode)
1041 {
1042 struct super_block *sb = inode-i_sb;
1043
1044 if (!hlist_unhashed(inode-i_hash)) {
1045
according to the chapter Linux Kernel Overview of the
kernelhacking-HOWTO the page cache holds pages associated with *open*
files:
The Page Cache
The page cache is made up of pages, each of which refers to a 4kB
portion of data associated with an open file. The data contained in a
page may come
On Wed, 2007-03-28 at 02:45 -0400, Xin Zhao wrote:
Hi,
If a Linux process opens and reads a file A, then it closes the file.
Will Linux keep the file A's data in cache for a while in case another
process opens and reads the same in a short time? I think that is what
I heard before.
Yes.
Thanks a lot! Folks!
Your reply addressed my concern.
Now I want to explain the problem that leads me to explore the Linux
disk cache management. This is actually from my project. In a file
system I am working on, two files may have different inodes, but share
the same data blocks. Of course
You are right. If the device is very big, the radix tree could be huge
as well. Maybe the lookup it not that cheap. But the per-device tree
can be optimized too. A simple way I can immediately image is: evenly
split a device into N parts by the sector numbers. For each part, we
maintain a radix
Hi,
If a Linux process opens and reads a file A, then it closes the file.
Will Linux keep the file A's data in cache for a while in case another
process opens and reads the same in a short time? I think that is what
I heard before.
But after I digged into the kernel code, I am confused.
When a
Hi,
If a Linux process opens and reads a file A, then it closes the file.
Will Linux keep the file A's data in cache for a while in case another
process opens and reads the same in a short time? I think that is what
I heard before.
But after I digged into the kernel code, I am confused.
When a
18 matches
Mail list logo
