Hi,
Can a dbuf be in DB_CACHED state, db_holds == 0,
b_efunc != NULL while its db_buf is put on the
eviction list ? From an ASSERT in dbuf_do_evict(),
it appears that it can. If it can, I am wondering what
is preventing the following race
dbuf_hold_impl()
db = dbuf_find(dn, level, blkid);
On Sep 17, 2007 15:26 -0700, Jeff Bonwick wrote:
> I suggest that we get together soon for a "dnode summit", if you will,
> in which we put our various plans on the whiteboard and attempt to do
> the global optimization. I suspect that Lustre and pNFS, for example,
> have very similar needs -- it
Bhaskar,
In the code below, dbuf_find() will return with db_mtx locked which will
prevent dbuf_do_evict() from proceedin as it will block waiting on this
mutex:
dbuf_do_evict(void *private)
{
if (!MUTEX_HELD(&db->db_mtx))
mutex_enter(&db->db_mtx);
Thanks,
George
Bhas
Thanks George. The code in dbuf_do_evict() will not
attempt to get the mutex again as it is held already.
This mutex_enter() is simply to avoid acquiring it twice
and not a synchonization lock.
Bhaskar
>
> In the code below, dbuf_find() will return with db_mtx locked which will
> prevent dbuf_d
Bhaskar,
In your scenario the mutex would be held by the other thread in
dbuf_hold_impl(). So the caller of the dbuf_do_evict() would not own the
mutex and would have to acquire it. It's quite possible that the
eviction thread could have acquired the mutex earlier in the call path.
Regardless,
There are all kinds of problems with this. It's not OK to grow the
amount of space used -- that'll break quotas, reservations, etc.
We should really get together for a comprehensive design review.
When's the next time you're going to be in town?
Jeff
On Fri, Sep 14, 2007 at 06:01:05PM +0100, Da
