Generic API for asynchronous filesystems (was Re: 2.3.99-pre6-pre7 sync_page in remove_inode_page)

Trond Myklebust (trond.myklebust@fys.uio.no)
27 Apr 2000 12:06:53 +0200


Perhaps I should explain more carefully what I see sync_page() being
useful for.

In essence I meant it to be a hint from the VFS to the underlying
filesystem that it wants to change the state of the page in some
fashion that is affected by/will affect asynchronous operations.

Currently, that means:

1) I want to grab the page lock. Please complete the pagein or
whatever other asynchronous operations that are holding us up.

2) I want to reclaim the page. Please put out any pending
asynchronous writes on this page as quickly as you can.

The idea with the latter is ultimately to provide a unified interface
for memory reclaiming. In particular I want to allow a cleanup of
shrink_mmap() to make it work on generic filesystems which support
asynchronous operations.

I thought that the 2 cases could be combined into 1 callback and that
the filesystem should be able to decide from context what exactly
needs to be done. Perhaps this assumption was wrong, and we should
implement

1) sync_page()
2) reclaim_page()

as 2 different callbacks?

Cheers,
Trond

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu
Please read the FAQ at http://www.tux.org/lkml/