Very Computer

Hello, Linus,

    Following patch exports remove_from_page_cache(). reiser4 stores all
    meta-data in the page cache. When piece of meta-data is removed,
    corresponding page has to be removed from the page cache (this is
    similar to truncate, but for meta-data), explicit call to
    remove_from_page_cache() is required at this point.

Please apply.
Nikita.
diff -rup -X dontdiff linus-bk-2.5/mm/filemap.c linux-2.5-reiser4/mm/filemap.c
--- linus-bk-2.5/mm/filemap.c   Fri Oct 18 03:00:41 2002

        __remove_from_page_cache(page);
        write_unlock(&mapping->page_lock);
 }
+EXPORT_SYMBOL(remove_from_page_cache);

 static inline int sync_page(struct page *page)
 {
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in

More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Could you please explain the code that needs it?  No one should
call this in individual filesystem drivers.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in

More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Quote:Christoph Hellwig writes:

 > > Hello, Linus,
 > >
 > >     Following patch exports remove_from_page_cache(). reiser4 stores all
 > >     meta-data in the page cache. When piece of meta-data is removed,
 > >     corresponding page has to be removed from the page cache (this is
 > >     similar to truncate, but for meta-data), explicit call to
 > >     remove_from_page_cache() is required at this point.
 >
 > Could you please explain the code that needs it?  No one should
 > call this in individual filesystem drivers.

Reiser4 stores meta-data in a huge balanced tree. This tree is kept
(partially) in the page cache. All pages in this tree are attached to
"fake" inode. Sometimes you need to remove node from the tree. At this
moment page has to be removed from the fake inode mapping.

Other file systems don't need remove_from_page_cache() because they only
store in the page cache data (and remove_from_page_cache() is called by
truncate()) and meta data that are never explicitly deleted (like
directory content in ext2).

Nikita.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in

More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

What about chaing truncate_inode_pages to take an additional len
argument so you don't have to remove all pages past an offset?

Quote:

> Other file systems don't need remove_from_page_cache() because they only
> store in the page cache data (and remove_from_page_cache() is called by
> truncate()) and meta data that are never explicitly deleted (like
> directory content in ext2).

Sorry, but that's wrong.  XFS does use the pagecache for all metadata and JFS
for all but the superblock (which is never changed durin use)

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in

More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Quote:Christoph Hellwig writes:

 > > Reiser4 stores meta-data in a huge balanced tree. This tree is kept
 > > (partially) in the page cache. All pages in this tree are attached to
 > > "fake" inode. Sometimes you need to remove node from the tree. At this
 > > moment page has to be removed from the fake inode mapping.
 >
 > What about chaing truncate_inode_pages to take an additional len
 > argument so you don't have to remove all pages past an offset?

It is possible, I think. But this will look more of a hack. Truncate is
rather for truncating mapping than cutting one page from the middle.

Besides, current truncate_inode_pages() with all its
radix_tree_gang_lookup()'s and two passes doesn't looks like easily
adaptable.

 >
 > >
 > > Other file systems don't need remove_from_page_cache() because they only
 > > store in the page cache data (and remove_from_page_cache() is called by
 > > truncate()) and meta data that are never explicitly deleted (like
 > > directory content in ext2).
 >
 > Sorry, but that's wrong.  XFS does use the pagecache for all metadata and JFS
 > for all but the superblock (which is never changed durin use)
 >

Interesting. Then, XFS and JFS meta data in the page cache probably
are linearly ordered, and there it is never necessary to remove meta
data page from the middle of the mapping, right?

Nikita.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in

More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

The issue is rather different for XFS and JFS.  in JFS most metadata
(actually all metadata but the small superblock) is stored in inodes,
and it's accessed through the pagecache mapping for those inodes.

All access to those pages doesn't go directly through the pagecache
interface but a small metapage wrapper.  When the page is removed it's synced
to disk and removed from the metapage hash, so that you can't acess it
anymore.  It might still be on the VM lists for a while.

XFS on the other hand only uses the blockdevice mapping to acess it's
metadata so it doesn't have to remove the page explicitly from the
cache ever.

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in

More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Quote:Christoph Hellwig writes:

 > > Interesting. Then, XFS and JFS meta data in the page cache probably
 > > are linearly ordered, and there it is never necessary to remove meta
 > > data page from the middle of the mapping, right?
 >
 > The issue is rather different for XFS and JFS.  in JFS most metadata
 > (actually all metadata but the small superblock) is stored in inodes,
 > and it's accessed through the pagecache mapping for those inodes.
 >
 > All access to those pages doesn't go directly through the pagecache
 > interface but a small metapage wrapper.  When the page is removed it's synced
 > to disk and removed from the metapage hash, so that you can't acess it
 > anymore.  It might still be on the VM lists for a while.

Interesting. But things like ->vm_writeback() and friends will go
directly to the page bypassing metapage wrapper, right? JFS checks that
page is still "live" on each low-level VM call?

 >
 > XFS on the other hand only uses the blockdevice mapping to acess it's
 > metadata so it doesn't have to remove the page explicitly from the
 > cache ever.
 >

Nikita.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in

More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Yes.

Quote:> JFS checks that
> page is still "live" on each low-level VM call?

Well, if the exntent in question doesn't exist anymore get_block()
will return a failure.  In practice that won't happen as those
pages still kept around are never dirty.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in

More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

That would be what we have been calling "punch", and is quite useful
for putting holes in files (i.e. making them sparse again).  This
can be used for InterMezzo (among other things) so that the KML log
file can be growing at the end, but being punched out at the start
so it doesn't use up a lot of disk space.

Not that I'm holding my breath on getting this in the kernel, but
it is definitely useful.

Cheers, Andreas
--
Andreas Dilger
http://www-mddsp.enel.ucalgary.ca/People/adilger/
http://sourceforge.net/projects/ext2resize/

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in

More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Quote:Andreas Dilger writes:

 > > > Reiser4 stores meta-data in a huge balanced tree. This tree is kept
 > > > (partially) in the page cache. All pages in this tree are attached to
 > > > "fake" inode. Sometimes you need to remove node from the tree. At this
 > > > moment page has to be removed from the fake inode mapping.
 > >
 > > What about chaing truncate_inode_pages to take an additional len
 > > argument so you don't have to remove all pages past an offset?
 >
 > That would be what we have been calling "punch", and is quite useful
 > for putting holes in files (i.e. making them sparse again).  This
 > can be used for InterMezzo (among other things) so that the KML log
 > file can be growing at the end, but being punched out at the start
 > so it doesn't use up a lot of disk space.

Abusing truncate for such things will remain abuse exactly. Separate
interface is required.

 >
 > Not that I'm holding my breath on getting this in the kernel, but
 > it is definitely useful.
 >
 > Cheers, Andreas

Nikita.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in

More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Actually, we may want that for other reasons anyway. In particular, I can
well imagine why a networked filesystem in particular might want to
invalidate a range of a file cache, but not necessarily all of it.

(Yeah, I don't know of any network filesystem that does invalidation on
anything but a file granularity, but I assume such filesystems have to
exist. Especially in cluster environments it sounds like a sane thing to
do invalidates on a finer granularity)

                        Linus

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in

More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

It's also very useful for HSM-software (Hirarcial Storage Management).

--
Ragnar Kj?rstad
Big Storage
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in

More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/