В Пнд, 29/10/2007 в 11:26 +0200, Dmitry Nezhevenko пишет:
PS. Не надо меня в CC вписывать. Я об этом не просил.
В Evolution есть две кнопки: Replay и Replay to all. Если я жму
Replay письмо пойдёт только автору, если Replay to all то автору и в
рассылку. Третьей кнопки нет!
--
Покотиленко
В Пнд, 29/10/2007 в 11:09 +0200, Dmitry Nezhevenko пишет:
On Mon, Oct 29, 2007 at 11:09:42AM +0300, Admont wrote:
Появился следующий вопрос - список файлов имеет резон хранить в базе
данных,
если требуется только проверять их существование, или файловая система
работает с такой
29.10.2007 11:09, Admont пишет:
IMHO, ФС лучше справится с этой задачей.
Но не обязательно это ext3.
Это Вы к чему?
К тому, что 10 000 директорий на одном уровне - это много, но тоже
решаемо на уровне ФС без дополнительных сущностей.
Кстати, все 10 000 директорий будут на одном уровне?
У пн, 2007-10-29 у 11:17 +0200, Покотиленко Костик пише:
В Пнд, 29/10/2007 в 11:26 +0200, Dmitry Nezhevenko пишет:
PS. Не надо меня в CC вписывать. Я об этом не просил.
В Evolution есть две кнопки: Replay и Replay to all. Если я жму
Replay письмо пойдёт только автору, если Replay to all
Dmitry Nezhevenko - debian-russian@lists.debian.org @ Mon, 29 Oct 2007
11:39:18 +0200:
PS. Не надо меня в CC вписывать. Я об этом не просил.
В Evolution есть две кнопки: Replay и Replay to all. Если я жму
Replay письмо пойдёт только автору, если Replay to all то автору и в
рассылку.
On Sunday 28 October 2007 19:32, Alexey Pechnikov wrote:
В сообщении от Sunday 28 October 2007 19:21:24 Maxim Kudelya написал(а):
Alexey Pechnikov wrote:
Появился следующий вопрос - список файлов имеет резон хранить в базе
данных, если требуется только проверять их существование, или
IMHO, ФС лучше справится с этой задачей.
Кстати, все 10 000 директорий будут на одном уровне?
Да, на одном уровне.
On Monday 29 October 2007 12:17, Покотиленко Костик wrote:
В Пнд, 29/10/2007 в 11:26 +0200, Dmitry Nezhevenko пишет:
PS. Не надо меня в CC вписывать. Я об этом не просил.
В Evolution есть две кнопки: Replay и Replay to all. Если я жму
Replay письмо пойдёт только автору, если Replay to all то
В сообщении от Monday 29 October 2007 13:09:11 Alexander Vlasov написал(а):
У пн, 2007-10-29 у 12:39 +0300, Alexey Pechnikov пише:
IMHO, ФС лучше справится с этой задачей.
Кстати, все 10 000 директорий будут на одном уровне?
Да, на одном уровне.
ext3 не позволяет больше 32k каталогов
У пн, 2007-10-29 у 12:39 +0300, Alexey Pechnikov пише:
IMHO, ФС лучше справится с этой задачей.
Кстати, все 10 000 директорий будут на одном уровне?
Да, на одном уровне.
ext3 не позволяет больше 32k каталогов на одном уровне, AFAIR.
--
Alexander Vlasov
ZULU-UANIC
JID: zulu at
В Пнд, 29/10/2007 в 12:49 +0300, Artem Chuprina пишет:
Dmitry Nezhevenko - debian-russian@lists.debian.org @ Mon, 29 Oct 2007
11:39:18 +0200:
PS. Не надо меня в CC вписывать. Я об этом не просил.
В Evolution есть две кнопки: Replay и Replay to all. Если я жму
Replay письмо
В Пнд, 29/10/2007 в 13:42 +0400, Max Dmitrichenko пишет:
On Monday 29 October 2007 12:17, Покотиленко Костик wrote:
В Пнд, 29/10/2007 в 11:26 +0200, Dmitry Nezhevenko пишет:
PS. Не надо меня в CC вписывать. Я об этом не просил.
В Evolution есть две кнопки: Replay и Replay to all. Если я
locate - list files in databases that match a pattern
Сие есть поиск, это другая задача.
С поиском понятно, а вот просто проверять на exists (tclsh# file exists
$fname)?
HINT: IIRC, предикат существования соответствует предикату (найдено = 1
вхождений).
И о чем это говорит? Если
Max Dmitrichenko - debian-russian@lists.debian.org @ Mon, 29 Oct 2007
13:49:08 +0400:
Появился следующий вопрос - список файлов имеет резон хранить в базе
данных, если требуется только проверять их существование, или файловая
система работает с такой задачей достаточно эффективно?
On Monday 29 October 2007 13:06, Artem Chuprina wrote:
Max Dmitrichenko - debian-russian@lists.debian.org @ Mon, 29 Oct 2007
13:49:08 +0400:
Появился следующий вопрос - список файлов имеет резон хранить в
базе данных, если требуется только проверять их существование, или
файловая
Полезно еще учитывать, что у locate информация по определению устаревшая.
Полезно, но это издержки любой БД, которая не обновляется с каждым
добавлением/удалением. Делать это на уровне ФС? Где-то я видел надпись,
что база данных - не единственный дурацкий способ организации ФС ;-)
Запрос к
Alexey Pechnikov - debian-russian@lists.debian.org @ Mon, 29 Oct 2007
13:24:05 +0300:
Полезно еще учитывать, что у locate информация по определению устаревшая.
Полезно, но это издержки любой БД, которая не обновляется с каждым
добавлением/удалением. Делать это на уровне ФС? Где-то я
29.10.07, Artem Chuprina[EMAIL PROTECTED] написал(а):
Alexey Pechnikov - debian-russian@lists.debian.org @ Mon, 29 Oct 2007
13:24:05 +0300:
AP из кэша). Запрос к ФС на существование файла - порядка микросекунды
AP (ФС кэширует, atime выключен). Выигрыш на 3 порядка вас не
AP
Dmitry Fedorov - debian-russian@lists.debian.org @ Mon, 29 Oct 2007 14:05:45
+0300:
AP из кэша). Запрос к ФС на существование файла - порядка микросекунды
AP (ФС кэширует, atime выключен). Выигрыш на 3 порядка вас не
AP интересует? Для меня это повод задуматься.
Во-первых, это
хуже того -- он пишется
У пн, 2007-10-29 у 14:05 +0300, Dmitry Fedorov пише:
29.10.07, Artem Chuprina[EMAIL PROTECTED] написал(а):
Alexey Pechnikov - debian-russian@lists.debian.org @ Mon, 29 Oct 2007
13:24:05 +0300:
AP из кэша). Запрос к ФС на существование файла - порядка
29.10.07, Artem Chuprina[EMAIL PROTECTED] написал(а):
DF Включенный atime разве не кэшируется?
Кэшируется. Но не на чтение, а на запись. Почувствуйте разницу.
И что? write-back же.
Dmitry Fedorov - debian-russian@lists.debian.org @ Mon, 29 Oct 2007 14:29:15
+0300:
DF Включенный atime разве не кэшируется?
Кэшируется. Но не на чтение, а на запись. Почувствуйте разницу.
DF И что? write-back же.
И то, что в какой-то момент оно таки пойдет писаться на диск. Нет,
Появился следующий вопрос - список файлов имеет резон хранить в базе
данных,
если требуется только проверять их существование, или файловая система
работает с такой задачей достаточно эффективно? Примерный масштаб: не
более
10 000 директорий и в каждой не более а) 100
IMHO, ФС лучше справится с этой задачей.
Но не обязательно это ext3.
Это Вы к чему?
К тому, что 10 000 директорий на одном уровне - это много, но тоже
решаемо на уровне ФС без дополнительных сущностей.
Дык про ext3 разговора и не было
Кстати, все 10 000 директорий будут на одном
В сообщении от Monday 29 October 2007 14:50:01 Игорь Чумак написал(а):
Запрос к базе - порядка миллисекунды (угу, база кэширует, но sql-запрос
надо отправить и распарсить и вернуть ответ, хотя бы и из кэша). Запрос к
ФС на существование файла - порядка микросекунды (ФС кэширует, atime
Вот я и предлагаю статистически доказать _пригодность_ (или
непригодность) ФС для решения _твоей_ задачи ;)
Делов то - нагенерить миллион файлов, да пустить 10 поисков, да
среднее время сосчитать.. Результат сравнить например с locate
Или я не прав?
Не прав. Чтобы сделать анализ, надо
Появился следующий вопрос - список файлов имеет резон хранить в базе данных,
если требуется только проверять их существование, или файловая система
работает с такой задачей достаточно эффективно? Примерный масштаб: не более
10 000 директорий и в каждой не более а) 100 файлов б) 1000 файлов. Или
В сообщении от Sunday 28 October 2007 19:21:24 Maxim Kudelya написал(а):
Alexey Pechnikov wrote:
Появился следующий вопрос - список файлов имеет резон хранить в базе
данных, если требуется только проверять их существование, или файловая
система работает с такой задачей достаточно
Появился следующий вопрос - список файлов имеет резон хранить в базе данных,
если требуется только проверять их существование, или файловая система
работает с такой задачей достаточно эффективно? Примерный масштаб: не более
10 000 директорий и в каждой не более а) 100 файлов б) 1000 файлов.
29 matches
Mail list logo