История изменений

Посмотрел bcache. Насколько я понял, надо создать бэкдевайс и кэш девайс. Оба они должны быть блочными устройствами и не рекомендуется их создавать поверх других блочных устройств (например loop таким образом не катит). При этом создать кэш в файле нельзя.

Отсюда для решаемой задачки выходит не использовать. Если ramdisk отдать целиком под bcache еще можно, то вот делать отдельный партишен (это как минимум) под бэкдевайс мне не хочется так как изменить размер файла, выделенного как «кусок tmp на hdd» я могу легко, а вот с партишеном возиться уже сложнее.

Так что пока single data single metadata в btrfs подходят лучше всего в рамках данного решения.

Но вот подумать о том, что бы поставить линь на bcache=ssdX+hddX думаю стоит. От этого ssd вполне вероятно проживет дольше просто потому, что стратегия при которой данные пишутся на hdd, а читаются с sdd, постепенно перетекая туда если читаются часто и только...это вполне себе мне нравится.

При этом: bcache + btrfs was not stable with bcache with old kernels but is apparently ok with 3.19+

Посмотрел bcache. Насколько я понял, надо создать бэкдевайс и кэш девайс. Оба они должны быть блочными устройствами и не рекомендуется их создавать поверх других блочных устройств (например loop таким образом не катит). При этом создать кэш в файле нельзя.

Отсюда для решаемой задачки выходит не использовать. Если ramdisk отдать целиком под bcache еще можно, то вот делать отдельный партишен (это как минимум) под бэкдевайс мне не хочется так как изменить размер файла, выделенного как «кусок tmp на hdd» я могу легко, а вот с партишеном возиться уже сложнее.

Так что пока single data single metadata в btrfs подходят лучше всего в рамках данного решения.

Но вот подумать о том, что бы поставить линь на bcache=ssdX+hddX думаю стоит. От этого ssd вполне вероятно проживет дольше просто потому, что стратегия при которой данные пишутся на hdd, а читаются с sdd, постепенно перетекая туда если читаются часто и только...это вполне себе мне нравится.