ru.linux

 
 - RU.LINUX ---------------------------------------------------------------------
 From : Vitaly Lugovsky                      2:5020/1737.307 02 May 2001  19:14:37
 To : Antony Y. Bolotin
 Subject : Re: Novell vs Linux
 -------------------------------------------------------------------------------- 
 

 >>  Hет. Hосителем может быть HЕКЭШИРУЮЩЕЕ блочное устройство. О чем я и
 
 > Угу. Вернулись к блочным устройствам :))
 
  Hет. Это не юниксовые блочные устройства. И более высокоуровневая сущность
 - файлы - доступны через совсем другое API.
 
 >>  толкую
 >> - на уровне драйвера ФС в идеологии юниксов нормальную ФС не реализовать,
 >> нужно на более низкий уровень лезть.
 
 > Если я правильно все понял, то такое уже есть или в informix или в DB2 
 > (SQL, кажись от IBM) - там ей даешь отдельную неразмеченную партицию, куда 
 > она свои базы и пихает. Загнать туда данные или получить их можно с помощью 
 > sql запросов.
 
  Вот вот. Каждому приложению по raw device выдавать - выдавалка отвалится.
 А просто захапать себе область на диске, которая бы не кэшировалась, и
 размечать её по своему усмотрению - облом. Да и стандартных средств на то
 нет, в отличии от продвинутых ФС.
 
 > Однако же сам sql-сервер как-то размечает партицию ? Разве это не фс, 
 > которую только он и понимает ? Или... ну хорошо, назовем по другому... 
 
  Это не ФС. ФС должна быть в ядре. 
 
 > Скажем, система индексирования информации. Смысл от перемены названия не 
 > изменяется - с помощью этой системы программа, которая с ней работает, 
 > может (даже доложна) однозначно определить местоположение на устройстве той 
 > информации, которую от нее потребовали. Кто потребовал - не ее забота. Это 
 > может быть как обычная программа пользователя, так и sql-сервер. В любом 
 > случае, запрос к накопителю пойдет в виде "прочитать оттуда столько-то 
 > данных" или "записать туда столько-то таких-то данных". Точнее, 
 > "переместить указатель на такую-то позицию",  а потом "прочитать/записать 
 > данные", если говорить о hd или fd.
 
  Я уже говорил, что не все файлы должны быть последовательными. Так что
 "такой-то позиции" может и не быть.
 
 -- 
 
    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.3-ac14 (i686))
  * Origin: Slaytanic Wermacht station (2:5020/1737.307)
 
 

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