On Wed, May 16, 2007 at 11:19:29AM +0100, David Howells wrote:
>
> However, page_mkwrite() isn't told which bit of the page is going to be
> written to. This means it has to ask prepare_write() to make sure the whole
> page is filled in. In other words, offset and to must be equal (in AFS I set
David Howells wrote:
Nick Piggin <[EMAIL PROTECTED]> wrote:
Dave is using prepare_write here to ensure blocks are allocated in the
given range. The filesystem's ->nopage function must ensure it is uptodate
before allowing it to be mapped.
Which is fine... assuming it's called. For blockdev
David Woodhouse <[EMAIL PROTECTED]> wrote:
> Really? Is it _really_ going to be modified?
Well, generic_file_buffered_write() doesn't check the success of the copy
before calling commit_write(), presumably because it uses
fault_in_pages_readable() first.
David
-
To unsubscribe from this list: se
Nick Piggin <[EMAIL PROTECTED]> wrote:
> Dave is using prepare_write here to ensure blocks are allocated in the
> given range. The filesystem's ->nopage function must ensure it is uptodate
> before allowing it to be mapped.
Which is fine... assuming it's called. For blockdev-based filesystems, t
On Wed, May 16, 2007 at 11:04:11PM +1000, Nick Piggin wrote:
> Chris Mason wrote:
> >On Wed, May 16, 2007 at 08:09:19PM +0800, David Woodhouse wrote:
> >
> >>On Wed, 2007-05-16 at 11:19 +0100, David Howells wrote:
> >>
> >>>The start and end points passed to block_prepare_write() delimit the
> >>>
Chris Mason wrote:
On Wed, May 16, 2007 at 08:09:19PM +0800, David Woodhouse wrote:
On Wed, 2007-05-16 at 11:19 +0100, David Howells wrote:
The start and end points passed to block_prepare_write() delimit the region of
the page that is going to be modified. This means that prepare_write()
do
On Wed, May 16, 2007 at 08:09:19PM +0800, David Woodhouse wrote:
> On Wed, 2007-05-16 at 11:19 +0100, David Howells wrote:
> > The start and end points passed to block_prepare_write() delimit the region
> > of
> > the page that is going to be modified. This means that prepare_write()
> > doesn't
On Wed, 2007-05-16 at 11:19 +0100, David Howells wrote:
> The start and end points passed to block_prepare_write() delimit the region of
> the page that is going to be modified. This means that prepare_write()
> doesn't need to fill it in if the page is not up to date.
Really? Is it _really_ goi
David Howells wrote:
David Chinner <[EMAIL PROTECTED]> wrote:
+ ret = block_prepare_write(page, 0, end, get_block);
As I understand the way prepare_write() works, this is incorrect.
I think it is actually OK.
The start and end points passed to block_prepare_write() delimit the re
David Chinner <[EMAIL PROTECTED]> wrote:
> + ret = block_prepare_write(page, 0, end, get_block);
As I understand the way prepare_write() works, this is incorrect.
The start and end points passed to block_prepare_write() delimit the region of
the page that is going to be modified. This means
Christoph Hellwig wrote:
On Mon, Mar 19, 2007 at 09:11:31PM +1100, Nick Piggin wrote:
I've got the patches in -mm now. I hope they will get merged when the
the next window opens.
I didn't submit the ->page_mkwrite conversion yet, because I didn't
have any callers to look at. It is is slightly
On Mon, Mar 19, 2007 at 09:11:31PM +1100, Nick Piggin wrote:
> I've got the patches in -mm now. I hope they will get merged when the
> the next window opens.
>
> I didn't submit the ->page_mkwrite conversion yet, because I didn't
> have any callers to look at. It is is slightly less trivial than f
Nick Piggin wrote:
David Chinner wrote:
On Mon, Mar 19, 2007 at 05:37:03PM +1100, Nick Piggin wrote:
David Chinner wrote:
+block_page_mkwrite(struct vm_area_struct *vma, struct page *page,
+ get_block_t get_block)
+{
+struct inode *inode = vma->vm_file->f_path.dentry->d_inod
Christoph Hellwig wrote:
On Mon, Mar 19, 2007 at 10:30:08AM +1100, David Chinner wrote:
Generic page_mkwrite functionality.
Filesystems that make use of the VM ->page_mkwrite() callout will generally use
the same core code to implement it. There are several tricky truncate-related
issues that
David Chinner wrote:
On Mon, Mar 19, 2007 at 05:37:03PM +1100, Nick Piggin wrote:
David Chinner wrote:
+block_page_mkwrite(struct vm_area_struct *vma, struct page *page,
+ get_block_t get_block)
+{
+ struct inode *inode = vma->vm_file->f_path.dentry->d_inode;
+
On Mon, Mar 19, 2007 at 10:30:08AM +1100, David Chinner wrote:
>
> Generic page_mkwrite functionality.
>
> Filesystems that make use of the VM ->page_mkwrite() callout will generally
> use
> the same core code to implement it. There are several tricky truncate-related
> issues that we need to de
On Mon, Mar 19, 2007 at 05:37:03PM +1100, Nick Piggin wrote:
> David Chinner wrote:
> >
> >+/*
> >+ * block_page_mkwrite() is not allowed to change the file size as it gets
> >+ * called from a page fault handler when a page is first dirtied. Hence
> >we must
> >+ * be careful to check for EOF co
David Chinner wrote:
Generic page_mkwrite functionality.
Filesystems that make use of the VM ->page_mkwrite() callout will generally use
the same core code to implement it. There are several tricky truncate-related
issues that we need to deal with here as we cannot take the i_mutex as we
normall
Generic page_mkwrite functionality.
Filesystems that make use of the VM ->page_mkwrite() callout will generally use
the same core code to implement it. There are several tricky truncate-related
issues that we need to deal with here as we cannot take the i_mutex as we
normally would for these path
19 matches
Mail list logo