Можно ли заставить ЯД (Яндекс Диск) - синхронизировать атрибуты/владельца файлов?

Я же просил без форс-мажоров.

А это не такой уж и форс-мажор. Обращаю внимание, я написал от порчи информации.

Ненавижу слово «могут».

Это ваша личная половая проблема, вы можете любить, можете ненавидеть, но от этого «могут» не трансформируется в другое слово.

Вот любой из нас завтра может сдохнуть! И что теперь? Не жить?

Как минимум не прилагать усилия к приближению этого «сдохнуть». А вообще желательно прилагать усилия к тому, что бы не сдохнуть.

Это не логика, а рукожопство! Если в ФС этот файл есть, а в шифрованную не пролазит - значит автор шифрованной - РУОЖОП!

Ну вот у меня не шифрованная фс, но аналогичная вашей ситуация, авторы не шифрованной fs тоже рукопопы?

Спасибо за подробное описание! Очень неслабо вам «повезло», сочувствую. В те времена сигейтам не свойственно была массовая смерть, конечно бывало что дохли, но весьма редко.

Ну вот у меня не шифрованная фс, но аналогичная вашей ситуация, авторы не шифрованной fs тоже рукопопы?

Это как посмотреть. Максимальная длина пути в Линукс - 4096 байт. Мактимальная длина имени файла: 255 байт.
Если не поддерживают - то как их назвать? Сейчас не 90 годы, когд за каждый байт бились.

Мактимальная длина имени файла: 255 байт.

Вот! Байт.

Спасибо за подробное описание! Очень неслабо вам «повезло», сочувствую. В те времена сигейтам не свойственно была массовая смерть, конечно бывало что дохли, но весьма редко.

Я тоже всегда верил в Сигейты, а вот 3Т Барракуды у них случились провальными... После этого они моё доверие потеряли.

Я тоже всегда верил в Сигейты, а вот 3Т Барракуды у них случились провальными...

КМК кто-то где-то путается в показаниях.

Я тоже всегда верил в Сигейты, а вот 3Т Барракуды у них случились провальными...

КМК кто-то где-то путается в показаниях.

В каком месте?
Сигейты всегда были надежными, работали без нареканий.
Поэтому в очередной домашний апгрейд был взят Seagate Barracuda 3T.
Работал, был взят второй под зеркало. Точных данных не приведу, я плохо осознаю как это растянуто во времени, возможно эти «ненадежные» барракуды проработали по несколько лет, прежде чем сдохнуть. Но именно «дохли», не плохие сектора появлялись, а диск не определялся при очередном включении. Но увы, прошел через тяжелый периоды «ЧМТ, несовместимой с жизнью» и развала дома и принудительного выселения из этого дома через суд (Гугль: Ударная 35), поэтому даже трупиков этих винтов не осталось... Имущество ведь «выселялось» судебными приставами, и в списке имущества, постоянно фигурировало: «коробка с мусором». Вот потом какого то «мусора» и не нашлось, включая древних, полуметрового и метрового объективов... Вот и эти сигейты через всё это прошли...
Сейчас прешел на Тошибы, посмотрим что будет с ними. По теме нашел публикацию: «Названы самые надежные и самые ломкие жесткие диски» - Там как раз хамят 3Т Барракуды:
https://www.cnews.ru/news/top/nazvany_samye_nadezhnye_i_samye_lomkie
Хотя конечно это может быть «рекламная» статья. Там присутствуют только Hitachi, Seagate и WD и Hitachi ощутимо выигрывает, а вот Барракуды прямо по тексту - ломались в 14 раз чаще.

Сигейты всегда были надежными, работали без нареканий.
Поэтому в очередной домашний апгрейд был взят Seagate Barracuda 3T.

Неправда. Именно Барракуды всегда считались самым днищем. Другое дело, что у них есть ещё Constellation и Ironwolf, о чём многие забывают и начинают кричать «сигейт ненадёжное говно», что не оправдано. Но не барракуды же надёжными считать.

Отмечаю топик как решенный, жаль никто не «ткнул» в решение, начали балабольство про облака и что они должны делать...

(250208) P.P.S. cryfs и ecryptfs - разочаровали. Решение оказалось нерешенным.
cryfs - Оттормаживается по 40-60 секунд на команде df на шифрованном разделе с залитыми 64Gb. Но и аремя и атрибуты сохраняет и они «пролазят» с хоста на хост через ЯД.
ecryptfs - Работает быстро, но время/дату/rwx, хранит в атрибутах зашифрованных файлов и естественно это не «пролазит» через ЯД.

У облаков api такой что файл не может быть частично прочитан/записан, только целиком, поэтому и не работают шифрованные фс так как хочется, можно попробовать реализовать кэширование путём даже использования свопа, но я не знаю как это сделать и сомневаюсь что это поможет, потому что софт которым монтируются файлы из облака скорее всего не умеют приоритеты, даже попытка чтения атрибутов будет приводить зависаниям скачивая весь файл целиком генерируя бесконечные очереди.

Частичное изменение объекта https://yandex.cloud/ru/docs/storage/concepts/object-patch

У облаков api такой что файл не может быть частично прочитан/записан, только целиком,

В моей ситуации на это накакать... Я монтирую и шифрую -локальное хранилище, которое уже реплицирует на сервер - yandex-disk. Мне плевать, что он там и как делает, но в варианте с пофайловой шифровкой - он максимум перезальёт один изменённый файл. Зависания cryfs идут уже при локальной работе, без всяких ЯДов... Я его даже не стартовал.

А cryfs это монстр, как бы запиленный для облачных хранилищ. его хранилище представляет из себя подкаталог с 4096 подкаталогами с именами 000-fff в которых хранятся файлы вида: AABBCCDD-EEFFGGHH по 16кб, т.е. при каком то изменении файла 10Гб, перезальётся файл 16кб.

КМК кто-то где-то путается в показаниях.

В каком месте?

Где-то здесь:

Я не так крут чтобы 4 барракуды разом в начале 2000 купить.

...

а вот 3Т Барракуды

И вот по этой теме:

По теме нашел публикацию: «Названы самые надежные и самые ломкие жесткие диски» - Там как раз хамят 3Т Барракуды:

3Tб вроде не только у сигейта неудачные выходили, в чем грабли были не помню, запомнилось что с ними проблемы были.

+1 за Constellation. А Ironwolf вроде уже не совсем полностью их. или я с чем-то путаю?

Где-то здесь:

Я не так крут чтобы 4 барракуды разом в начале 2000 купить.

Ключевое слово: «разом». Я их покупал с разницей во времени, возможно по году или даже два. (1)Мастер, (2)бэкап, (3)зеркало к мастеру, (4)замену сдохшему зеркальному. Сдох он не сразу, уже был бэкап и зеркало. Возможно в зеркале пару лет проработал, или простоял - периодически включаясь. У нас как раз были траблы с жильём. Я жил в одном городе, а мои компы в другом... Временами возил к ним данные и бэкапил. Раз приехал, включил комп, а зеркало дохлое.... Другой раз приехал с бэкапом - не смог зеркало забэкапить на бэкап, ибо бэкап сдох... Вот дальше могу путаться. Ад с судами и житьё где попало - разбомбили всю память, жил в диком стрессе. Исправно платил, но дом плохо обслуживался и развалился и нас как преступников - судили, чтобы вменить нам принудительное выселение из того места где мы были зарегистрированы. т.е. на сделали «БОМЖами в законе», по решению суда мы не могли жить в месте нашей регистрации.
P.S. Сейчас залез в записи. Бэкапный был не Барракуда а Seagate NAS 3T
И по записям был ещё USB3.0 3T Seagate Backup Plus Desktop, но я его совсем не помню.
И в принципе судя по всему они конечно не сразу сдохли, как там в обзоре заявлено что средний срок жизни этих винтов 3-5 лет.
2 Крайних я покупал в 2013, 2014 а сдохли в районе 2017,2018.
Но блин Самсунг 1Т у меня с аптаймом уже более 9 лет.

2 Крайних я покупал в 2013, 2014 а сдохли в районе 2017,2018.

Вот это уже больше на правду.

Но блин Самсунг 1Т у меня с аптаймом уже более 9 лет.

Опять вы называете только производителя и объем. Но конкретно про гнусмус ничего не могу сказать ни плохого ни хорошего, мне в голову не пришло бы брать их харды(HDD).

Опять вы называете только производителя и объем. Но конкретно про гнусмус ничего не могу сказать ни плохого ни хорошего, мне в голову не пришло бы брать их харды(HDD).

Ну...

=== START OF INFORMATION SECTION ===
Model Family:     SAMSUNG SpinPoint F3 EG
Device Model:     SAMSUNG HD105SI
Serial Number:    S25GJ9CZ801073
LU WWN Device Id: 5 0024e9 20345debd
Firmware Version: 1AJ10001
User Capacity:    1 000 204 886 016 bytes [1,00 TB]
Sector Size:      512 bytes logical/physical
Rotation Rate:    5400 rpm
Form Factor:      3.5 inches
Device is:        In smartctl database 7.3/5319
ATA Version is:   ATA8-ACS T13/1699-D revision 6
SATA Version is:  SATA 2.6, 3.0 Gb/s
Local Time is:    Sun Feb  9 12:27:25 2025 MSK
SMART support is: Available - device has SMART capability.
SMART support is: Enabled

=== START OF READ SMART DATA SECTION ===
SMART overall-health self-assessment test result: PASSED
[axed]
ID# ATTRIBUTE_NAME          FLAG     VALUE WORST THRESH TYPE      UPDATED  WHEN_FAILED RAW_VALUE
  1 Raw_Read_Error_Rate     0x002f   100   100   051    Pre-fail  Always       -       12
  2 Throughput_Performance  0x0026   252   252   000    Old_age   Always       -       0
  3 Spin_Up_Time            0x0023   075   040   025    Pre-fail  Always       -       7631
  4 Start_Stop_Count        0x0032   099   099   000    Old_age   Always       -       1049
  5 Reallocated_Sector_Ct   0x0033   252   252   010    Pre-fail  Always       -       0
  7 Seek_Error_Rate         0x002e   252   252   051    Old_age   Always       -       0
  8 Seek_Time_Performance   0x0024   252   252   015    Old_age   Offline      -       0
  9 Power_On_Hours          0x0032   100   100   000    Old_age   Always       -       81434
 10 Spin_Retry_Count        0x0032   252   252   051    Old_age   Always       -       0
 11 Calibration_Retry_Count 0x0032   252   252   000    Old_age   Always       -       0
 12 Power_Cycle_Count       0x0032   100   100   000    Old_age   Always       -       966
191 G-Sense_Error_Rate      0x0022   100   100   000    Old_age   Always       -       8
192 Power-Off_Retract_Count 0x0022   252   252   000    Old_age   Always       -       0
194 Temperature_Celsius     0x0002   061   047   000    Old_age   Always       -       39 (Min/Max 11/53)
195 Hardware_ECC_Recovered  0x003a   100   100   000    Old_age   Always       -       0
196 Reallocated_Event_Count 0x0032   252   252   000    Old_age   Always       -       0
197 Current_Pending_Sector  0x0032   252   100   000    Old_age   Always       -       0
198 Offline_Uncorrectable   0x0030   252   252   000    Old_age   Offline      -       0
199 UDMA_CRC_Error_Count    0x0036   100   100   000    Old_age   Always       -       3
200 Multi_Zone_Error_Rate   0x002a   100   100   000    Old_age   Always       -       2505
223 Load_Retry_Count        0x0032   252   252   000    Old_age   Always       -       0
225 Load_Cycle_Count        0x0032   100   100   000    Old_age   Always       -       1098

(250208) P.P.S. cryfs и ecryptfs - разочаровали. Решение оказалось нерешенным.

Почему бы не попробовать написать собственное решение для FUSE с/без шифрования. Я тут подумал и в голову пришло два варианта:

• простой при котором атрибуты хранятся в поддиректории например «.acl» с тем же названием что и оригинальный файл плюс зарезервированный файл для атрибутов директории. Плюс в том что можно читать и без FUSE модуля. Минус может быть рассинхронизация атрибутов и содержимого файла, также если файл атрибута еще не синхронизировался то не показывать оригинальный файл даже если он был синхронизирован.
• чуть посложнее, выделить в начале файла определенный размер достаточный для всех атрибутов, для директории надо будет файл зерезервированный. Плюс в том что синхронизироваться данные будут сразу с атрибутами, кроме директории и если не синхронизирован файл атрибутов директории то также не показывать(было бы хорошо если можно выставить приоритет файлов при синхронизации). Минус в том что без нужного FUSE модуля нормально не прочитаешь.

(250208) P.P.S. cryfs и ecryptfs - разочаровали. Решение оказалось нерешенным.

Есть еще gocryptfs развитие EncFS специально для облаков сделано и должен поддерживать атрибуты.

Почему бы не попробовать написать собственное решение для FUSE с/без шифрования. Я тут подумал и в голову пришло два варианта:

Замечательное предложение, но я не программер! Вариантов и мне может прийти сотня, например взять готовое: eadata.sf, наверняка где то есть описание формата и возможно он потянет POSIX, но не смогу реализовать эти идеи.

Я сюда обратился, чтобы узнать - вдруг есть уже готовое решение!
Пока нашел лишь cryfs и то тормознутое...

Впрочем прямо сейчас пошел к Дипсику и он мне выдал:

>Расскажи, есть ли под Linux подсистема - позволяющая хранить POSIX атрибуты файлов поверх неPOSIX системы? т.е. в отдельных структурах.

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

1. Расширенные атрибуты (xattrs)
Linux поддерживает расширенные атрибуты (extended attributes, xattrs), которые позволяют хранить дополнительные метаданные файлов, включая POSIX-атрибуты. Эти атрибуты можно сохранять в отдельные структуры данных.

Как это работает:

Расширенные атрибуты хранятся в виде пар "ключ-значение" и могут быть привязаны к файлам или каталогам.

Даже если файловая система не поддерживает POSIX-атрибуты, их можно сохранить в xattrs.

Пример использования:

bash
Copy
# Установка расширенного атрибута
setfattr -n user.permissions -v "rwxr-xr-x" file.txt

# Просмотр расширенных атрибутов
getfattr file.txt

# Сохранение POSIX-атрибутов в xattrs
chmod 755 file.txt
getfattr -n user.posix.permissions file.txt
Ограничения:

Не все файловые системы поддерживают xattrs (например, FAT32 не поддерживает).

Если файловая система поддерживает xattrs, их можно использовать для хранения POSIX-атрибутов.

2. Метаданные в отдельном файле
Если файловая система не поддерживает xattrs, можно хранить метаданные (включая POSIX-атрибуты) в отдельном файле.

Как это работает:

Для каждого файла создаётся отдельный файл с метаданными (например, .file_metadata.txt).

В этом файле хранятся права доступа, владелец, группа и другие атрибуты.

Пример:

Для файла file.txt создаётся файл .file.txt.metadata с содержимым:

Copy
permissions=rwxr-xr-x
owner=user
group=users
При восстановлении атрибуты применяются с помощью скриптов.

Ограничения:

Требуется ручное управление метаданными.

Неудобно для большого количества файлов.

3. Использование FUSE (Filesystem in Userspace)
FUSE позволяет создавать пользовательские файловые системы, которые могут эмулировать POSIX-атрибуты поверх не-POSIX хранилищ.

Как это работает:

Файловая система на основе FUSE может хранить метаданные (включая POSIX-атрибуты) в отдельной базе данных или файле.

Примеры таких файловых систем:

sshfs — монтирует удалённую файловую систему через SSH.

rclone mount — монтирует облачные хранилища (например, Яндекс.Диск, Google Drive).

encfs — шифрованная файловая система.

Пример с FUSE:

Создайте файловую систему, которая хранит метаданные в SQLite или JSON-файле.

При монтировании файловая система будет использовать эти метаданные для эмуляции POSIX-атрибутов.

4. Использование attr и acl
Если файловая система поддерживает расширенные атрибуты, можно использовать утилиты attr и acl для управления атрибутами.

Пример:

bash
Copy
# Установка расширенного атрибута
setfattr -n user.posix.permissions -v "rwxr-xr-x" file.txt

# Установка ACL
setfacl -m u:user:rwx file.txt
5. Использование overlayfs
overlayfs — это файловая система, которая объединяет несколько слоёв (например, read-only и read-write). Её можно использовать для хранения метаданных в отдельном слое.

Как это работает:

Основной слой — это не-POSIX файловая система.

Верхний слой — это каталог, где хранятся метаданные (атрибуты).

Пример:

bash
Copy
mount -t overlay overlay -o lowerdir=/non-posix,upperdir=/metadata,workdir=/work /mnt/merged
6. Использование git или borg
Если вам нужно сохранить атрибуты для резервного копирования, можно использовать инструменты вроде git или borg.

Пример с borg:

bash
Copy
borg create /path/to/repo::archive_name /path/to/file_or_directory
borg сохраняет атрибуты файлов в архиве.

Итог:
Если вам нужно хранить POSIX-атрибуты поверх не-POSIX системы, лучшие варианты:

Использовать расширенные атрибуты (xattrs), если файловая система их поддерживает.

Создать пользовательскую файловую систему на основе FUSE.

Хранить метаданные в отдельных файлах или базе данных.

Если у вас есть конкретный сценарий, дайте знать — я помогу с реализацией! 😊

Есть еще gocryptfs развитие EncFS специально для облаков сделано и должен поддерживать атрибуты.

Спасибо, посмотрю.
Его же (encfs) предложил Дипсих (Dipseek).

И в беседе предложил всех слать к нему:

Если вдруг кто-то в форуме захочет узнать, как "Дипсих" справляется с задачами, смело отправляйте их ко мне — я всегда готов помочь! 😊

Я сюда обратился, чтобы узнать - вдруг есть уже готовое решение!

Просто очень экзотические требования.

• для S3/Google Cloud/etc вроде есть решения которые используют API для хранения дополнительных данных для файлов. И не ограничены единственным решением вендора.
• для сетевых дисков или локальных достаточно использовать решения хранения всей FS в одном файле хоть в qcow2 или любых других которые популярны для виртуальных машин.

Я для себя решил что для хранения терабайтных данных в облаке лучше всего это взять дешевую VPS. Собрать 3 небольших NAS с 1-2 дисками по 8TB-16TB и разместить их в разных географических зонах у родственников, и чтоб они все работали через один VPS. Тут даже если в двух зонах пропадет электричество всё равно будет доступен один NAS.

Я сюда обратился, чтобы узнать - вдруг есть уже готовое решение!

Просто очень экзотические требования.

В чём экзотика? Я тупо под линуксом, и тупо захотел смонтировать /usr/local/bin с ЯДа.... Чтобы он на всех машинах был одинаков.
Ну да, «из пушки по воробьям», проще дешевую VPS с 10Gb диском взять и хватит...

для S3/Google Cloud/etc вроде есть решения которые используют API для хранения дополнительных данных для файлов. И не ограничены единственным решением вендора.

Да Дипсих там уже насоветовал...

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

По факту говорят что ЯД полностью копирует файл у которого изменился 1 байт... Собственно поэтому я взял шифрующие системы на файлах, а не на контейнере.

Я для себя решил что для хранения терабайтных данных в облаке лучше всего это взять дешевую VPS. Собрать 3 небольших NAS с 1-2 дисками по 8TB-16TB и разместить их в разных географических зонах у родственников, и чтоб они все работали через один VPS. Тут даже если в двух зонах пропадет электричество всё равно будет доступен один NAS.

И ты знаешь весь инструментарий позволящий это реализовать?
Я вот банально не представляю как синхронизировать 3 сервера... Зеркало через drbd, я ещё представляю, а вот ТРИ - нет!
Ну а автоматический выбор зеркала - это тоже нехилая задача.
И расскажи сколько в месяц, будет стоить VPS на которой официально разрешено поднимать VPN, насколько я понимаю - сейчас на большинстве VPS - это запрещено.

В чём экзотика?

В том что нет контроля за тем в каком порядке синхронизируются файлы. Так можно побить файла на куски по 16КБ-64КБ. Но не факт что они будут в нужном порядке синхронизироваться, а это значит что нужно следить чтоб все файлы были доступны прежде чем отобразить файл через прослойку. Плюс большинство не интересует права на файлы в облаке, поэтому и решений так мало.

И ты знаешь весь инструментарий позволящий это реализовать? Я вот банально не представляю как синхронизировать 3 сервера… Зеркало через drbd, я ещё представляю, а вот ТРИ - нет!

rsync и скрипты на bash-е например. Возможно есть готовые решения, я не копал так как пока нет возможности но планирую такое сделать. Так при удалении/создании/изменении файла/директории заносить путь к файлу/директории в список на синхронизацию. Для каждой записи хранить статус синхронизации с остальными NAS, после успешной синхронизации со всеми удалять запись. Конфликты разрешать вручную или по правилам. На самом VPS можно держать структуру файлов и директорий и статусы синхронизаций.

Ну а автоматический выбор зеркала - это тоже нехилая задача.

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

Для закачивания через VPS если файл не большой и есть место то сперва на него закачать а затем уже от туда на все зеркала раздать. Если файл слишком большой то по статистике скорости выбрать одно зеркало на которое первоначалоно будет записано, а затем уже синхронизировать. Либо если скорости позволяют то сразу параллельно на все зеркала писать. Также можно предусмотреть если скорости не позволяют то сколько пролезет столько и писать на все зеркала при чем разным зеркалам разные куски можно отдавать.

Также помимо связи через VPS можно напрямую держать связь между зеркалами чтоб не упираться в пропускную способность и уменьшить потребления трафика VPS который на дешевых тарифах хоть и большой но ограниченный. С наличием VPS шансы пробить NAT для зеркал очень большие. Плюс можно еще и подключаться через зеркала а не только VPS.

Плюс можно еще и подключаться через зеркала а не только VPS.

Почитал я твои «плюсовые» фантазии, и хочу узнать - ты хоть представляешь как это сделать? Или это просто фантазии?
В твоих фантазиях слишком часто используется слово «можно», но не уверен в возможности реализаций этих «можно». Ты в своих фантазиях - расписал систему с зачатками ИИ.
У многих твоих знакомых есть канал с белым ip и возможностью подключиться снаружи?
А мощность потребляемую таким «небольшим» NAS - измерял?
Сколько он будет у друга «откушивать» в месяц?

В общем фантазии красивые, но это фантазии и не более.
Как я предполагаю - они просто размажутся об реальность.
Слишком много «может» и других неизвестностей.

Слишком много «может» и других неизвестностей.

Сходу нагуглил готовое решение Synology Drive, позволяет синхронизировать несколько NAS. Просто пока нет необходимости - лень гуглить и вникать в тему.

У многих твоих знакомых есть канал с белым ip и возможностью подключиться снаружи?

Для этого и нужен VPS чтоб гарантия подключения была если нет ни одного белого IP. Плюс гарантия что если останется только одно зеркало без белого IP, то все равно можно будет подключиться.

Почитал я твои «плюсовые» фантазии

Вот я «фантазии» описал так как не вижу никаких препятствий и в гугле сразу же нашел готовое решение. Если придумал какое-то решение то скорее всего кто-то уже давно то-же самое придумал и реализовал, надо только хорошо поискать.

А мощность потребляемую таким «небольшим» NAS - измерял?

Обычный NAS потребляет 5Вт в спящем режиме и 15Вт при доступе к данным. При 24/7 в активном режиме это как энергосберегающая LED лампочка. За месяц максимум потребление в районе 11кВт.

https://chat.deepseek.com/

Эх, хотел ему ещё задать вопрос но:

The server is busy. Please try again later.

И расскажи сколько в месяц, будет стоить VPS на которой официально разрешено поднимать VPN,

см. Посоветуйте самую дешевую российскую VPS или отговорите.

насколько я понимаю - сейчас на большинстве VPS - это запрещено.

скорее наоборот, если используется полная виртуализация, а не контейнерная.

И про «Гнусмасы» я ни чего плохого сказать не могу, ни одного дохлого не видел

А они дохнут. Собсно дохнут любые, кто-то чаще, кто-то реже, не более того. У меня когда-то давно гнусмус был, но я тогда был ещё молодой и неопытный, да и в те времена и солнце ярче было и железо понадежнее клепали.