> mountinfo - IMO needs a sane discussion of what and how should be shownHere's my take on the matter. The propagation tree can be either be represented 1) "from root to leaf" listing members of peer groups and their slaves explicitly, 2) or "from leaf to root" by identifying each peer group and then for each mount showing the id of its own group and the id of the group's master. 2) can have two variants: 2a) id of peer group is constant in time 2b) id of peer group may change The current patch does 2b). Having a fixed id for each peer group would mean introducing a new object to anchor the peer group into, which would add complexity to the whole thing. All of these are implementable, just need to decide which one we want. Miklos - To unsubscribe from this list: send the line "unsubscribe linux-fsdevel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
| Greg KH | [RFC] sample kobject implementation |
| Greg Kroah-Hartman | [PATCH 001/196] Chinese: Add the known_regression URI to the HOWTO |
| Paul E. McKenney | [PATCH RFC 2/9] RCU: Fix barriers |
| Joe Perches | [PATCH 011/148] include/asm-x86/bug.h: checkpatch cleanups - formatting only |
git: | |
| Jarek Poplawski | [PATCH] pkt_sched: Destroy gen estimators under rtnl_lock(). |
| Gerrit Renker | [PATCH 15/37] dccp: Set per-connection CCIDs via socket options |
| Linus Torvalds | Re: [GIT]: Networking |
| Jeff Garzik | Re: [PATCH] drivers/net: remove network drivers' last few uses of IRQF_SAMPLE_RANDOM |
