Saket, Thanks for explanation. Saket Sinha: > What I am referring here is the topic <storing metadata in multiple > places vs "block device level union">. See DM operates on block > device/sector, but a stackable =EF=AC=81lesystem operates on =EF=AC=81lesys= > tem/=EF=AC=81le. My > point is this that which is the better approach according to the > kernel maintainers, so that this concept of Unioning gets universally > accepted and we have a mainline kernel union filesystem. While I don't know who prefers which approach, generally speaking, if you get what you want by an existing technology, it must be better to use it. Your ".me." approach will surely reduce the consumed blocks in the upper layer, but it of course contains a new overhead to maintain the information stored in ".me.". Additionally, as a result of ".me." approach, the upper layer will have info as not an ordinary file. I mean, fileA exists on the lower layer, but its metadata exists on the upper layer. So if a user (regardless within union or out of union) wants a complete fileA, then he has to get info from two places and merge them. Such situation looks similar to "block device level union". Currently it is unclear which evolution way hepunion will take, but if you want - filesystem-type union (instead of mount-type union nor block device level union) - and name-based union (insated of inode-based union) then the approach is similar to overlayfs's. So it might be better to make overlayfs as the base of your development. If supporting NFS branch (or exporting hepunion) is important for you, then the inode-based solution will be necessary. J. R. Okajima -- To unsubscribe from this list: send the line "unsubscribe linux-fsdevel" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
