On 2018年02月16日 01:15, Ellis H. Wilson III wrote: > In discussing the performance of various metadata operations over the > past few days I've had this idea in the back of my head, and wanted to > see if anybody had already thought about it before (likely, I would guess). > > It appears based on this page: > https://btrfs.wiki.kernel.org/index.php/Btrfs_design > that data and metadata in BTRFS are fairly well isolated from one > another, particularly in the case of large files. This appears > reinforced by a recent comment from Qu ("...btrfs strictly > split metadata and data usage..."). > > Yet, while there are plenty of options to RAID0/1/10/etc across > generally homogeneous media types, there doesn't appear to be any > functionality (at least that I can find) to segment different BTRFS > internals to different types of devices. E.G., place metadata trees and > extent block groups on SSD, and data trees and extent block groups on > HDD(s).
Just want to point out that, metadata trees, block groups, *AND* tree blocks of file trees (data trees in your words) are all *METADATA*. That's to say, btrfs can't isolate tree blocks from file trees and other trees. They are all tree blocks, thus all metadata. Real data is, non-inlined, non-hole data. Tree blocks of file tress has pointers to data, but the tree blocks of file trees are still metadata. So even on day, btrfs supports to alloc data/meta chunks using different strategy, we are still a step away from your different-chunk-for-different-tree idea. Thanks, Qu > > Is this something that has already been considered (and if so, > implemented, which would make me extremely happy)? Is it feasible it is > hasn't been approached yet? I admit my internal knowledge of BTRFS is > fleeting, though I'm trying to work on that daily at this time, so > forgive me if this is unapproachable for obvious architectural reasons. > > Best, > > ellis > -- > 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
signature.asc
Description: OpenPGP digital signature
