Messages in this thread | | | Date | Tue, 13 Jan 1998 23:56:00 GMT | From | "Stephen C. Tweedie" <> | Subject | Re: [RFC] [PATCH] Dirty pages in the page cache |
| |
On 13 Jan 1998 05:59:30 -0600, ebiederm+eric@npwt.net (Eric W. Biederman) said:
> O.K. Then I guess the basic task is a follows. > For writepage (which really hasn't been used yet). Revert that to use > an inode (instead of a dentry).
We've already come across the problem that NFS needs dentries, not inodes. We solve this currently by doing all of the flushing from virtual memory to filesystem when we traverse the vm region or page tables: that way, we have the relevant vma in hand when we spot dirty data, and can get the dentry from that. We've recently got a patch which traverses vma's on a page clearing pte dirty bits whenever we msync such a page.
So, I guess the question is, why _exactly_ do you want to have dirty page cache pages? I'm not saying it's a bad idea, but you do need to identify precisely what problem you are trying to solve before we can say whether or not the solution is a brilliant idea!
> Reimplement the buffer_head pointer as a generic pointer, with a flag > that says it's a buffer_head pointer.
Possibly. The existing filesystems don't need it. You could certainly make things easier for some network filesystems by maintaining dirty data for them, but who is responsible for that dirty data? What happens when different users, or perhaps different dirent aliases for the same file, dirty the same page? These have to be filesystem policy decisions. I guess this means that the page cache changes you propose really are purely facilities for filesystem use, not to be used directly by any generic file IO routines.
So, once we have a page cache which can hold dirty data, who are you proposing is responsible for flushing that dirty data to backing store? I'm not sure whether you are suggesting a completely new mechanism for maintaining asynchronously written dirty data with callbacks into the filesystem, or whether the page cache extensions will do nothing extra on their own but will be called by the filesystem when it decides for itself that data needs to be written out.
> Update my current patch to these changes.
> Test it.
> Send it to Linus?
> Buffer cache changes, and ext2 support, and other filesystems. > Once the basic code is in place.
The ext2 support doesn't _need_ any changes to the page cache! It doesn't, strictly speaking, need any buffer cache changes either, but a new free-after-bdflush buffer type would be highly desirable just from a performance point of view --- there's no reason to maintain the physical view of the data past the point where it has reached disk.
Cheers, Stephen.
| |