amarao (amarao_san) wrote,
amarao
amarao_san

И ещё раз об идейном конфликте

Тезис: крупные (тяжёлые/важные) приложения должны хранить данные на отдельных разделах. Это я полагаю аксиомой.

Далее мы имеем идейно различающиеся подходы:

1) разделы для данных приложения монтируются в "места по-умолчанию" для приложений.
2) Разделы монтируются в одно место, а приложения переконфигурируются для хранения данных в новом месте.
3) Разделы монтируются в одно место, а у приложений места по-умолчанию являются симлинками на точки монтирования.

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

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

Третий подход с одной стороны сочетает плюсы первых двух, с другой стороны имеет определённый минус: симлинк всё-таки не каталог, с одной стороны. С другой стороны, раскиданные симлинки по файловой системе управляемы даже хуже, чем точки монтирования. Однако, например, на умершей системе, просто глядя на файловую систему можно сказать, что "тут был симлинк туды-то". В случае развала и смерти системы с точками монтирования мы это можем сказать только получив в руки /etc/fstab. При этом, однако, второй подход требует от нас аналогичного, но с файлами конфигурации.


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

Изложу ещё раз мысли:

1) Я сторонник максимально возможных дефолтных конфигов. Чем меньше ищешь багов, тем меньше их находишь. Дефолтные пути позволяют легко переводить данные с сервера на сервер (данные могут содержать полные пути, в этом случае голыми конфигами не обойдёшься). Посторонний человек (например, последователь по работе) найдёт объекты именно там, где ожидает найти, вместо того, чтобы задумчиво размышлять на тему, "почему у нас файлы конфигурации в /var, а кеш в /etc? Чем больше система похожа на референс, тем больше к ней применимы всякие howto в буквальном исполнении.
2) mount на живой системе позволяет легко получить список точек монтирования.
3) Такой метод легко развивается эволюционно: сначала у нас был отдельным разделом /var, потом из него выделились в отдельные разделы /var/mail и /var/lib/mysql, потом у нас /var/lib/mysql рассыпался на 10+ отдельных разделов для разных баз данных, а для сквида был выделен отдельный раздел в /var/spool/squid. В каждый момент времени наше направление всегда понятно - мы всё глубже и глубже режем иерархию на отдельные разделы. При одноуровневом монтировании в "специальный каталог" мы с одной стороны имеем его как самый наглядный, с другой стороны, мы можем получить конфликт (/var/mail и /var/spool/mail), чреватный неинтуитивными переименованиями для разрешения неоднозначности.
Subscribe

  • Madoka

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

  • И это не то,о чём вы подумали

  • онгоинг

    One Piece, наконец, дополз до battle mode. Ещё два месяца и там станет горячо. HxH идёт удивительно steady, даже быстрее, чем я ожидал. 20ая серия -…

  • Post a new comment

    Error

    default userpic

    Your IP address will be recorded 

    When you submit the form an invisible reCAPTCHA check will be performed.
    You must follow the Privacy Policy and Google Terms of use.
  • 7 comments