|
ru.linux
- RU.LINUX ---------------------------------------------------------------------
From : Alex Korchmar 2:5020/400 12 May 2007 15:06:56
To : Sergey Rogulev
Subject : Re: Чиста теоретический вопрос про файловые системы
--------------------------------------------------------------------------------
Sergey Rogulev <Sergey.Rogulev@p13.f7.n5031.z2.fidonet.org> wrote:
AK>> наоборот, это ключевой вопрос. Понимание того факта, что ext2 заброшен
AK>> девелоперами и содержит прорву глюков (а может и багов) давно
AK>> поправленых в ext3 убережет от некоторого количества глупых решений.
SR> а, ты об этом... ну так вроде никто и не спорит, что ext2 очень
SR> редко где стоит пользовать.
ее "редко где стоило бы использовать", если бы не этот самый факт.
"ext3, только без лога". А с учетом оного ее использовать не стоит _нигде_.
(ну /boot в r/o на ней можно держать, только незачем, поскольку и
на ext3 можно)
Умерла птичка.
AK>> есть - -i 1024 большинству достаточно. Мне крайне трудно придумать что
AK>> же такое должно быть на fs, чтобы этого не хватило.
SR> у меня там была библиотечка. небольшая такая, около 2 млн.
SR> файлов и поллимона каталогов. а размер раздела - небольшой.
еще раз: доступный минимум - по иноде на килобайт. Если у тебя файлы
еще меньше - это уже клиника.
Hичего кроме бездарной попытки эмуляции базы данных средствами fs мне не
фантазируется. Тут не fs надо менять, а формат данных, оно в любой fs
будет чудовищно неэффективно - размер метаинформации сравним с размером
э... содержимого. Можно и больше.
Иллюстрация: хранить в файлах номера чего-нибудь. По файлу на номерок.
SR>>> вспомни кто и как хранит мелкие файлы (меньше размера блока) и с
SR>>> какой
AK>> ext3 - разумно, reizer - дурацки, ну и что?
SR> то что "дурацки" в данном случае дополнительно дает атрибуты "экономично" и
SR> "быстродоставаемо".
ага, выбирайте любое из двух.
AK>> не знаю где берут такие помойки.
SR> у меня их есть ;) описанных выше библиотечек сейчас несколько, да и та
SR> подросла. мечты с переводом их в SQL уже много лет так и остаются мечтами :(
тут не sql, тут голову включить надо было - много лет назад.
SR> потому что на медленных дисках разница меньше заметна, упирается все уже не
SR> в fs а в seek и трансфер диска.
структура fs не может ли в данном случае играть роль ? ;-)
SR> помершие файловые видел (и лечил) неоднократно. вот только _у меня_ они не
SR> мрут. мож кормлю по другому?
или просто везло.
> Alex
--- ifmail v.2.15dev5.3
* Origin: Demos online service (2:5020/400)
Вернуться к списку тем, сортированных по: возрастание даты уменьшение даты тема автор
|
