[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