Комментарии 32
Ну, ещё один способ дифференциального бэкапа. Но там есть нюансы - в NTFS хардлинк работает только для файлов, и только в рамках одного логического раздела. Для папок и разных разделов уже придётся с точками соединения (NTFS junction point) извращаться.
А почему эти вольшебные хардлинки не использует микрософт и пресловутая winsxs занимает овердохрена гигабайт которые портят мой твердотельник. Если якобы винда не может посчитать реальный размер, тогда где утилита которая может?
Это три разных вопроса. По порядку.
1. Windows использует hard liks. В основном для обратной совместимости. Если мне не сильно изменяет память то на обычный блокнот имеется 7 шт. hard link.
2. Windows не корректно считает размер файла по отношению к GUI пользователя, занятое место на диске отображается абсолютно корректно.
3. Уверен что программы, которые учитывают hard links по идентификаторам (inode, если бы мы говорили про UNIX) существуют, просто не являются дефолтными.
А когда люди узнают про reflink на cow файловых системах (btrfs,zfs,xfs,..), вообще офигеют (сарказм).
Файлы, скопированные штатным cp с этой опцией, будут скопированы мгновенно, потому что вместо копирования на каждый кластер (там кажется группами идет, так что сотни гигабайт так же мгновенно) будет скопирована ссылка, но, если исходный или новый файл будет изменен, изменение отразится только на нем, а не на копии (с hardlink как раз 'оба файла' изменятся), т.е. с точки зрения использования это независимая копия файла, но место на диске тратится только на хранение изменений.
Более того, в btrfs (за остальные не скажу, в zfs по-моему так же, а в xfs-нет) если в первом файле изменить только один байт - на диске не создастся его измененная копия, а только допишется измененная копия того блока, в котором был измененный байт, и в измененном файле (а файл - это просто цепочка ссылок на блоки) поменяется только ссылка на измененный блок.
Вообще кода zfs получит распространение будет интересно) Тем не менее буквально в прошлом месяце я встречал флешку отформатированную в FAT32, и видел людей с дискетами 3,5 мб.
А в чем флешку форматировать надо? Я тут недавно хотел флешку форматнуть в линуксе и из универсальных фс он мне предложил фат32 и нтфс... Эксфат не было...и?
Мне кажется современное решение это NTFS. FAT32 не даст записать файл размером более 4 гб, и имеет ограничение на количество файлов в одном каталоге = 65534, на опыте я упирался в оба ограничения. У NTFS один файл может весить до 16ТБ и количество файлов в каталоге может быть более 4 млн. шт. Конечно какие-то экзотические устройства могут принимать только FAT32, но это скорее исключение. Ext (стандартный для Linux) я бы тоже не стал использовать, может потребоваться прочесть флешку на Windows.
exFAT - native file system in Linux 5.4
Надо было поставить exfatprogs
https://pkgs.org/download/exfatprogs
exfat вроде с достаточно давних пор должен быть свободно доступен в Linux.
существуют две основные стратегии: хранить файлы прямо в базе данных или записывать в базу данных только ссылки, а сам файл оставить в файловой системе сервера.
А уж что будет когда узнают что бывает вариант когда в базе хранится идентификатор а сам файл - в S3...
за такие туториалы надо лет на 10 отбирать возможность публиковать что либо
Очень аргументированное возмущение) А что так? Ни когда не приходилась восполнять пробелы в знаниях новых сотрудников, или есть предложение как сделать лучше? А нет, всё проще. Я почитал вашу историю комментариев и статей, вам просто нравятся дизлайки))
Это задумывалось как ответ мне наверное. Просто почему-то оказалось отдельным комментом. В общем, буду краток: русский — хотя бы на уровне правильного написания базиса (того же «никогда»), а потом уже в туториалы пыжиться. И всё это ещё относительно далеко от того, чтобы пытаться проводить какие-то параллели между "AND" и RAID-1, прасти-хоспади… — AND и copy это вообще разные вещи, просто вообще разные. Но как видно, когда в голове каша, то она сама-то этого не видит, вот уже и «туториалы» «для новых сотрудников» создаёт.
В общем так — 10 лет мало даже, 15 минимум. Оптимистичная оценка.
P. S. Надеюсь, что "CTO" в титуле это всё же «100» по-русски. Позволяет оставить хоть какую-то надежду за предполагаемый бизнес и его сотрудников.
Жалко вы не хотите писать полезные комментарии, видимо могли бы. Например предложить, как лучше и нагляднее донести эти простые темы? Или может имеете богатый опыт в развёртывании инфраструктуры, я бы почитал. Найти опечатки, это конечно мило, но может вы способны на что-то более продуктивное?
P.S. Да с RAID 1формулировка не точная, согласен.
Читал со все большим недоумением пытаясь понять, как хардлинки и хор будут прикручивать к веб-приложению. А тут хоп - и конец.
Это было в начале, откуда пошло рассуждение. Но если интересно, то вот так:
Когда файлы загружаются на сервер, то создаётся особая структура каталогов и файл именуется по шаблону. Таким образом в самом коде веб приложения сразу пишется паттерн, который указывает на на место в файловой системе. Для того чтобы приложению не нужно было администрировать файлы, то они при загрузке распределялись бы хардлинками по нужным каталогам.
Используя git вы сталкиваетесь именно в hard link и понимание этого есть основная цель.
XOR сам по себе не сильно интересен. Но при решении отдельных задач крайне спасает. Например, не помню где на просторах интернета встречал: СКУД много людей заходят, много выходят. Один не вышел, как найти? И одно из решений было пройти XOR-ом по всем записям. Не помню деталей, но и работало это только в случае, если не вышел 1 человек. Главное - это понимание механизма.
там, как говорится, прекрасно всё…
Буквально конец статьи би лайк:
Чуть-чуть теории (всего один абзац!)
Красивая картинка с HEX редактором какое отношение к теории имеет?
Запишем в bigfile.txt некоторую информацию, например, "Это просто статья на Хабре, читайте дальше". Откроем hardlink.txt и увидим ту же информацию, потому что hard link, по сути, является тем же файлом с точки зрения операционной системы.
Подскажите, чем правильно редактировать txt файлы, размером 10Gb? Почему выбран именно такой объем файла?
Поэтому пользуемся программным, аппаратным или собственным RAID, написанном на Python, для создания избыточности и повышения безопасности:
Даже если воспринимать этот код как концепт - от чего конкретно защищает этот ваш псевдо-raid? От повреждения файлов он не защищает. От удаления одного из файлов? Ну теоретически да, но это функционал резервного копирования а не raid.
HEX редактор напрямую никакого отношения не имеет. Но найти картинку способную точно передать идею я увы не смог. В добавок современные операционные системы хорошо скрывают реальные адреса, а DOS ради этого было ставить очень мутерно. Я использую эту картинку исключительно для визуализации отличия адреса от информации. Это не точное пособие, но в целом идею на нём показать можно.
Чем правильно редактировать например EmEditor или суровое консольное nano. Если хватит оперативной памяти, то оно должно открыть.
Это просто способ пощупать XOR. На этом можно построить защиту от повреждения, файлы будут друг друга контролировать. Но тогда хэш физического файла нужно сравнивать с хэшом XOR от двух других файлов, при не совпадении восстанавливать из XOR файла и даже можно будет определить конкретные битые места.
например EmEditor или суровое консольное nano. Если хватит оперативной памяти, то оно должно открыть.
EmEditor - обещает открыть за час с лишним, nano - виснет, notepad++ вылетает (быть может ему 12Gb свободной оперативки мало), mcedit - открывает на чтение, но выдает ошибку на запись. Очевидно что любой HEX редактор успешно прожует подобный объем (например HxD поскольку тот же WinHEX не сохраняет в бесплатной версии такие объемы), но вы так уверенно рассуждаете в статье про "откроем" и "запишем" что мне стало любопытно - чем конкретно вы открываете и записываете под Win в разумные сроки и с разумным расходом памяти. Видимо это было теоретическое "откроем".
при не совпадении восстанавливать из XOR файла
Допустим у нас есть 4 файла A="000", B="000", C="000", XOR="010"
Мы понимаем что один из них поврежден во 2м бите. Внимание вопрос - который из 4х файлов поврежден?
Но тогда хэш физического файла нужно сравнивать с хэшом XOR от двух других файлов, при не совпадении восстанавливать из XOR
При изменении одного из файлов - пересчитывать хэш этого файла и хэш XOR файла. Сильно. Опять же - это сработает только если не сходится только один хэш т.е. все повреждения попали на один файл. Лично мне крайне сложно придумать практическое применение вашей идее, для детектирования ошибок есть просто хэш, для исправления код Хэмминга, Рида-Соломона, raid 6.
По поводу «откроем и запишем», наверное было бы корректнее сказать «перепишем», но чтобы не отходить от темы опустил этот момент.
Практического применения код не имеет никакого) Глупо спорить, что уже имеющиеся решения, в том числе аппаратный RAID или mdamd покрывают весь спектр. Но иногда приходится решать узкие проблемы или разбираться в работе того или иного кода, и в этот момент просто полезно знать какой бывает инструментарий.
Подобно этому, файл number.txt на рабочем столе, на самом деле, — это только ссылка, указывающая на область в памяти диска допустим 0x7ffd3b56a4d0, где находятся данные «01001001».
Нет, не так. Вся обрасть памяти диска разбита на блоки одинакового размера, файл может занимать как один блок, так и несколько блоков и эти блоки с содержимым одного лишь файла могут быть раскиданы по всему диску. Если файл меньше блока, он все равно займет один блок целиком. Таким образом, кучкой мелких файлов можно забить весь диск, хотя в сумме размер всех файлов будет гораздо меньше объема диска.
Все это сделано для того, чтоб можно было эффективно изменять и удалять файлы, а не только записывать их один раз и больше не менять. Однако для резервного копирования нам не надо изменять файлы, нам надо записать их один раз, а значит можно воспользоваться более подходящим под задачу решением. Например, сделать как вы и сказали - просто ссылка на начало файла в блобе, где файлы записаны один за другим. Плюс файлы можно сжимать, что еще больше сэкономит места. Ну и для надежности не обязательно ксорить, есть и другие эффективные алгоритмы, вроде можно где-то 15% избыточности добавить и при этом суметь восстановить поврежденные данные.
Согласен, всё описанное вами абсолютно верно. И отлично дополняет. Я решил, чтобы статья была лёгкой для чтения опустить подробности. Это как рассмотрение солнечной системы, если нарисовать все планеты и солнце в масштабе, но это будет не наглядно и начинать погружаться в астрономию с этого будет тяжело. Рассмотрение всех возможных эффективных способов сжатия мне кажется это вообще отдельная тема, в которой я точно не силён. В этом беда наглядных пособий, они не точны и приходится делать некоторые допущения.
можно полностью резервировать 2 диска...
Я понимаю, что Вы имеете в виду, но вообще-то по-русски "резервирование" - это то, что по-английски называется allocation или booking.
Возможно стоит конкретизировать. Буду рад, если подскажете более точный термин. Тут ведь с какой стороны посмотреть. Физически у вас есть возможность восстановить утраченные / повреждённые данные. И это в русскоязычном сегменте обычно зовётся "резервированием", с другой, конечно это не система хранения данных типа rsync, готового RAID и т.д.
Файловая система без фокусов: как hard links и XOR сэкономят ваши гигабайты