On Mon, Jun 02, 2008 at 11:35:00AM +0200, Jan Kara wrote:
> > @@ -1052,6 +1051,7 @@ static int __mpage_da_writepage(struct page *page,
> > head = page_buffers(page);
> > bh = head;
> > do {
> > +
> I guess this line is a typo.
>
Yes, Mostly some debug lines I removed, but missed the newline added.
> > BUG_ON(buffer_locked(bh));
> > if (buffer_dirty(bh))
> > mpage_add_bh_to_extent(mpd, logical, bh);
> > diff --git a/mm/page-writeback.c b/mm/page-writeback.c
> > index 789b6ad..655b8bf 100644
> > --- a/mm/page-writeback.c
> > +++ b/mm/page-writeback.c
> > @@ -881,7 +881,12 @@ int write_cache_pages(struct address_space *mapping,
> > pagevec_init(&pvec, 0);
> > if (wbc->range_cyclic) {
> > index = mapping->writeback_index; /* Start from prev offset */
> > - end = -1;
> > + /*
> > + * write only till the specified range_end even in cyclic mode
> > + */
> > + end = wbc->range_end >> PAGE_CACHE_SHIFT;
> > + if (!end)
> > + end = -1;
> > } else {
> > index = wbc->range_start >> PAGE_CACHE_SHIFT;
> > end = wbc->range_end >> PAGE_CACHE_SHIFT;
> Are you sure you won't break other users of range_cyclic with this
> change?
>
I haven't run any specific test to verify that. The concern was that if
we force cyclic mode for writeout in delalloc we may be starting the
writeout from a different offset than specified and would be writing
more. So the changes was to use the offset specified. A quick look at
the kernel suggested most of them had range_end as 0 with cyclic_mode.
I haven't audited the full kernel. I will do that. Meanwhile if you
think it is risky to make this changes i guess we should drop this
part. But i guess we can keep the below change
+ index = mapping->writeback_index;
+ if (!range_cyclic) {
+ /*
+ * We force cyclic write out of pages. If the
+ * caller didn't request for range_cyclic update
+ * set the writeback_index to what the caller requested.
+ */
+ mapping->writeback_index = wbc->range_start >> PAGE_CACHE_SHIFT;
+ }
-aneesh
--
To unsubscribe from this list: send the line "unsubscribe linux-ext4" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
