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