Что произойдет, если я добавлю 1 миллион строк в /etc/hosts/
Вы можете использовать что-то вроде:
PATH=$(/usr/bin/getconf PATH)
, чтобы использовать полный путь к getconf, который вернет стандартное значение PATH, которое вы можете использовать в дальнейшем.
То же, что и для любой другой базы данных с плоскими файлами.
На самом деле это общая вещь.
Проблема связана с форматом файла и относится к /etc/passwd, /etc/group, /etc/shells. /etc/phones, /etc/ttys, /etc/services, /etc/fstabи другие в отношении /etc/hosts. Эти файлы не индексируются и не сортируются.поэтому любой поиск должен быть последовательным сканированием, возможно, всего файла. Поиск несуществующей -записи должен считывать каждую запись файла. Вставки и удаления должны читать и записывать каждую запись файла.
Существует причина, по которой BSD переключили базу данных учетных записей пользователей с этого формата плоского файла на Berkeley DB(/etc/pwd.dbи /etc/spwd.db), и это все. База данных Berkeley DB индексируется , и поиск не является последовательным сканированием с начала файла. Это одна из причин появления DNS (методы доступа к неструктурированным файлам были одной из причин HOSTS.TXTпроблем; репликация этого файла по всей сети была другой ).
По этой причине системы электронной -почты используют базы данных в формате CDB, Berkeley DB и других форматах для настройки таких вещей, как списки доменов и учетные записи виртуальных пользователей. Напротив, ваша библиотека C почти наверняка не предусматривает использование какого-либо другого формата базы данных вместо плоского файла для /etc/hosts.
Кроме того, поиск в этой таблице требует выполнения множества операций, от специальных дополнений аргументов команд в оболочках до сетевых инструментов и утилит системного мониторинга/администрирования до печати, веб-браузеров и систем электронной -почты.
База данных плоских файлов с миллионом -записей — плохая идея для этого.
Я еще даже не коснулся того факта, что вставки и удаления должны выполняться атомарно, иначе система увидит файл в частично переписанном состоянии (, что может иметь весьма нежелательные последствия ). Это не будет иметь место , если ваша практика состоит в том, чтобы наивно открывать файл в текстовом редакторе. Большинство текстовых редакторов сами по себе по умолчанию не будут выполнять атомарные обновления файлов. Плоские файловые базы данных, особенно большие, требуют более тщательного обращения, чем люди наивно думают. Нет, это не "просто текстовые файлы".
Использование поиска по имени для фильтрации доступа к WWW-серверу, конечно, тоже плохой механизм.