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

[dm-devel] Re: [PATCH 1/3] sysfs representation of stacked devices (dm/md common)

Thanks Alasdair and Neil,

Alasdair G Kergon wrote:
Test with trees of devices too - where a whole tree is suspended -

Suspending maps in the tree and reload one of them?
I'll try that.

I don't think you can allocate anywhere in dm_swap_table()
without PF_MEMALLOC (which I recently removed and am reluctant
to reinstate).

I understand your reluctance and I don't want to revive it either.
I think moving sysfs_add_link() outside of dm_swap_table() solves
this. Am I right?
Or do you want to eliminate the possibility that sysfs_remove_symlink()
may require memory allocation in future?

Anyway, I'll seek for bd_claim based approach.

Have you considered if anything is feasible based around bd_claim()?
Doesn't it make more sense for the links to be set up at table
load time - i.e. superset of both tables if present?

I think it makes sense. But I have difficulty with it.

What I once thought was extending bd_claim() like:
  bd_claim_with_owner(bdev, void *holder, struct kobject *owner)
where "owner" is a kobject for "slaves" directory.
We may have the object embedded in gendisk structure.
Then we can create symlinks like:
  /sys/block/<bdev>/holders/<owner> --> /sys/block/<owner>
  /sys/block/<owner>/slaves/<bdev> --> /sys/block/<bdev>

This should work for md.

However, dm needs more for its flexibility.
Because multiple dm devices can hold one device and one dm device
can hold a device twice (i.e. current table and new table),
we need to reference-count per relationship basis, not per slave
This might be solved by allocating management struct in bd_claim()
to reference-counting the relationship.
I'll try this. Comments are welcome.

Jun'ichi Nomura, NEC Solutions (America), Inc.

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