Есть новый SSD, я не хочу его изнашивать, но я все еще хочу использовать его для хранения файлов данных вместе со старым HDD

Я купил новый твердотельный накопитель Samsung 850 EVO емкостью 250 ГБ для своего ноутбука, который я хочу использовать в качестве основного устройства хранения данных, вместе со старым, но все еще работающим жестким диском на 250 ГБ 7500 об / мин, который я положил в прежний отсек для DVD с адаптером.

На данный момент на жестком диске есть только один большой раздел ext4, содержащий ОС, приложения и файлы данных. Я хочу использовать жесткий диск для хранения данных, но я не хочу упустить возможность получить повышение скорости SSD при этом.

Я хочу объединить, скажем, 50 ГБ или даже меньший раздел на SSD и объединить его с разделом на жестком диске, чтобы наименее модифицированные из наиболее часто используемых файлов автоматически перемещались на SSD.

Я смотрел на кэши, такие как EnancheIO и Bcache , но они не выглядят так, как я хочу, потому что (поправьте меня, если я ошибаюсь):

Пространство, занимаемое разделом кэша, вычитается из количества доступного пространства.
Кэш-память ускоряет доступ к наиболее часто используемым файлам независимо от того, являются ли они также реже измененными, что противоречит цели отказа от изнашивания SSD.

Верно ли вышеизложенное, или может ли кеш (какой из этих двух?) Помочь мне достичь моей цели? Если вышеприведенное верно, знаете ли вы какое-либо другое жизнеспособное решение?

Будет ли здесь полезна объединенная файловая система , такая как OverlayFS ? Если вы контролировали жесткий диск на предмет наличия наиболее часто используемых файлов (отслеживая их atimeежедневно) и определяли наименее измененные среди них (отслеживая их mtime), теоретически вы могли бы переместить эти файлы на SSD, освободив место на диске. HDD, в то время как объединенная файловая система может сделать все это прозрачным для пользователя.

Будет ли это работать?

— Фабио А.
источник

Теоретически ваши требования выполнимы. Наиболее выполнимым решением является отправка запроса на функцию отслеживания ошибок bcache с просьбой о другой стратегии хранения файлов в bcache.

— Адам Рычковски

... И да, размер раздела bcache будет "съеден" из общего доступного хранилища. Это сделано специально, потому что bcache не зависит от файловой системы. Этот дизайн дает вам преимущество хранения только наиболее часто изменяемой части файла , что должно быть выгодно, например, для данных базы данных.

— Адам Рычковски

Также ознакомьтесь с проектом, который может быть легко изменен в соответствии с вашими потребностями (или может даже поддержать его «из коробки»): romanrm.net/mhddfs

— Адам

@Fabio: без комментариев, без принятия, но вы были онлайн. Есть проблемы с ответом ниже?

— Fabby

@Fabby, сейчас у меня есть время, чтобы просмотреть ответы и комментарии, хотя я был в сети и не мог тратить время на это. Я доберусь до этого сейчас.

— Фабио А.

У вас есть несколько вариантов в зависимости от того, что вы пытаетесь достичь:

Использование bcache: Вы сможете съесть свой торт, но не сохранить его.

Да, объем пространства, которое вы резервируете для кэширования, будет аналогичен размеру файла подкачки: указанный вами объем будет «забран» из общего объема дискового пространства и передан подсистеме памяти, которая будет использоваться в качестве буферов для другой жесткий диск.
Чтобы контролировать, какие файлы кэшируются, используйте что-то вроде vmtouchтонкой настройки bcacheкэширования.
Используйте LVM: вы получите свой торт, но не съедите его.

Диспетчер логических томов можно использовать для создания тома, содержащего как SSD, так и HDD, создавая большой /homeтом, содержащий пространство из обоих, но:
1. Вы не сможете контролировать, какой файл идет на SSD, а какой на HDD
2. Если вы потеряете один из двух дисков, вы потеряете все данные и потребуется восстановить из резервной копии !!!
Используйте ручную систему: вы сможете сохранить свой торт и съесть его.

Разбейте диск на отдельные файловые системы: установите /на SSD и /homeна HDD. Кроме того, вы должны поместить все файлы, в которые вы хотите быстро перейти, /media/FastDataи сопоставить оригиналы с теми, которые находятся в /media/FastData том и только в том случае, если эти файлы находятся в вашем/home (в противном случае они уже находятся на SSD в любом случае)

^{Примечание 1: У меня есть маленький SSD и большой жесткий диск, поэтому я использую еще одну систему: /на SSD и /homeна жестком диске, и не пытаюсь оптимизировать дальше ...}
_{Примечание 2: Файловая система объединения не поможет вам. больше, чем ручная система ...}
_{Примечание 3: Вот еще несколько советов, как не изнашивать твердотельный накопитель, начиная с пункта 4 и выше.}

— Fabby
источник

Поскольку вы никогда не принимали ответ на этом сайте ранее: Если этот ответ помог вам, не забудьте нажать на серый ☑ в левой части этого текста, что означает Да, этот ответ действителен ! ;-)

— Fabby

Дополнительные советы приведены в дополнительном примечании! ;-)

— Fabby

Спасибо за ответ и указатель на vmtouch, но - чтобы не быть грубым - кроме этого, я не вижу никакой дополнительной информации о том, что я сам сформулировал в самом вопросе, не так ли? Идея использования Union FS заключалась в том, что тогда для пользователя было бы прозрачно определить, куда файлы были помещены - на SSD или на жесткий диск - на основе того, что процесс перемещения файлов с одного носителя на другой будет полностью автоматическим. Думая об этом, он также может быть реализован с помощью символических ссылок, которые могут оказаться проще в реализации.

— Фабио А.

В общем, похоже, что нет правильного решения моего вопроса, но я приму ваш ответ как действительный, поскольку вы помогли понять, что пока нет правильного решения. Спасибо.

— Фабио А.

@FabioA. Ну, это зависит от вашего определения "правильного". Symlinking делает трюк «прозрачно» для конечного пользователя (после того, как администратор установил его) ... mhddfsимеет те же недостатки моего lvmрешения. Грейзи Милл за признание, и благосклонность вернулась: Q проголосовал! ;-)

— Fabby