Отримав новий SSD, не хочу його зношувати, але я все одно хочу використовувати його для зберігання файлів даних разом зі старим жорстким диском

Я купив новий ноутбук Samsung 850 EVO SSD для 250 Гб, який я хочу використовувати як основний пристрій зберігання, разом зі старим, але все ще функціонуючим 250 ГБ жорстким диском з об'ємом 7500 об / хв, який я поставив у колишній відсік DVD з адаптером Caddy.

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

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

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

Простір, зайнятий розділом кеша, віднімається від кількості наявного простору.
Кеш прискорює доступ до найчастіше доступних файлів незалежно від того, чи вони також є найменш часто модифікованими, що суперечить цілі не хочуть зношувати SSD.

Чи правильно сказане вище, чи міг кеш (який із цих двох?) Допомогти мені досягти своєї мети? Якщо вищесказане правильно, чи знаєте ви яке-небудь інше життєздатне рішення?

Чи допомогла б тут файлова система об'єднання , як OverlayFS ? Якщо ви відстежували жорсткий диск на предмет найбільш доступних файлів ( atimeщодня відстежуючи їх ) та виявляючи найменш модифіковані серед них (слідкуючи за їх mtime), теоретично ви могли переміщувати ці файли на SSD, звільняючи простір на Жорсткий диск, тоді як файлова система об'єднання може зробити все це прозорим для користувача.

Це працювало б?

— Фабіо А.
джерело

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

— Адам Річковський

... І так, розмір розділу bcache буде "з'їдений" подалі від загального доступного сховища. Це за задумом, тому що bcache є агностиком файлової системи. Цей дизайн дає вам бонус за збереження лише найбільш часто змінюваної частини файлу , яка повинна бути вигідною, наприклад, з даними бази даних.

— Адам Річковський

Також перегляньте проект, який може бути легко модифікований відповідно до ваших потреб (або навіть може підтримати його з коробки): romanrm.net/mhddfs

— Адам Ріцковський

@Fabio: ні коментарів, ні прийняття, але ви були онлайн. Будь-які проблеми з наведеною нижче відповіддю?

— Fabby

@Fabby, щойно я отримав час переглянути відповіді та коментарі, хоча я був у мережі, я не міг витрачати час на це. Я зараз до цього дістанусь.

— Фабіо А.

У вас є кілька варіантів залежно від того, що ви намагаєтеся виконати:

Використання bcache: Ви зможете з'їсти ваш торт, але не зберігати його.

Так, кількість місця, яке ви резервуєте для кешування, буде таким же, як і протилежний файлу swap: сума, яку ви вкажете, буде "забрана" із загального обсягу дискового простору та надана підсистемі пам'яті, яка буде використана як буфери для інший жорсткий диск.
Щоб контролювати, які файли кешуються, використовуйте щось на кшталт vmtouchточної настройки bcacheкешування.
Використовуйте LVM: Ви зможете тримати торт, але не їсти його.

Ви можете використовувати Logical Volume Manager для створення тома, що містить і SSD, і HDD, створивши великий /homeоб'єм, який містить простір з обох, але:
1. Ви не будете контролювати, який файл надходить на SSD, а який на жорсткому диску
2. Якщо ви втратите один з двох накопичувачів, ви втратите всі дані, і їх потрібно буде відновити з резервного копіювання !!!
Користуйтеся ручною системою: Ви зможете зберегти свій торт та з'їсти його.

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

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

— Фабі
джерело

Оскільки ви ніколи раніше не приймали відповідь на цьому веб-сайті: Якщо ця відповідь допомогла вам, не забудьте натиснути сіру ☑ зліва від цього тексту, що означає , що ця відповідь є дійсною ! ;-)

— Fabby

Додаткові поради, надані в додатковій записці! ;-)

— Fabby

Дякую за відповідь і вказівник на vmtouch, але - не бути грубим - крім цього, я не бачу додаткової інформації щодо того, що я заявив про себе в питанні, чи є це? Ідея використання об'єднання FS полягала в тому, що він би тоді був прозорий для користувача щодо того, куди були розміщені файли - на SSD чи на жорсткому диску - виходячи з того, що процес переміщення файлів з одного носія на інше було б абсолютно автоматичним. Думаючи про це, він також може бути реалізований за допомогою символьних посилань, що може виявитись простішим у виконанні.

— Фабіо А.

Загалом, здається, що немає правильного рішення мого питання, але я прийму вашу відповідь як дійсну, оскільки ви допомогли зрозуміти, що поки немає належного рішення. Дякую.

— Фабіо А.

@FabioA. Ну, це залежить від вашого визначення "належного". Поміщення символів робить фокус "прозоро" для кінцевого користувача (як тільки адміністратор встановив його) ... mhddfsмає ті ж недоліки, що і у мого lvmрішення. Grazie mille за прийняття, хоча і прихильність повернулася: Q схвалено! ;-)

— Fabby