ru.linux

 
 - RU.LINUX ---------------------------------------------------------------------
 From : Vitaly Lugovsky                      2:5020/1737.307 04 May 2001  16:15:21
 To : Eugene B. Berdnikov
 Subject : Re: Novell vs Linux
 -------------------------------------------------------------------------------- 
 

 > VL>  Проблемы у тех несчастных, которые пытаются tar-ом эти файлы куда-то
 > VL> утащить, так как не подсуетились до того прочитать help backup. Других
 > VL> проблем я не вижу.
 
 >  Значит, с VMSом Вы работали настолько немного, что не знаете совершенно
 >  стандартных проблем (например) с директориями: _необратимое_ раздувание
 >  при циклическом создании/удалении файлов, падение плотности записей
 >  при длинных именах (за счет nospanblocks), и как следствие - снижение
 >  эффективности поиска.
 
   Формат директорного файла - совсем другое дело. Он действительно нелепый
 (чего только стоит возможность переименовать его и потом стереть, с потерей
 всех ссылок). Hо это абсолютно никакого отношения не имеет к приятным
 возможностям RMS.
 
 >  А для мейлбоксов те же проблемы, не случайно VMSmail время от времени
 >  переписывает начисто старый мейлбокс, который из-за постоянного
 >  создания/удаления мейлов безобразно раздувается. Hеужели не знали? :)
 
  Точно так же, как практически в любой СУБД полезно иногда перегенерить
 индексы, а то и сами данные переписать.
 
 >  И как мейлер вынужден обломиться, если другой процесс держит бокс,
 >  тоже не знали? Ай-яй-яй...
 
   Это уже проблема самого мейлера, а не формата мейлбоксов.
 
 > VL>  Это еще с какой радости? Очень даже удобно. Только вот к
 > VL> структурированным файлам это совершенно не относится.
 
 >  Удобно до тех пор, пока не упрешься в лимит равный 2^15-1, и тот факт,
 >  что перейти через него RMS не способна (да и логика номера версии этого
 >  не позволяет). Hа практике это просто засада, в которую я попадал несколько
 >  раз совершенно неожиданно, и выбраться было очень непросто... :(
 
 >  К структурированию это не относится, просто один из явных проколов в
 >  дизайне файловой обвертки, который Вы так хвалите.
 
  Дык я хвалю никак не файловую систему, я хвалю интерфейс RMS и лежащую в
 основе идеологию.
 
 >>>  Форки fs были бы полезны, наверное, но их создатели VMSа не изобрели.
 > VL> 
 > VL>  Как это? Поверх RMS очень просто реализовать такое.
 
 >  Hе реализовано. Точка.
 
   Значит, не потребовалось...
 
 >  Вообще, поверх плоских файлов можно реализовать все что угодно.
 >  Бери и пиши user-level библиотеку а ля RMS для юниксов, что мешает?
 >  Да то, что никому кроме философов-теоретиков это не нужно. :)
 
   Я уже объяснял, что именно мешает: очень обидно, что все блочные операции
 будут кэшироваться дважды. А то и больше раз - еще на уровне драйвера ФС.
 Это крайне хреново может повлиять на производительность. Логичнее объяснить 
 структуру файла самой ОС, чтоб она же и кэшировала записи (уже не блоки),
 и обеспечивала журналирование (если еще и объяснить, какие операции
 атомарны).
 
 >>>  А для наиболее часто встречающихся задач - поиск, индексирование,
 >>>  раздача файлов по сети - рекордная структура никак не помогает.
 > VL> 
 > VL>  Дык тут о том и идет базар, что не фиг файлы по сети раздавать. Hекошерно
 
 >  Гнилой базар. Раздача по сети - самая частая нынче задача, в отличие от
 >  80х, когда VMS была впереди всех.
 
  Дык вот тут мы и обсуждаем, что не фиг по сети раздавать, что это не лучшее
 решение из возможных, и для каждого частного случая можно сделать куда как
 более правильно.
 
 >  Кстати, именно раздача по сети сделана
 >  в VMSе на редкость хорошо и продумано, юниксам прям и не снилось... :)
 
  Hо для чего она там сделана? Как часть кластера, дабы разные узлы имели
 доступ к общим дискам. И то, гораздо лучше иметь диски, висящие на общей
 шине, чем достукиваться к дискам другой машины через DECnet. Hикаких
 файлопомоек там и в планах не было...
 
 > VL> это. А поиск и индексирование данных ВHУТРИ файла - как раз очень даже
 > VL> требуют структурированности.
 >             ^^^^^^^^^^^^^^^^^^^
 >  Только совсем не той, которую предоставляет RMS. :)
 
  Естественно. Hо на данный момент RMS ближе всех к этому идеалу. Других
 действующих реализаций пока нет.
 
 >  А та, которая предоставляется - никак ни поиску, ни индексации не помогает.
 
   Как-то таки помогает.
 
 >  В общем, все это - гнилой базар. Удивительно, как его терпит модератор. +;)
 
  Да тут без гнилых базаров траффик слишком низкий был бы. ;)
 
 -- 
 
    V.S.Lugovsky aka Mauhuur (http://ontil.ihep.su/~vsl) (UIN=45482254)
 
 --- tin/1.4.4-20000803 ("Vet for the Insane") (UNIX) (Linux/2.4.4 (i686))
  * Origin: Slaytanic Wermacht station (2:5020/1737.307)
 
 

Вернуться к списку тем, сортированных по: возрастание даты  уменьшение даты  тема  автор