Re: [reiserfs-list] Re: VM brokenness, possibly related to reiserfs

Re: [reiserfs-list] Re: VM brokenness, possibly related to reiserfs

[Chris Mason]

On Thursday, February 01, 2001 02:16:43 PM -0200 Rik van Riel <riel@conectiva.com.br> wrote:

> 
> About the system hanging completely, I wonder if it goes
> away by pressing sysrq-S (sync all disks). If it does,
> maybe Reiserfs was blocking all the pages in the inactive
> list from being written because one of the active pages
> (not a replacement candidate) needed to be written out
> first?  Or does the Reiserfs ->writepage() function handle
> this?
> 

In most cases, the reiserfs writepage func is the same as block_write_full_page.  The only difference should come when a packed tail has been mmap'd.

Since JOURNAL_MAX_BATCH was at 100, the log should have only pinned 400k.  More blocks could be pinned, but kreiserfsd should be in the process of flushing those.

I've been trying out a few things to send memory pressure down to reiserfs, but they have mostly been based on the code to make fs/buffer.c use writepage for flushing.  I should have done something simple first, I'll start on that now.

-chris

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
Please read the FAQ at http://www.tux.org/lkml/

Re: [reiserfs-list] Re: VM brokenness, possibly related to reiserfs

[David Ford]

My apologies...my internic data isn't updated, http://208.179.0.18/VM/

-d


--
  There is a natural aristocracy among men. The grounds of this are virtue and talents. Thomas Jefferson
  The good thing about standards is that there are so many to choose from. Andrew S. Tanenbaum



-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
Please read the FAQ at http://www.tux.org/lkml/

Re: [reiserfs-list] Re: VM brokenness, possibly related to reiserfs

[David Ford]

Chris Mason wrote:

> Sorry, can't seem to resolve stuph.org.  What is kreiserfsd doing during when the system is waiting for more ram?  With JOURNAL_MAX_BATCH set to 100, kreiserfsd will end up responsible for sending log blocks/metadata to disk and freeing the pinned buffers.
>
> -chris

(http://208.179.0.18/VM/)

[schedule_timeout+115/148] [process_timeout+0/72] [interruptible_sleep_on_timeout+66/92] [reiserfs_journal_commit_thread+173/224] [kernel_thread+40/56]

-d

--
  There is a natural aristocracy among men. The grounds of this are virtue and talents. Thomas Jefferson
  The good thing about standards is that there are so many to choose from. Andrew S. Tanenbaum



-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
Please read the FAQ at http://www.tux.org/lkml/

Re: [reiserfs-list] Re: VM brokenness, possibly related to reiserfs

[David Ford]

My apologies...my internic data isn't updated, http://208.179.0.18/VM/

-d


--
  There is a natural aristocracy among men. The grounds of this are virtue and talents. Thomas Jefferson
  The good thing about standards is that there are so many to choose from. Andrew S. Tanenbaum



-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
Please read the FAQ at http://www.tux.org/lkml/

Re: [reiserfs-list] Re: VM brokenness, possibly related to reiserfs

[David Ford]

Chris Mason wrote:

> 
> On Thursday, February 01, 2001 02:16:43 PM -0200 Rik van Riel <riel@conectiva.com.br> wrote:
> 
>> About the system hanging completely, I wonder if it goes
>> away by pressing sysrq-S (sync all disks). If it does,
>> maybe Reiserfs was blocking all the pages in the inactive
>> list from being written because one of the active pages
>> (not a replacement candidate) needed to be written out
>> first?  Or does the Reiserfs ->writepage() function handle
>> this?
> 

In answer to Rik's question, no, sysrq-S doesn't fix it.  The sound of 
the disk grind changes momentarily then it resumes.

> In most cases, the reiserfs writepage func is the same as block_write_full_page.  The only difference should come when a packed tail has been mmap'd.
> 
> Since JOURNAL_MAX_BATCH was at 100, the log should have only pinned 400k.  More blocks could be pinned, but kreiserfsd should be in the process of flushing those.
> 
> I've been trying out a few things to send memory pressure down to reiserfs, but they have mostly been based on the code to make fs/buffer.c use writepage for flushing.  I should have done something simple first, I'll start on that now.
> 
> -chris


http://stuph.org/VM/ is back up, no thanks to the network solutions.  
The files listed there have all the relevant backtraces.

-d


-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
Please read the FAQ at http://www.tux.org/lkml/