On Wed, Jun 29, 2011 at 1:57 AM, Jan Kara <[email protected]> wrote:
> On Tue 28-06-11 14:30:55, Moffett, Kyle D wrote:
>> This is really helpful to me, but it's deviated a bit from solving
>> the original bug. ?Based on the last log that I generated showing that
>> the error occurs in journal_stop(), what else should I be testing?
> ?I was looking at it for a while but so far I have no idea...
>
Hi Jan,
I would like to suggest an approach that may help us track down these
sort of bugs more easily.
Add a new class_id argument to ext4_handle_dirty_metadata() and collect
statistics of used credits per class_id.
There are only so many types of journaled objects:
SUPER, GDT, BB, IB, ITB, IND, EXT, DATA, XATTR, QUOT...
So it shouldn't be a problem to save the statistics per handle.
If you look at struct jbd2_journal_handle, you will find a bunch of h_cow_XXX
fields intended as COW debugging counters.
We may as well turn these fields into a generic counters array, which can
be used by either COW debugging or credits debugging code.
This should be simple enough to implement and should provide
a more detailed report when buffer credits have run out.
However, if we are going to modify all call sites of
ext4_handle_dirty_metadata(),
it would be wise to also add an object_id (or a better name) argument
that will provide
the group no. or inode no. or quota type, or any other id relevant for
classification.
We can use this information, along with where, line, handle, ino,
block_nr, buffer_credits
and create a stable trace point in __ext4_handle_dirty_metadata().
Sorry for writing emails instead of patches...
Amir.
On 2011-06-29, at 1:10 AM, Amir Goldstein wrote:
> I would like to suggest an approach that may help us track down these
> sort of bugs more easily.
>
> Add a new class_id argument to ext4_handle_dirty_metadata() and collect
> statistics of used credits per class_id.
>
> There are only so many types of journaled objects:
> SUPER, GDT, BB, IB, ITB, IND, EXT, DATA, XATTR, QUOT...
> So it shouldn't be a problem to save the statistics per handle.
>
> If you look at struct jbd2_journal_handle, you will find a bunch of h_cow_XXX
> fields intended as COW debugging counters.
> We may as well turn these fields into a generic counters array, which can
> be used by either COW debugging or credits debugging code.
>
> This should be simple enough to implement and should provide
> a more detailed report when buffer credits have run out.
>
> However, if we are going to modify all call sites of
> ext4_handle_dirty_metadata(), it would be wise to also add an object_id
> (or a better name) argument that will provide the group no. or inode no.
> or quota type, or any other id relevant for classification.
>
> We can use this information, along with where, line, handle, ino,
> block_nr, buffer_credits and create a stable trace point in
> __ext4_handle_dirty_metadata().
One of the things I like about the ZFS/DMU transaction API is that instead
of the caller having to "just know" how many credits are needed to modify
the filesystem, the caller specifies the inodes/directories that will be
modified, and if new inodes are allocated in a "declaration" step before
starting the transaction. This allows the internal code to account for the
metadata will be modified, and avoids the knowledge of journal credits for
different update types all over the code.
Cheers, Andreas
2011/6/29 Andreas Dilger <[email protected]>
>
> On 2011-06-29, at 1:10 AM, Amir Goldstein wrote:
> > I would like to suggest an approach that may help us track down these
> > sort of bugs more easily.
> >
> > Add a new class_id argument to ext4_handle_dirty_metadata() and collect
> > statistics of used credits per class_id.
> >
> > There are only so many types of journaled objects:
> > SUPER, GDT, BB, IB, ITB, IND, EXT, DATA, XATTR, QUOT...
> > So it shouldn't be a problem to save the statistics per handle.
> >
> > If you look at struct jbd2_journal_handle, you will find a bunch of h_cow_XXX
> > fields intended as COW debugging counters.
> > We may as well turn these fields into a generic counters array, which can
> > be used by either COW debugging or credits debugging code.
> >
> > This should be simple enough to implement and should provide
> > a more detailed report when buffer credits have run out.
> >
> > However, if we are going to modify all call sites of
> > ext4_handle_dirty_metadata(), it would be wise to also add an object_id
> > (or a better name) argument that will provide the group no. or inode no.
> > or quota type, or any other id relevant for classification.
> >
> > We can use this information, along with where, line, handle, ino,
> > block_nr, buffer_credits and create a stable trace point in
> > __ext4_handle_dirty_metadata().
>
> One of the things I like about the ZFS/DMU transaction API is that instead
> of the caller having to "just know" how many credits are needed to modify
> the filesystem, the caller specifies the inodes/directories that will be
> modified, and if new inodes are allocated in a "declaration" step before
> starting the transaction. ?This allows the internal code to account for the
> metadata will be modified, and avoids the knowledge of journal credits for
> different update types all over the code.
Would you please give more details about this? I don't think it's
different from Jbd/Jbd2
at first glance
>
> Cheers, Andreas
>
>
>
>
>
> --
> To unsubscribe from this list: send the line "unsubscribe linux-ext4" in
> the body of a message to [email protected]
> More majordomo info at ?http://vger.kernel.org/majordomo-info.html
--
Ding Dinghua