On 11/19/13, 12:12 AM, deadhorseconsulting wrote: > In theory (going by the man page and available documentation, not 100% > clear) does the following command indeed actually work as advertised > and specify how metadata should be placed and kept only on the > "devices" specified after the "-m" flag? > > Thus given the following example: > mkfs.btrfs -L foo -m raid10 <ssd> <ssd> <ssd> <ssd> -d raid10 <rust> > <rust> <rust> <rust> > > Would btrfs stripe/mirror and only keep metadata on the 4 specified SSD > devices? > Likewise then stripe/mirror and only keep data on the specified 4 spinning > rust? > > In trying and creating this type of setup it appears that data is also > being stored on the devices specified as "metadata devices". This is > observed through via a "btrfs filesystem show". after committing a > large amount of data to the filesystem The data devices have balanced > data as expected with plenty of free space but the SSD device are > reported as either nearly used or completely used.
Others have noted that's not how it works, but I wanted to add a comment. I had a feature request from a customer recently that was pretty much exactly this. I think it'd be pretty easy to implement by allocating all (except for overhead) of the devices to chunks immediately at mkfs time, bypassing the kernel's dynamic chunk allocation. Since you don't *want* to mix allocation profiles, the usual reason for doing it dynamically doesn't apply. Extending an existing file system created in a such a manner so that the added devices are set up with the right kinds of chunks would require other extensions, though. I have a few things on my plate right now, but I'll probably dig into this in the next month or so. -Jeff -- Jeff Mahoney SUSE Labs
signature.asc
Description: OpenPGP digital signature
