Chris Mason wrote:
Daniel Phillips wrote:
Simply stated, the new cache design divides filesystem blocks into two
classes: those that can be memory-mapped and those that can't. There
is no defined way to move a given block from one class to the other.
This is the sequence of events
On Tue, 12 Sep 2000, Daniel Phillips wrote:
After thinking about it last night I saw the correct approach. I need
a new page cache primitive:
struct page *getpage (struct address_space *mapping, unsigned long
index)
This is getblk, except for pages. It finds or sets up a page in a
On Tue, 12 Sep 2000, Daniel Phillips wrote:
Chris Mason wrote:
Now I can unmerge this way:
- Fix up various inode fields
- getpage the tail page from the mapping
- bread the shared tail block
- get the appropriate page buffer using page_buffer
- copy the tail
--On 09/12/00 10:17:29 -0400 Alexander Viro [EMAIL PROTECTED] wrote:
On Tue, 12 Sep 2000, Daniel Phillips wrote:
Chris Mason wrote:
Now I can unmerge this way:
- Fix up various inode fields
- getpage the tail page from the mapping
- bread the shared tail block
--On 09/12/00 10:30:28 -0400 Alexander Viro [EMAIL PROTECTED] wrote:
On Tue, 12 Sep 2000, Chris Mason wrote:
Almost, truncate could remove the file items in the middle of the
unmerge.
proc1: writepage-prepare_write-unmerge
Chris, RTFPOSIX. pageout should _never_ expand the file.
Alexander Viro wrote:
Do it in -prepare_write() if page is the last one. End of story. You'll
have to call the thing in your truncate() (expanding case) and that's it.
Pageout _never_ changes the file size, write and truncate own the -i_sem.
So "page covers the end of file" is not going to
Alexander Viro wrote:
On Tue, 12 Sep 2000, Daniel Phillips wrote:
Alexander Viro wrote:
On Tue, 12 Sep 2000, Daniel Phillips wrote:
This is getblk, except for pages. It finds or sets up a page in a
mapping. It puts buffers on the page if necessary but doesn't cause
On Tue, 12 Sep 2000, Chris Mason wrote:
--On 09/12/00 10:30:28 -0400 Alexander Viro [EMAIL PROTECTED] wrote:
On Tue, 12 Sep 2000, Chris Mason wrote:
Almost, truncate could remove the file items in the middle of the
unmerge.
proc1: writepage-prepare_write-unmerge
--On 09/12/00 10:47:23 -0400 Alexander Viro [EMAIL PROTECTED] wrote:
On Tue, 12 Sep 2000, Chris Mason wrote:
--On 09/12/00 10:30:28 -0400 Alexander Viro [EMAIL PROTECTED] wrote:
On Tue, 12 Sep 2000, Chris Mason wrote:
Almost, truncate could remove the file items in the
Alexander Viro wrote:
On Tue, 12 Sep 2000, Daniel Phillips wrote:
There is a very heavy investment in generic_read/write/mmap - I don't
want to throw that away. This is a mod to Ext2, and Ext2 uses these
Oh, but these functions don't need to be modified. Change
10 matches
Mail list logo
