Re: Bcache upstreaming

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

 



Hello,

On Fri, Feb 01, 2013 at 03:32:30PM -0500, Mike Snitzer wrote:
> The need for the same holder refcount is like I thought: a DM device's
> active and inactive tables can open the same block devices.  I looked at
> the prospect of pushing the refcount into DM but I don't think it is as
> clean as having the bd_holder_disk struct continue to provide the

It's a layering thing.  It's dm which is sharing exclusive open.  It
should be dm's responsibility to keep track of who's using what.

> refcount.  Pushing it into DM would still require an explicit call to
> bd_unlink_disk_holder.

While I don't know the code, I can't see why it has to be that way.
If a dm device is holding a device, it'll maintain the link between
old and new tables.  If it's being transferred to another device or
whatnot, it really should release the exclusive open and then
reacquire for the new use.

> The refcount is really pretty benign; so I'm inclined to leave things as
> is.

Yeah, the code isn't horribly complex but it's conceptually pretty
ugly.  If dm can back out of it, it would be awesome.  If that's not
something readily obtainable, ah well, another cruft we have to keep
around, I guess.

Thanks.

-- 
tejun
--
To unsubscribe from this list: send the line "unsubscribe linux-bcache" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html


[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[Index of Archives]     [Linux ARM Kernel]     [Linux Filesystem Development]     [Linux ARM]     [Linux Omap]     [Fedora ARM]     [IETF Annouce]     [Security]     [Bugtraq]     [Linux OMAP]     [Linux MIPS]     [ECOS]     [Asterisk Internet PBX]     [Linux API]

  Powered by Linux