Re: [RFC] Journal credits debugging (Was: Re: Bug#615998: ...)

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



2011/6/29 Andreas Dilger <adilger@xxxxxxxxx>
>
> 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 majordomo@xxxxxxxxxxxxxxx
> More majordomo info at  http://vger.kernel.org/majordomo-info.html



--
Ding Dinghua
--
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


[Index of Archives]     [Reiser Filesystem Development]     [Ceph FS]     [Kernel Newbies]     [Security]     [Netfilter]     [Bugtraq]     [Linux FS]     [Yosemite National Park]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux RAID]     [Samba]     [Device Mapper]     [Linux Media]

  Powered by Linux