OGAWA Hirofumi wrote:
Nick Piggin <[EMAIL PROTECTED]> writes:
status = __block_prepare_write(inode, new_page, zerofrom,
PAGE_CACHE_SIZE, get_block);
if (status)
@@ -2110,7 +2111,7 @@
memset(kaddr+ze
OGAWA Hirofumi <[EMAIL PROTECTED]> writes:
> Ah, unfortunately we can't this. If we don't update ->i_size before
> page_cache_release, pdflush will think these pages is outside ->i_size
> and just clean the page without writing it.
Ugh, of course, s/page_cache_release/unlock_page/
--
OGAWA Hirof
Nick Piggin <[EMAIL PROTECTED]> writes:
>> >status = __block_prepare_write(inode, new_page, zerofrom,
>> >PAGE_CACHE_SIZE, get_block);
>> >if (status)
>> > @@ -2110,7 +2111,7 @@
>> >memset(kaddr+zerofrom, 0, PAGE_CACHE
On Thu, Nov 30, 2006 at 11:21:02PM -0800, Andrew Morton wrote:
> On Fri, 1 Dec 2006 06:08:52 +0100
> Nick Piggin <[EMAIL PROTECTED]> wrote:
>
> > On Fri, Dec 01, 2006 at 12:41:25PM +0900, OGAWA Hirofumi wrote:
> > >
> > > Yes, this patch doesn't pass zero-length to prepare_write. However,
> > > I
On Fri, 1 Dec 2006 06:08:52 +0100
Nick Piggin <[EMAIL PROTECTED]> wrote:
> On Fri, Dec 01, 2006 at 12:41:25PM +0900, OGAWA Hirofumi wrote:
> >
> > Yes, this patch doesn't pass zero-length to prepare_write. However,
> > I'm not checking this patch is ok for reiserfs...
>
> OK, vfat wasn't working
On Fri, Dec 01, 2006 at 12:41:25PM +0900, OGAWA Hirofumi wrote:
>
> Yes, this patch doesn't pass zero-length to prepare_write. However,
> I'm not checking this patch is ok for reiserfs...
OK, vfat wasn't working correctly for me -- I needed the following patch:
Index: linux-2.6/fs/buffer.c
=
On Fri, Dec 01, 2006 at 12:41:25PM +0900, OGAWA Hirofumi wrote:
> Nick Piggin <[EMAIL PROTECTED]> writes:
> >
> > So basically this is changing from having prepare_write do all the
> > zeroing, to zeroing the last page in generic_cont_expand, so that
> > we don't have to pass a zero-length to prepa
Nick Piggin <[EMAIL PROTECTED]> writes:
> On Fri, Dec 01, 2006 at 07:14:28AM +0900, OGAWA Hirofumi wrote:
>>
>> quick look. Doesn't this break reiserfs? IIRC, the reiserfs is using
>> it for another reason. I was also working for this, but I lost the
>> thread of this, sorry.
>>
>> I found some
On Fri, Dec 01, 2006 at 07:14:28AM +0900, OGAWA Hirofumi wrote:
>
> quick look. Doesn't this break reiserfs? IIRC, the reiserfs is using
> it for another reason. I was also working for this, but I lost the
> thread of this, sorry.
>
> I found some another users (affs, hfs, hfsplus). Those seem ha
On Fri, Dec 01, 2006 at 10:11:14AM +0900, OGAWA Hirofumi wrote:
> Nick Piggin <[EMAIL PROTECTED]> writes:
>
> > I would be happy if you come up with a quick fix, I'm just trying to
> > stamp out a few big bugs in mm. However I did prefer my way of moving
> > all the exapand code into generic_cont_
Nick Piggin <[EMAIL PROTECTED]> writes:
> I would be happy if you come up with a quick fix, I'm just trying to
> stamp out a few big bugs in mm. However I did prefer my way of moving
> all the exapand code into generic_cont_expand, out of prepare_write, and
> avoiding holding the target page locke
On Fri, Dec 01, 2006 at 07:14:28AM +0900, OGAWA Hirofumi wrote:
>
> quick look. Doesn't this break reiserfs? IIRC, the reiserfs is using
> it for another reason. I was also working for this, but I lost the
> thread of this, sorry.
Yes I think it will break reiserfs, so I just have to have a look
Nick Piggin <[EMAIL PROTECTED]> writes:
> Rework the cont filesystem helpers so that generic_cont_expand does the
> actual work of expanding the file. cont_prepare_write then calls this
> routine if expanding is needed, and retries. Also solves the problem
> where cont_prepare_write would previous
Sorry, missed a hunk which prevented fat from linking :(
---
Rework the cont filesystem helpers so that generic_cont_expand does the
actual work of expanding the file. cont_prepare_write then calls this
routine if expanding is needed, and retries. Also solves the problem
where cont_prepare_write
14 matches
Mail list logo
