Messages in this thread | | | Subject | Re: Journaled FS | From | (Eric W. Biederman) | Date | 19 Jun 1998 16:29:08 -0500 |
| |
>>>>> "AB" == Adam D Bradley <artdodge@cs.bu.edu> writes:
AB> On 19 Jun 1998, Eric W. Biederman wrote:
AB> Indeed. I would be interested in any white papers or other documents AB> describing how your architecture works, what interface it will present AB> to filesystems, etc.
See below
AB> LFS's require the ability to change a buffer's "physical association" AB> i.e., when a buffer is dirtied it must (a) not be written back to its AB> original location and (b) eventually be assigned a new block location. AB> I would imagine the LVM layer would require a similar capability for AB> the physical volume removal case at least. How well would your AB> interface cope with this?
The moving block problem is at the generic level trivial, but the generic level that I'm coding doesn't do the work for you.
Roghly here is what I have.
I start with the current page cache, which has good read in behavior, and caches data in the form it will be used in.
To struct page I add: - A PG_Dirty bit to the flags field - void *pg_generic to hold page specific information.
I add two inode operations.
pg_clearpage - which is called just before the page is removed from the page cache, so any tracking information can be released. pg_writepage - which is called to write the page out to disk
Somewhere in file_write you are responsible for allocating all the resources a file will block will need to be written and calling mark_page_dirty(page)
pg_writepage will then sometime later (called by pgflushd a clone of kflushd, but for pages) call pg_writepage to send the page to disk.
The restriction on pg_writepage is it will not fail except for catastrophic errors that's why you need to allocate your disk resources first. This is needed because a delayed writeback can't return an error to user space.
I should have a completed and tested version in a week or two. I'm 3/4 done with the code now.
A preliminary version of the code is included with my shmfs package, which is my test case of a filesystem that uses this.
The current work I am doing is adding pgflush support (instead of writing from shrink_mmap when the page is needed), and making sure the generic routines appear to be sufficient for any cause.
For the case of moving files about on physical storage, I can handle swapoff without problems, while my filesystem is running. Except when swapoff should fail, I would up locking the machine trying to allocate memory I believe.
It is located at: http://www.npwt.net/~ebiederm/files shmfs-0.1.009.tar.gz
Eric
- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.rutgers.edu
| |