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

Re: freeing, allocating and free blocks in Ext3



Alexander Viro wrote:
> 
> On Wed, 2 May 2001, Andrew Morton wrote:
> 
> > Ah. lock_super().  I nearly fell out of my tree when I saw that
> > thing.  ext3 has lock_journal(), which is a clone.  Did I hear
> > a rumour that you had a replacement for lock_super() coded up?
> 
> See namespace patch. It's there. As the matter of fact, was one of the
> first pieces. It works - the kernel I'm running right now is 2.4.4
> + several minor bugfixes + namespace-patch + ext2-dir-patch.

'k.  Thanks.

> > Also, have you chosen an appropriate place for clearing BH_New?
> 
> <shrug> When you mark the buffer uptodate and dirty. Why?

I am tentatively using buffer_new() to make decisions as to
whether ext3_get_block() has returned a new buffer - one which
thus cannot be in use by a previous transaction.  It needs
to be sane.

For this purpose it will be sufficient to just clear BH_New
in ext3_get_block():


 reread:
         partial = ext3_get_branch(inode, depth, offsets, chain, &err);
 
         /* Simplest case - block found, no allocation needed */
         if (!partial) {
+                bh_result->b_state &= ~(1UL << BH_New);
 got_it:
                 bh_result->b_dev = inode->i_dev;
                 bh_result->b_blocknr = le32_to_cpu(chain[depth-1].key);


But it seems that this flag has a rather vague lifecycle.  When
does a buffer stop being "new"?  As you say: when it's up-to-date.
Perhaps mark_buffer_uptodate() should clear BH_New.





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