Re: [reiserfs-list] Re: VM brokenness, possibly related to reiserfs
On Thursday, February 01, 2001 02:16:43 PM -0200 Rik van Riel <[EMAIL PROTECTED]> 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 [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: [reiserfs-list] Re: VM brokenness, possibly related to reiserfs
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 [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: [reiserfs-list] Re: VM brokenness, possibly related to reiserfs
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 [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: [reiserfs-list] Re: VM brokenness, possibly related to reiserfs
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 [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: [reiserfs-list] Re: VM brokenness, possibly related to reiserfs
Chris Mason wrote: > > On Thursday, February 01, 2001 02:16:43 PM -0200 Rik van Riel ><[EMAIL PROTECTED]> 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 [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
