On Sat, Nov 25, 2017 at 09:12:35AM +0800, Qu Wenruo wrote: > On 2017年11月25日 03:16, Hans van Kranenburg wrote: > > Last week, when implementing the automatic classifier to dynamically > > create tree item data objects by key type in python-btrfs, I ran into > > the following commits in btrfs-progs: > > > > commit 8609c8bad68528f668d9ce564b868aa4828107a0 > > btrfs-progs: print-tree: factor out temporary_item dump > > and > > commit a4b65f00d53deb1b495728dd58253af44fcf70df > > btrfs-progs: print-tree: factor out persistent_item dump > > > > ...which are related to kernel... > > > > commit 50c2d5abe64c1726b48d292a2ab04f60e8238933 > > btrfs: introduce key type for persistent permanent items > > and > > commit 0bbbccb17fea86818e1a058faf5903aefd20b31a > > btrfs: introduce key type for persistent temporary items > > > > Afaics the goal is to overload types because there can be only 256 in > > total. > > Personally speaking, to overload types, we can easily make different > meanings of type based on tree owner.
Key type tied to a tree would cause some ambiguity, while now we always know what's in the type item if we eg. read a random metadata block. We're now at ~40 key types, scattered in the 256 range so further extensions are possible should we need a particular number due to the ordering. -- To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
