Hi,
On Wed, Mar 19, 2008 at 10:45:15AM +, Samuel Thibault wrote:
> [EMAIL PROTECTED], le Tue 18 Mar 2008 11:02:43 +0100, a écrit :
> > I don't know how the syncing works, so I can't really tell what the
> > problem is. If there are blocking points before the superblock read,
> > we need to ch
Michal Suchanek, le Wed 19 Mar 2008 16:55:48 +0100, a écrit :
> On 19/03/2008, Samuel Thibault <[EMAIL PROTECTED]> wrote:
> > Yes, that's what I meant actually: the diskfs_sync_everything() function
> > is able to trigger a lot of thread creations.
> >
> > A way to have things work correctly woul
On 19/03/2008, Samuel Thibault <[EMAIL PROTECTED]> wrote:
>
> Yes, that's what I meant actually: the diskfs_sync_everything() function
> is able to trigger a lot of thread creations.
>
> A way to have things work correctly would be by marking threads with a
> "level", i.e. diskfs_sync_everythin
[EMAIL PROTECTED], le Tue 18 Mar 2008 11:02:43 +0100, a écrit :
> On Mon, Mar 17, 2008 at 10:41:01AM +, Samuel Thibault wrote:
> > [EMAIL PROTECTED], le Sun 16 Mar 2008 08:52:56 +0100, a écrit :
>
> > > What makes me wonder is, how can it happen in the first place that
> > > so many requests a
Hi,
On Mon, Mar 17, 2008 at 10:41:01AM +, Samuel Thibault wrote:
> [EMAIL PROTECTED], le Sun 16 Mar 2008 08:52:56 +0100, a écrit :
> > What makes me wonder is, how can it happen in the first place that
> > so many requests are generated before the superblock is requested
> > during handling o
Thomas Bushnell BSG, le Mon 17 Mar 2008 15:09:12 -0400, a écrit :
>
> On Sun, 2008-03-16 at 08:52 +0100, [EMAIL PROTECTED] wrote:
> > Hi,
> >
> > On Tue, Mar 11, 2008 at 11:19:32AM +, Samuel Thibault wrote:
> > > [EMAIL PROTECTED], le Tue 11 Mar 2008 04:53:45 +0100, a écrit :
> >
> > > > [I]
On Sun, 2008-03-16 at 08:52 +0100, [EMAIL PROTECTED] wrote:
> Hi,
>
> On Tue, Mar 11, 2008 at 11:19:32AM +, Samuel Thibault wrote:
> > [EMAIL PROTECTED], le Tue 11 Mar 2008 04:53:45 +0100, a écrit :
>
> > > [I] suggested a more adaptive approach: Keep track of the existing
> > > threads, and
[EMAIL PROTECTED], le Sun 16 Mar 2008 08:52:56 +0100, a écrit :
> On Tue, Mar 11, 2008 at 11:19:32AM +, Samuel Thibault wrote:
> > [EMAIL PROTECTED], le Tue 11 Mar 2008 04:53:45 +0100, a écrit :
>
> > > [I] suggested a more adaptive approach: Keep track of the existing
> > > threads, and if no
Hi,
On Tue, Mar 11, 2008 at 11:19:32AM +, Samuel Thibault wrote:
> [EMAIL PROTECTED], le Tue 11 Mar 2008 04:53:45 +0100, a écrit :
> > [I] suggested a more adaptive approach: Keep track of the existing
> > threads, and if none of them makes progress in a certain amount of
> > time (say 100 ms
Hello,
[EMAIL PROTECTED], le Tue 11 Mar 2008 04:53:45 +0100, a écrit :
> [I] suggested a more adaptive approach: Keep track of the existing
> threads, and if none of them makes progress in a certain amount of
> time (say 100 ms), allow creating some more threads. But that was
> never implemented.
Hi,
On Sun, Mar 09, 2008 at 10:17:05PM -0400, Thomas Bushnell BSG wrote:
> On Mon, 2008-03-10 at 01:19 +, Samuel Thibault wrote:
> > This thread is syncing everything, i.e. asking a lot of writes,
> > which triggers the creation of a lot of threads. Unfortunately the
> > superblock was paged
Thomas Bushnell BSG, le Sun 09 Mar 2008 22:17:05 -0400, a écrit :
> On Mon, 2008-03-10 at 01:19 +, Samuel Thibault wrote:
> > This thread is syncing everything, i.e. asking a lot of writes, which
> > triggers the creation of a lot of threads. Unfortunately the superblock
> > was paged out, so
On Mon, 2008-03-10 at 01:19 +, Samuel Thibault wrote:
>
> This thread is syncing everything, i.e. asking a lot of writes, which
> triggers the creation of a lot of threads. Unfortunately the superblock
> was paged out, so they all block on reading it. Unfortunately, since in
> Debian there
While having a beer with Gianluca, I thought about a possible case:
> Thread 7 (thread 588.7):
> #5 0x08052472 in write_all_disknodes ()
> at /build/mbanck/hurd-20071119/build-tree/hurd/ext2fs/inode.c:592
> #6 0x08054a90 in diskfs_sync_everything (wait=0)
This thread is syncing everything,
Hello,
Sometimes ext2fs just hangs, and gdb-ing it shows a huge lot of threads
almost all blocked at hurd/ext2fs/getblk.c:236, i.e. on a dereference
of sblock (unfortunately I forgot to ask for a backtrace). I was
wondering: what happens if because of memory pressure the superblock
gets swapped o
15 matches
Mail list logo