Trond Myklebust wrote:
On Wed, 2006-12-13 at 12:56 +1100, Nick Piggin wrote:
Note that these pages should be *really* rare. Definitely even for normal
filesystems I think RMW would use too much bandwidth if it were required
for any significant number of writes.
If file "foo" exists on
On Wed, 2006-12-13 at 08:49 -0500, Peter Staubach wrote:
> Trond Myklebust wrote:
> > On Wed, 2006-12-13 at 12:56 +1100, Nick Piggin wrote:
> >
> >> Note that these pages should be *really* rare. Definitely even for normal
> >> filesystems I think RMW would use too much bandwidth if it were requ
On Wed, 2006-12-13 at 15:03 +1100, Nick Piggin wrote:
> Trond Myklebust wrote:
> > On Wed, 2006-12-13 at 12:56 +1100, Nick Piggin wrote:
> >
> >>Note that these pages should be *really* rare. Definitely even for normal
> >>filesystems I think RMW would use too much bandwidth if it were required
>
Trond Myklebust wrote:
On Wed, 2006-12-13 at 12:56 +1100, Nick Piggin wrote:
Note that these pages should be *really* rare. Definitely even for normal
filesystems I think RMW would use too much bandwidth if it were required
for any significant number of writes.
If file "foo" exists on the se
On Wed, 2006-12-13 at 12:56 +1100, Nick Piggin wrote:
> Note that these pages should be *really* rare. Definitely even for normal
> filesystems I think RMW would use too much bandwidth if it were required
> for any significant number of writes.
If file "foo" exists on the server, and contains data
On Wed, 2006-12-13 at 11:53 +1100, Nick Piggin wrote:
> Not silly -- I guess that is the main sticking point. Luckily *most*
> !uptodate pages will be ones that we have newly allocated so will
> not be in pagecache yet.
>
> If it is in pagecache, we could do one of a number of things: either
> re
Trond Myklebust wrote:
On Wed, 2006-12-13 at 11:53 +1100, Nick Piggin wrote:
Not silly -- I guess that is the main sticking point. Luckily *most*
!uptodate pages will be ones that we have newly allocated so will
not be in pagecache yet.
If it is in pagecache, we could do one of a number of th
Mark Fasheh wrote:
On Tue, Dec 12, 2006 at 02:52:26AM +1100, Nick Piggin wrote:
Nick Piggin wrote:
Hmm, doesn't look like we can do this either because at least GFS2
uses BH_New for its own special things.
Also, I don't know if the trick of only walking over BH_New buffers
will work anyway, s
On Tue, Dec 12, 2006 at 02:52:26AM +1100, Nick Piggin wrote:
> Nick Piggin wrote:
> >Mark Fasheh wrote:
>
> >>->commit_write() would probably do fine. Currently, block_prepare_write()
> >>uses it to know which buffers were newly allocated (the file system
> >>specific
> >>get_block_t sets the bit
Nick Piggin <[EMAIL PROTECTED]> writes:
> Finally, filesystems. Only OGAWA Hirofumi and Mark Fasheh have given much
> feedback so far. I've tried to grok ext2/3 and think they'll work OK, and
> have at least *looked* at all the rest. However in the worst case, there
> might be many subtle and diff
Hi,
On Tue, 2006-12-12 at 03:39 +1100, Nick Piggin wrote:
> Steven Whitehouse wrote:
>
> >>Hmm, doesn't look like we can do this either because at least GFS2
> >>uses BH_New for its own special things.
> >>
> >
> > What makes you say that? As far as I know we are not doing anything we
> > should
Steven Whitehouse wrote:
Hmm, doesn't look like we can do this either because at least GFS2
uses BH_New for its own special things.
What makes you say that? As far as I know we are not doing anything we
shouldn't with this flag, and if we are, then I'm quite happy to
consider fixing it up so
Hi,
On Tue, 2006-12-12 at 02:52 +1100, Nick Piggin wrote:
> Nick Piggin wrote:
> > Mark Fasheh wrote:
>
> >> ->commit_write() would probably do fine. Currently, block_prepare_write()
> >> uses it to know which buffers were newly allocated (the file system
> >> specific
> >> get_block_t sets the
Nick Piggin wrote:
Mark Fasheh wrote:
->commit_write() would probably do fine. Currently, block_prepare_write()
uses it to know which buffers were newly allocated (the file system
specific
get_block_t sets the bit after allocation). I think we could safely move
the clearing of that bit to bl
Nick Piggin wrote:
Mark Fasheh wrote:
If we make the change I described above (looking for BH_New buffers
outside
the range passed), then zero length or partial shouldn't matter, but zero
length instead of partial would be nicer imho just for the sake of
reducing
the total number of cases d
Mark Fasheh wrote:
On Fri, Dec 08, 2006 at 02:28:10PM +1100, Nick Piggin wrote:
In generic_file_buffered_write() we now do:
status = a_ops->commit_write(file, page, offset,offset+copied);
Which tells the file system to commit only the amount of data that
filemap_copy_from_user() was a
On Fri, Dec 08, 2006 at 02:28:10PM +1100, Nick Piggin wrote:
> >In generic_file_buffered_write() we now do:
> >
> > status = a_ops->commit_write(file, page, offset,offset+copied);
> >
> >Which tells the file system to commit only the amount of data that
> >filemap_copy_from_user() was able to p
Mark Fasheh wrote:
Hi Nick,
On Tue, Dec 05, 2006 at 05:52:02PM +1100, Nick Piggin wrote:
Hi,
I'd like to try to state where we are WRT the buffered write patches,
and ask for comments. Sorry for the wide cc list, but this is an
important issue which hasn't had enough review.
I pulled broke
Hi Nick,
On Tue, Dec 05, 2006 at 05:52:02PM +1100, Nick Piggin wrote:
> Hi,
>
> I'd like to try to state where we are WRT the buffered write patches,
> and ask for comments. Sorry for the wide cc list, but this is an
> important issue which hasn't had enough review.
I pulled broken-out-2006-12-0
Hi,
I'd like to try to state where we are WRT the buffered write patches,
and ask for comments. Sorry for the wide cc list, but this is an
important issue which hasn't had enough review.
Well the next -mm will include everything we've done so far. I won't
repost patches unless someone would like
20 matches
Mail list logo
