> 1. Keep most of the data on just one drive (for movies from my own DVDs).
> 2. Keep the rest in RAID-5 form (for movies in games and such: PITA to
> reinstall but can be done if needed).
> 3. Keep my own personal files (1% of total size or so) duplicated 4 times > (on 4 HDDs).
> Pretty easy and simple requirements, right? Yet totally unachievable with
> usual LVM/filesystem separation. Currently btrfs can not support this mode > of operation too, but potentially - it's doable...
What's wrong with using partitions and bind mounts?
3) A partition that's mirrored on all disks
2) A RAID 5 (yuck!) using partition on 3 disks
1) A partition for your data disk
You can bind mount stuff to be at convenient points in the filesystem hierarchy. That is "specifiying different methods of replication for different parts of the namespace".
( Frankly if you have 4 disks, then I'd rather stripe, lower level mirrors with RAID 10 and accept the lower capacity for the performance and reliability benefits of avoiding RAID5 in a 3 disk configuration. )
Using a RAID layer to do RAID
An LVM layer to provide logical volumes (caveat on FS barriers)
File System layer to hand filesystem structure, and journalling
Would appear like a logical structure, though it does require initial planning.
Perhaps you want to be able to expand the alloted space, given over to RAID1, RAID5, RAID10 etc?
Couldn't that be done, by using LVM type block devices, used by the RAID layer which is then exposed to filesystems, so they can grow/shrink their capacity, as chunks of disk are (de)allocated to partitions?
Call me a cynic if you like but pushing every feature you could want into 1 layer, the filesystem, which should then become a generic dynamic disk management system, would appear to become a very complicated monolithic block of code. If sane implementations would then use generic layers, then you're really back to where you started.