Как организовывать файлы на компьютере?

Т.е. построить аналогию для mv ~/Documents/* /run/media/`whoami`/exthdd1 ты не можешь? Тебе надо явно писать «хардлинк работает только в пределах одного раздела»?

У меня тоже остаётся. Но занимаемые 150М памяти это целая вкладка в браузере а фоновая нагрузка на цпу увеличивает лаг интерфейсов на 0,1 сек и просаживает ФПС в open X-COM с 19-20 до 16-18.

ок, мы в третий раз интенсивно нагружаем сервер

Да кого это волнует, если у него среднесуточная нагрузка меньше 0,25, а энергопотребление колеблется между 10 и 15 ваттами?

ок, мы делаем бекап реже, чем в месяц

Так часто как я считаю это нужным. В основном ради сохранок, лежащих в винде. Ну, потерял я 2-3 дня прогресса когда у меня диск накрылся и что?

чувствуешь разницу?

Нет, я всё ещё не чувствую разницу потому что описания вашей системы бэкапа в студии нету.

Я как бы в курсе что в пределах одного. В случае переноса одной копии на другой раздел она внезапно скопируется, а на исходном разделе станет на одну копию меньше. Можно подумать, при использовании индексирующей БД не пришлось бы хранить 2 копии на двух разделах...

у него среднесуточная нагрузка меньше 0,25, а энергопотребление колеблется между 10 и 15 ваттами?

ну так, конечно, если раз в месяц бекапы делать. с 2 тб она просто не справится. надеюсь, хоть ТС сделает какие-то полезные для себя выводы из этого разговора.

потому что описания вашей системы бэкапа в студии нету.

да ты вроде не спрашивал

а чем бекапите, borg backup ?

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

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

а на исходном разделе станет на одну копию меньше

Кхм… что? Т.е. 10 хардлинков = десять копий файла?

при использовании индексирующей БД

Адекватный человек индексирующую БД только для ускорения поиска использовать будет, а не как основное место хранения аттрибутов.

И да, в линуксах давно есть файловые системы, которые умеют в теги. xattr легко эти нужды закроет. Нет только софта, который бы давал интерфейс для взаимодействия с ними.

Отнюдь - там в about us почти все имена и фамилии немецкие, что кагбэ намекает ¯\_(ツ)_/¯

То есть по сути можно с помощью lvm mirroring и nbd замутить аналогичную схему замутить

В общем, надоел мне беспорядок.

Тебе для решения этой проблемы файловую систему дали.

вот именно, что замутить, а не сделать. мутить можно все, что угодно. вон kirill_rrr тоже намутил... спец. тулзы более чувствительны к качеству сети. а бекап лучше делать по приципу KISS. чем проще можешь сделать - тем лучше.

Хотелось бы посмотреть на реализацию

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

И да, в линуксах давно есть файловые системы, которые умеют в теги. xattr легко эти нужды закроет. Нет только софта, который бы давал интерфейс для взаимодействия с ними.

Нет софта - нет фичи. Мало ли чего там есть в ядре. Без софта, это разве хоть кто-то тестировал?

Для старых юниксов существовал строгий стандарт где что должно лежать

Разговор вообще разве не о юзерских данных, которые свалены в какие-то ~/Документики по дефолту? Вот уж где адок

Софт есть, но он cli. Хочется в гуйне.

... архивы перепаковываются со скоростями порядка 1,5-2 Мб/сек

... дедупликация может прыгать до 15 Мб/сек.

 26 Mar 2019 19:45:58 Same blocks: 491, diff:  42, 533/1824, average speed: 100.3 MB/s

выше - это мегабайты, а не мегабиты, если что.

Я всего лишь 2 раза не спрашивал.

Что это было?

да, вот именно так. если хозяин компа не наводит порядок сам, он там никак не самоорганизуется.

забей.