[dm-devel] [PATCHES] convert dm-thin to use dm-bufio

Mikulas Patocka mpatocka at redhat.com
Mon Aug 22 18:24:53 UTC 2011


> Mikulas,
> 
> On Fri, Aug 19, 2011 at 10:12:24AM +0100, Joe Thornber wrote:
> > On Thu, Aug 18, 2011 at 06:31:13PM -0400, Mikulas Patocka wrote:
> > > I uploaded bufio-based block manager at 
> > > http://people.redhat.com/mpatocka/patches/kernel/dm-thinp-bufio/. It 
> > > supports locks, but it defines new functions down_write_non_owner and 
> > > up_write_non_owner.
> > 
> > Thanks Mikulas, I'll try and get it merged over the next couple of days.
> 
> I've merged and pushed this to my git repo.

I checkouted the tree now (I tried all branches reported with git-branch 
-a), but I couldn't see bufio in any of the branches.

> All the test-suite is passing.  Performance is identical (though
> hopefully we're a lot more scaleable now).
> 
> I have to say I think the separation of io and locking is very elegant
> now.  Well done.
> 
> I've made two small changes:
> 
> i) I switched to using dm_bufio_new() rather than dm_bufio_read() at
> the start of *write_lock_zero().  No point reading the data if we're
> going to throw it away.

OK, I forgot about this.

> ii) We no longer hold the superblock lock for the duration of the
> transaction.  This means we can get rid of the nasty rwsem non-owner
> patch.
> 
> We have one outstanding issue however.  Now we're using a rwsem per
> block, lockdep is trying to validate there are no deadlocks.  Which it
> can't do, so is producing a warning. See the
>    
>  "Exception: Nested data dependencies leading to nested locking"
> 
> section in lockdep-design.txt for more discussion of the problem.
> 
> We need to suppress this somehow.  I guess the right thing to do is
> use the nesting level facility, eg call the superblock level 0, btree
> roots level 1 etc.  This will involve a lot of code changes however.
> So for now I just want to turn off checking on those locks.

I think you can't turn off lockdep just so. Those "non-owner" lock 
versions, bypass lockdep.

Mikulas

> - Joe
> 




More information about the dm-devel mailing list