[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20080814084011.GB6422@skywalker>
Date: Thu, 14 Aug 2008 14:10:11 +0530
From: "Aneesh Kumar K.V" <aneesh.kumar@...ux.vnet.ibm.com>
To: Mingming Cao <cmm@...ibm.com>
Cc: tytso <tytso@....edu>, linux-ext4@...r.kernel.org,
Andreas Dilger <adilger@....com>
Subject: Re: [PATCH 5/6 ]Ext4 journal credits reservation fixes
On Wed, Aug 13, 2008 at 06:01:10PM -0700, Mingming Cao wrote:
....
....
> > > +static int ext4_writepages_trans_blocks(struct inode *inode)
> > > +{
> > > + int bpp = ext4_journal_blocks_per_page(inode);
> > > + int max_blocks = EXT4_MAX_WRITEPAGES_SIZE * bpp;
> > > +
> > > + if (max_blocks > EXT4_I(inode)->i_reserved_data_blocks)
> > > + max_blocks = EXT4_I(inode)->i_reserved_data_blocks;
> >
> >
> >
> > Why are we limiting max_blocks to i_reserved_data_blocks ?
> >
>
> i_reserved_data_blocks is the total number of "delayed" blocks that need
> block allocation. That's a counter being adds up at each write_begin()
> when the block allocation is defered. That's a accurate counter to
> indicate the max number of allocation we need to flush all dirty pages
> to disk for this inode, fits well when we need to calculate the credits
> for da_writepages.
>
> Now that we don't have PAGEVEC limit, we could use this to limit the
> total number of blocks to allocate when estimate the credit. But if
> this i_reserved_data_blocks gets too large, that can't fit into one
> single transaction, later get_block() will overflow the journal, we need
> someway to limit the number of pages to flush still:(
We should be requesting for credits needed for
EXT4_I(inode)->i_reserved_data_blocks with chunk = 1. If we don't have
that many credits we can limit max_blocks with EXT4_BLOCKS_PER_GROUP
if (EXT4_I(inode)->i_reserved_data_blocks > EXT4_BLOCKS_PER_GROUP)
max_blocks = EXT4_BLOCKS_PER_GROUP;
else
max_blocks = EXT4_I(inode)->i_reserved_data_blocks;
>
> >
> > > +
-aneesh
--
To unsubscribe from this list: send the line "unsubscribe linux-ext4" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Powered by blists - more mailing lists