> Op 29 september 2016 om 18:31 schreef Emmanuel Florac <eflorac@xxxxxxxxxxxxxx>: > > > Le Thu, 29 Sep 2016 17:40:56 +0200 > "Jens-U. Mozdzen" <jmozdzen@xxxxxx> écrivait: > > > Another counter-example: You wouldn't put LVM on a disk that's > > intended as a (100%) MD-RAID volume, and add an LV as RAID member... > > you'll add a partition table for a reason, but no extra layer > > between the partition and the RAID stuff. > > > > I agree, but usually you wouldn't partition an MD-RAID either, would > you? OSDs are still holding (so far) ordinary filesystems locally > mounted on the nodes (except for BlueStore AFAIK). > I have partitioned MD-RAID before, works just fine. FileStore currently has a local XFS filesystem indeed, with BlueStore the OSD will consume a RAW device. > Anyway bcache would mostly make sense for the journal, much less for > the data section, so wouldn't it better to use bcache (or flash) for > journal/metadata only? > The Journal will be gone with BlueStore and that will become the RocksDB WAL. Using bcache for the data partition (the large one) will still benefit since frequently accessed blocks can be cached and thus lower the read latency. The question still remains, can bcache be patched that it allocates the right minor in the kernel so that it allows for partitions. I'm not a kernel nor bcache developer, just looking for somebody who would be willing to do this. Happy to assist, support and test! Wido > -- > ------------------------------------------------------------------------ > Emmanuel Florac | Direction technique > | Intellique > | <eflorac@xxxxxxxxxxxxxx> > | +33 1 78 94 84 02 > ------------------------------------------------------------------------ -- To unsubscribe from this list: send the line "unsubscribe linux-bcache" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
