2013/10/7 Eugene V. Samusev
> но где бы взять инструмент, который будет копировать в /dev/null и
> показывать при этом текущую скорость? (Простто список файлов не надоЮ, надо
> именно мегабайты в секунду).
>
>>
>> $sudo pv -tpreb /dev/sdb | dd of=/dev/null bs=64M
>
>
Огромное спасибо! Я не знал
2013/10/5 Mikhail Ramendik
>
> но где бы взять инструмент, который будет копировать в /dev/null и
> показывать при этом текущую скорость? (Простто список файлов не надоЮ, надо
> именно мегабайты в секунду).
>
> $sudo pv -tpreb /dev/sdb | dd of=/dev/null bs=64M
Mikhail Ramendik ☫ → To Debian-russian List @ Sat, Oct 05, 2013 01:37 +0100
> Попробовал повторить проблему, копируя с каждого из дисков на него же.
> Повторить не удалось. То есть оно произошло только при копировании с одного
> на другой. Надо бы проверить копированием в /dev/null , но где бы взя
2013/10/5 Mikhail Ramendik
> Развитие событий... Я попробовал зажать скорость SATA на полтора гига (как
> было на прежней материнке), но это не помогло. Стал бекапить некие данные
> на второй диск (mc, там видно скорость процесса) - и в какой-то момент
> процесс стал рывками замедляться. Тыр-тыр
g, /var/log/messages, /var/log/kern/log,
> /var/log/daemon/log ничего подозрительного не обнаружено.
>
> Может ли это быть всё-таки HDD? Я могу перенести root на другой диск, их
> два, но там тогда возня с partition resizing (сейчас одна ext3 на весь диск
> с кучей фильмов, ну не
перенести root на другой диск, их
два, но там тогда возня с partition resizing (сейчас одна ext3 на весь диск
с кучей фильмов, ну не прямо же туда root копировать). Есть ли смысл
всё-таки с переносом на другой диск возиться?
И/или что ещё это может быть? Вряд ли ядро, поскольку я уже поднял ядро с
17:43 Sat 07 Apr, Andrey Melnikoff wrote:
> Andrey Tataranovich wrote:
> > У меня пробовалась такая схема:
> > http://blog.tataranovich.com/2012/03/mysql-backup-and-partial-restore.html
> Идея правильная, но пока mysql свой (есть пароль от root'a). А как только он
> чужой?
Чтобы работал мой
Andrey Tataranovich wrote:
> 16:32 Fri 30 Mar, Andrey Melnikoff wrote:
> > Кстати да, раз тут зашел разговор про бакапы mysql - сколько будет длиться
> > снапшот раздела с базами на 20Gb, с учетом того что туда все время что-то
> > пишется? И какова веротяность того, что таблицы будут не битые
13:27 Mon 02 Apr, Скубриев Владимир wrote:
> изначально предполагалось, что /etc будет вынесен в отдельную
> файловую систему, в которую будет как можно меньше вноситься
> изменений. дабы в случае непредвиденной остановки сервера ее
> проверка проходила нормально и сервер запускался до стадии,
31.03.2012 23:38, Sohin Vyacheslaw написал:
28.03.2012 11:20, Andrey Rahmatullin написал:
"сервер не загрузится из-за не достаточности данных или не доступности
/etc"
ну дык а какая разница недоступен будет /etc, который на отдельном
разделе или в корне...?
--
BW
Сохин Вячеслав
изначально п
On Sat, Mar 31, 2012 at 10:38:19PM +0300, Sohin Vyacheslaw wrote:
> ну дык а какая разница недоступен будет /etc, который на отдельном
> разделе или в корне...?
Ну, типа, если /etc отдельный, то он доступен будет,
--
WBR, wRAR
signature.asc
Description: Digital signature
28.03.2012 11:20, Andrey Rahmatullin написал:
> "сервер не загрузится из-за не достаточности данных или не доступности
> /etc"
>
ну дык а какая разница недоступен будет /etc, который на отдельном
разделе или в корне...?
--
BW
Сохин Вячеслав
--
To UNSUBSCRIBE, email to debian-russian-requ...@li
16:32 Fri 30 Mar, Andrey Melnikoff wrote:
> Кстати да, раз тут зашел разговор про бакапы mysql - сколько будет длиться
> снапшот раздела с базами на 20Gb, с учетом того что туда все время что-то
> пишется? И какова веротяность того, что таблицы будут не битые (i.e. при
> разворачивании снапшота
16:23 Fri 30 Mar, Andrey Melnikoff wrote:
> Mikhail A Antonov wrote:
> > [-- text/plain, кодировка base64, кодировка: KOI8-R, 26 строк --]
>
> > 29.03.2012 19:01, Andrey Melnikoff пишет:
> > > Ну со свопом сейчас уже всё трудно. Его можно и не делать более 2Gb. Если
> > > нужно - можно с помо
On Fri, 30 Mar 2012 16:23:36 +0400
Andrey Melnikoff wrote:
>> На сколько я помню, GPT умеет не всякий BIOS, да и даст ли мне GPT на
>> лету поменять размеры разделов? Снапшоты? Миграцию с диска на диск?
>Снапшоты? ext3? на ходу? Да-да, каждый день наблюдаю:
>
>ext3_orp
gt; лету поменять размеры разделов? Снапшоты? Миграцию с диска на диск?
Снапшоты? ext3? на ходу? Да-да, каждый день наблюдаю:
ext3_orphan_cleanup: deleting unreferenced inode 4826057
ext3_orphan_cleanup: deleting unreferenced inode 1769475
EXT3-fs: dm-3: 75 orphan inodes deleted
EXT3-fs:
Andrey Tataranovich wrote:
> 19:01 Thu 29 Mar, Andrey Melnikoff wrote:
> > Для себя вообще не вижу надобности в lvm. Нет, он нужен мне на моей рабочей
> > машине, куда я переодически доабвляю мелкие винты под хранилище торрентов.
> > Но вот на серверах - совершенно бесполезная вещь.
> Как р
On Fri, 30 Mar 2012 09:06:45 +0300
Andrey Tataranovich wrote:
>> вчера ставил дебиан по новой схеме, вынести /etc в отдельный раздел
>> установщик не дал.
>> сказал, что /etc должна находится в root fs и его по всей видимости
>> не переубедить.
>>
>> ни кто случайно не подскажет более точно поче
13:31 Fri 30 Mar, Andrey Rahmatullin wrote:
> On Fri, Mar 30, 2012 at 09:06:45AM +0300, Andrey Tataranovich wrote:
> > > вчера ставил дебиан по новой схеме, вынести /etc в отдельный раздел
> > > установщик не дал.
> > > сказал, что /etc должна находится в root fs и его по всей видимости
> > > н
On Fri, Mar 30, 2012 at 09:06:45AM +0300, Andrey Tataranovich wrote:
> > вчера ставил дебиан по новой схеме, вынести /etc в отдельный раздел
> > установщик не дал.
> > сказал, что /etc должна находится в root fs и его по всей видимости
> > не переубедить.
> >
> > ни кто случайно не подскажет более
09:10 Fri 30 Mar, Скубриев Владимир wrote:
> 29.03.2012 1:16, Michael Shigorin написал:
>
> >>Можно не пилить так, а сделать квотами, но _мне_ так удобнее.
> >Аналогично -- один раздел (не считая /home или /var, соответственно)
> >делаю только на ноутах и hardware node серверов виртуализации.
29.03.2012 1:20, Michael Shigorin написал:
On Tue, Mar 27, 2012 at 07:16:46PM +0400, Igor Savinykh wrote:
Причем были случаи когда диски начинали сыпаться с областей в var.
Диски менять надо через три года более-менее любые, см. тж.
http://research.google.com/archive/disk_failures.pdf
+1
29.03.2012 1:16, Michael Shigorin написал:
Можно не пилить так, а сделать квотами, но _мне_ так удобнее.
Аналогично -- один раздел (не считая /home или /var, соответственно)
делаю только на ноутах и hardware node серверов виртуализации.
вчера ставил дебиан по новой схеме, вынести /etc в отде
29.03.2012 19:01, Andrey Melnikoff пишет:
> Ну со свопом сейчас уже всё трудно. Его можно и не делать более 2Gb. Если
> нужно - можно с помощью dphys-swapfile по ходу создавать его.
> Но как показывает моя практика - для тяжелонагруженой машины с достаочным
> количеством свопа и памяти - своп иногд
19:01 Thu 29 Mar, Andrey Melnikoff wrote:
> Для себя вообще не вижу надобности в lvm. Нет, он нужен мне на моей рабочей
> машине, куда я переодически доабвляю мелкие винты под хранилище торрентов.
> Но вот на серверах - совершенно бесполезная вещь.
Как раз на серверах оно полезно, особенно е
Mikhail A Antonov wrote:
> [-- text/plain, кодировка base64, кодировка: windows-1251, 86 строк --]
> 28.03.2012 09:45, Скубриев Владимир пишет:
> > Вы ведь в списке рассылке, которая по сути своей существует с целью
> > помощи одних - другим. Расскажите пожалуйста как вы делаете разбивку
> > на с
28.03.2012 14:02, Mikhail A Antonov написал:
28.03.2012 13:59, Скубриев Владимир пишет:
Спасибо за участие в треде. Вот ведь как иногда бывает полезно
обсудить давно понятное!
Скажи, ты знаешь что такое оверквотинг?
неа, только слышал, щас почитаю
--
С Уважением,
специалист по техническом
29.03.2012 01:16, Michael Shigorin пишет:
>> ИМХО, /tmp на tmpfs самое место, но опять же зависит от задач.
>> Некоторые очень хотят много писать в /tmp - например mc.
> pad:~> realpath $TMP/mc-mike
> /tmp/.private/mike/mc-mike
>
> Это точно так же мог быть $HOME/tmp/mc-mike, если бы локальной
> и
On Tue, Mar 27, 2012 at 07:16:46PM +0400, Igor Savinykh wrote:
> Причем были случаи когда диски начинали сыпаться с областей в var.
Диски менять надо через три года более-менее любые, см. тж.
http://research.google.com/archive/disk_failures.pdf
--
WBR, Michael Shigorin
-- Linux.Kiev
огда лень или по барабану.
> >>>>> Например программа писала в /var который по сути у вас
> >>>>> находится на одной файловой системе с /etc и т.д.
> >>>>> произошла ошибка, например выключение питания. Очень
> >>>>> велика
28.03.2012 13:59, Скубриев Владимир пишет:
>
> Спасибо за участие в треде. Вот ведь как иногда бывает полезно
> обсудить давно понятное!
>
Скажи, ты знаешь что такое оверквотинг?
--
Best regards,
Mikhail
-
WWW: http://www.antmix.pp.ru/
XMPP: ant...@stopicq.ru
signature.asc
Description: OpenPG
загрузится из-за не достаточности данных или не доступности /etc.
о_О
я часто с таким встречался
За более чем 10 лет не встречался ни разу чтобы ext3 крошилась от
такого. С недавнего времени использую ext4, но и она себя так не ведёт.
4. lvm 5 - var
Херасе.
Для примера ради. Помога
что сервер не
>>>>> загрузится из-за не достаточности данных или не доступности /etc.
>>>> о_О
>>> я часто с таким встречался
За более чем 10 лет не встречался ни разу чтобы ext3 крошилась от
такого. С недавнего времени использую ext4, но и она себя так не
On Wed, Mar 28, 2012 at 08:56:20AM +0400, Скубриев Владимир wrote:
> >>Например программа писала в /var который по сути у вас находится на
> >>одной файловой системе с /etc и т.д. произошла ошибка, например
> >>выключение питания. Очень велика вероятность того, что сервер не
> >>загрузится из-за не
On Wed, Mar 28, 2012 at 09:45:26AM +0400, Скубриев Владимир wrote:
> Вариант 1 - совершенно не правилен с точки зрения надежности. Как в
> принципе и вариант 2. Причина этому - все в одной файловой системе -
> большая вероятность проблем загрузки сервера в случае ошибок на
> файловы
28.03.2012 09:53, Скубриев Владимир пишет:
> 27.03.2012 19:33, Igor Savinykh написал:
>> 27.03.2012 12:01, Mikhail A Antonov написал:
>>
>>> А заодно расскажи зачем swap не на lvm.
>>
>> Для универсальности я думаю swap можно разместить на LVM. Но в случае
>> сервера если сразу под swap выделить 1-
27.03.2012 19:33, Igor Savinykh написал:
27.03.2012 12:01, Mikhail A Antonov написал:
А заодно расскажи зачем swap не на lvm.
Для универсальности я думаю swap можно разместить на LVM. Но в случае
сервера если сразу под swap выделить 1-2 Gb, то вряд ли потребуется в
обозримом будущем увеличи
м" от "по разным lvm
томам разносить"
тем, что в случае использования lv томов мы получаем гибкость за счет
изменения размеров файловых систем, в случае необходимости.
но это и так всем понятно - это плюс от использования lvm
1. sda1 512 /boot желательно ext3 опять же с точки зре
27.03.2012 12:01, Mikhail A Antonov написал:
27.03.2012 11:18, Andrey Rahmatullin пишет:
On Tue, Mar 27, 2012 at 11:12:15AM +0400, Скубриев Владимир wrote:
2. sda2 8192 swap с точки зрения сервера с 4 Гигами оперативы
Обоснуйте.
захотелось так
А заодно расскажи зачем swap не на lvm.
пото
если
еще по разным lvm томам разносить, то появляется гибкость lvm.
А как можно на одном lv два раздела держать?
не придирайтесь к словам, кому надо, тот понял. разносить каталоги по
разным томам - естественно.
1. sda1 512 /boot желательно ext3 опять же с точки зрения
совместимости. я
On Tue, Mar 27, 2012 at 07:33:48PM +0400, Igor Savinykh wrote:
> >А заодно расскажи зачем swap не на lvm.
> Для универсальности я думаю swap можно разместить на LVM. Но в
> случае сервера если сразу под swap выделить 1-2 Gb, то вряд ли
> потребуется в обозримом будущем увеличивать этот раздел.
"Мож
27.03.2012 12:01, Mikhail A Antonov написал:
А заодно расскажи зачем swap не на lvm.
Для универсальности я думаю swap можно разместить на LVM. Но в случае сервера
если сразу под swap выделить 1-2 Gb, то вряд ли потребуется в обозримом будущем
увеличивать этот раздел.
У меня на сервере при
27.03.2012 11:12, Скубриев Владимир написал:
Рассказываю...
Владимир, спасибо за полный ответ. Интересно познакомиться с твоим опытом.
Полностью поддерживаю подход, когда на сервере создается несколько разделов.
У меня несколько серверов пока без LVM. На них отдельные разделы для
/, /home, /tm
е по разным lvm томам разносить, то появляется гибкость lvm.
> >А как можно на одном lv два раздела держать?
> извиняюсь - неправильно выразился, я имел в виду по разным томам
> конечно разные каталоги
Поясните, чем отличается "разношу по разным разделам" от "по разным lvm
том
On Tue, 27 Mar 2012 11:12:15 +0400
Скубриев Владимир wrote:
>Выносить раздел boot за lvm имеет смысл, для совместимости с grub.
>По крайней мере иначе поставить будет сложно, но по идее варианты
>существуют.
GRUB2 был ещё в Lenny, едва ли имеет смысл соблюдать совместимость с
Etch (да и там LI
, tmp, home разношу по разным разделам, кстати если
еще по разным lvm томам разносить, то появляется гибкость lvm.
А как можно на одном lv два раздела держать?
извиняюсь - неправильно выразился, я имел в виду по разным томам конечно
разные каталоги
1. sda1 512 /boot желательно ext3 опять же
27.03.2012 11:18, Andrey Rahmatullin пишет:
> On Tue, Mar 27, 2012 at 11:12:15AM +0400, Скубриев Владимир wrote:
>> 2. sda2 8192 swap с точки зрения сервера с 4 Гигами оперативы
> Обоснуйте.
А заодно расскажи зачем swap не на lvm.
И ещё маленькое дополнение - используя lvm не обязательно забивать
26.03.2012 20:33, Sergej Kochnev написал:
LVM никак не влияет на устойчивость к перебоям питания. Раньше не
работали барьеры ФС, но примерно в 2.6.30 это починили.
Все ясно. Буду использовать вариант 2 с LVM.
Всем спасибо.
--
To UNSUBSCRIBE, email to debian-russian-requ...@lists.debian.org
w
м разносить, то появляется гибкость lvm.
А как можно на одном lv два раздела держать?
> 1. sda1 512 /boot желательно ext3 опять же с точки зрения
> совместимости. я например использую acronis, чтобы сохранять разделы
Уууу.
> 2. sda2 8192 swap с точки зрения сервера с 4 Гигами оперативы
О
разделы со swap и ext3 и
установить Debian.
2) Вариант с LVM - настроить LVM, диск разбить на разделы со swap и
ext3 и установить Debian. /boot можно вынести за LVM.
Вариант 2 более гибкий.
Меня интересует надежность варианта 2 в плане реакции на мелкие сбои:
сбой питания (конечно сервер
ко я знаю, кроме надёжности
они ничего дать не могут. Если шансы внезапной остановки малы, а
нагрузки на ФС большие, то barrier=0 может быть довольно разумным
решением.
>Если все именно так, как описал выше, то применение ext3 + lvm это
>удар по производительности за счет применения барьеров
что ext4
эффективнее при использовании барьеров, которые с некоторого релиза
включены по умолчанию.
Верно?
Если все именно так, как описал выше, то применение ext3 + lvm это
удар по производительности за счет применения барьеров и, возможно,
потеря положительного эффекта от самой функции барьера фс.
???
On Mon, 26 Mar 2012 21:05:19 +0400
"Dmitry A. Zhiglov" wrote:
>26 марта 2012 г. 20:33 пользователь Sergej Kochnev
> написал:
>> LVM никак не влияет на устойчивость к перебоям питания. Раньше не
>> работали барьеры ФС, но примерно в 2.6.30 это починили.
>
>Что за барьеры ФС?
http://lwn.net/Articl
26 марта 2012 г. 20:33 пользователь Sergej Kochnev
написал:
> LVM никак не влияет на устойчивость к перебоям питания. Раньше не
> работали барьеры ФС, но примерно в 2.6.30 это починили.
Что за барьеры ФС?
нчестер.
>1) Стандартный вариант - диск разбить на разделы со swap и ext3 и установить
>Debian.
>
>2) Вариант с LVM - настроить LVM, диск разбить на разделы со swap и ext3 и
>установить Debian. /boot можно вынести за LVM.
>
>Вариант 2 более гибкий.
>
>Меня интересует н
вера на 1 винчестер.
> 1) Стандартный вариант - диск разбить на разделы со swap и ext3 и установить
> Debian.
>
> 2) Вариант с LVM - настроить LVM, диск разбить на разделы со swap и
> ext3 и установить Debian. /boot можно вынести за LVM.
>
> Вариант 2 более гибкий.
>
Всем привет!
Давно присматриваюсь к LVM, прочитал различную документацию, обсуждения в
форумах.
Хочу спросить у тех кто имеет опыт работы с LVM.
Рассмотрим ситуацию установки небольшого сервера на 1 винчестер.
1) Стандартный вариант - диск разбить на разделы со swap и ext3 и установить
2 октября 2010 г. 21:35 пользователь Sergey Kharlamov
написал:
> Проблемы с монтированием жесткого диска. Файловая система Ext3. Размер
> 320GB, Монтирую следующим образом mount -t ext3 /dev/sda1 /mnt/sda1
> выдает ошибку
> EXT3-fs error (device sda1): ext3_check_descriptors: Ino
Проблемы с монтированием жесткого диска. Файловая система Ext3. Размер
320GB, Монтирую следующим образом mount -t ext3 /dev/sda1 /mnt/sda1
выдает ошибку
EXT3-fs error (device sda1): ext3_check_descriptors: Inode table for
group 1857 not in group (block 0)!
EXT3-fs: group descriptors corrupted
Спасибо. Буду копать.
Если получу какие-то результаты, то сообщу.
--
With best regards,
Ivan Surzhenko
Это должно справиться: http://anyfs-tools.sourceforge.net/
29 октября 2009 г. 14:33 пользователь Ivan Surzhenko
написал:
> Нужно перевести раздел из FAT32 в EXT3.
> При этом очень хочется, чтобы инфу никуда не переписывать на время
> конвертации.
> Порылся в гугле. Пишут, что нельзя
Thu, Oct 29, 2009 at 13:33 +0200 Ivan Surzhenko воздействовал на энтропию:
> Нужно перевести раздел из FAT32 в EXT3.
> При этом очень хочется, чтобы инфу никуда не переписывать на время
> конвертации.
> Порылся в гугле. Пишут, что нельзя.
> Меня вот смутило, что гугль дает
Нужно перевести раздел из FAT32 в EXT3.
При этом очень хочется, чтобы инфу никуда не переписывать на время конвертации.
Порылся в гугле. Пишут, что нельзя.
Меня вот смутило, что гугль дает ссылки на инфу датируемую этак 2004/2005 годом.
Хочу уточнить. На сегодняшний день так и не придумали
Mikhail Ramendik пишет:
2008/10/6 Andrey Lyubimets <[EMAIL PROTECTED] <mailto:[EMAIL PROTECTED]>>
Mikhail Ramendik пишет:
Всем привет!
Есть жёсткий диск SATA. По hdparm скорость больше 50 мегов в
секунду.
А вот копирование с одного раздела ex
Mikhail Ramendik пишет:
Всем привет!
Есть жёсткий диск SATA. По hdparm скорость больше 50 мегов в секунду.
А вот копирование с одного раздела ext3 на другой - 8-10 мегов в секунду...
Кто 8-10 кажет? mc ? ;-)
Это нормально? Можно ли сделать быстрее, и если можно - то как?
--
Yours, Mikhail
егов в
> секунду.
> > А вот копирование с одного раздела ext3 на другой - 8-10
> мегов в секунду...
> > Это нормально? Можно ли сделать быстрее, и если можно - то
> как?
> >
>
>
> Что копируется? О
2008/10/1 Dmitry Nezhevenko <[EMAIL PROTECTED]>
> On Wed, Oct 01, 2008 at 08:40:49PM +0100, Mikhail Ramendik wrote:
> > Есть жёсткий диск SATA. По hdparm скорость больше 50 мегов в секунду.
> > А вот копирование с одного раздела ext3 на другой - 8-10 мегов в
> секунду...
,-[Thu, Oct 02, 2008 at 11:55 +0300, Покотиленко Костик:]
|> А вот копирование с одного раздела ext3 на другой - 8-10 мегов в
|
|Это зависит... Но в целом нормально, разделы на одном диске - скорость
|теоретически падает в 2 раза, + фрагментация +ещё несколько моментов -
|примерно
В Срд, 01/10/2008 в 20:40 +0100, Mikhail Ramendik пишет:
> Всем привет!
>
> Есть жёсткий диск SATA. По hdparm скорость больше 50 мегов в секунду.
>
> А вот копирование с одного раздела ext3 на другой - 8-10 мегов в
> секунду...
>
> Это нормально? Можно ли сделать быстре
On Wed, Oct 01, 2008 at 08:40:49PM +0100, Mikhail Ramendik wrote:
> Есть жёсткий диск SATA. По hdparm скорость больше 50 мегов в секунду.
> А вот копирование с одного раздела ext3 на другой - 8-10 мегов в секунду...
> Это нормально? Можно ли сделать быстрее, и если можно - то как
Всем привет!
Есть жёсткий диск SATA. По hdparm скорость больше 50 мегов в секунду.
А вот копирование с одного раздела ext3 на другой - 8-10 мегов в секунду...
Это нормально? Можно ли сделать быстрее, и если можно - то как?
--
Yours, Mikhail Ramendik
Hello!
В сообщении от Wednesday 13 August 2008 13:00:30 Sergey Spiridonov написал(а):
> > не менее, я полагаю, что в дебиане должен быть пакет, в котором можно
> > полноценно работать с русским или любым другим языком. Насколько такое
> > пожелание соответствует идеологии дебиана - оценивать не бе
On Tue, Aug 12, 2008 at 06:32:02PM +0400, Alexey Pechnikov wrote:
> > ЗЫ Я призываю _всех_ пользователей и разработчиков активнее использовать
> > багсистему, это большая помощь нам всем! Правильно оформленный багрепорт
> > это гораздо лучше чем письмо мэинтейнеру.
>
> К сожалению, я не специалист
Привет
Alexey Pechnikov wrote:
> не менее, я полагаю, что в дебиане должен быть пакет, в котором можно
> полноценно работать с русским или любым другим языком. Насколько такое
> пожелание соответствует идеологии дебиана - оценивать не берусь. Мантейнеру
> писал, но ответа не получил.
Ещё раз
Alexey Pechnikov пишет:
Hello!
В сообщении от Monday 11 August 2008 13:00:55 Sergey Spiridonov написал(а):
Дебиан официально поддерживает юникод ещё с sarge. Так что ещё с sarge
все пакеты не поддерживающие юникод должны получать баг с уровнем wishlist.
Поправьте, если я не прав, но в lenny по
Hello!
В сообщении от Tuesday 12 August 2008 20:57:16 Andrey Vasilenko написал(а):
> форматируем с dir_index.
Индекс директорий можно и без форматирования включить, прямо на "живой" ФС.
Best regards, Alexey.
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble
Итак, подводя предварительную черту, если можно так выразится.
Монтируем с noatime и nodiratime, форматируем с dir_index.
Не тороплюсь пока, место на первом ЖД ещё есть. Ещё раз повторю, ОСОБЫЕ
требования
к ФС отсутствуют, т.к. сейчас у меня нет задач, которые бы постоянно
требовали интенсивного
Hello!
В сообщении от Monday 11 August 2008 13:00:55 Sergey Spiridonov написал(а):
> Дебиан официально поддерживает юникод ещё с sarge. Так что ещё с sarge
> все пакеты не поддерживающие юникод должны получать баг с уровнем wishlist.
>
> Поправьте, если я не прав, но в lenny по-моему по-умолчанию
Alexey Pechnikov <[EMAIL PROTECTED]> wrote:
> Hello!
> В сообщении от Thursday 07 August 2008 19:03:54 Alexey Lobanov написал(а):
> > Ну не вижу никакой проблемы.
> >
> > Могу ещё подмонтировать бэкапный раздел, где есть директория с 35 000
> > файлами н
Hi
Alexey Pechnikov wrote:
> На мой взгляд, в дебиане должен быть пакет с
> поддержкой юникода, но это вопрос личных вкусов мантейнера, никакого policy
> на этот счет я не знаю.
...
> В общем бага нету, просто муть какая-то :-)
Дебиан официально поддерживает юникод ещё с sarge. Так что ещё с sa
chaos пишет:
Чиститься чем-то самописным? или есть есть что готовое в репозитории?
tmpreaper
--
DamirX
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
On Sat, Aug 09, 2008 at 05:55:11PM +0300, chaos wrote:
> В сообщении от 8 августа 2008 10:12 Dmitry Azhichakov написал(a):
> > У меня на основе atime по крону чистится ~/tmp помойка. Я к этому
> > жутко привык :)
>
> Чиститься чем-то самописным? или есть есть что готовое в репозитории?
Самописным
Alexey Pechnikov -> debian-russian@lists.debian.org @ Sat, 9 Aug 2008 12:33:42
+0400:
>> Что-то у меня на десктопе не дофига серверных программ... И ни одной
>> РСУБД, кстати. И я не вижу смысла оптимизировать на нем доступ к ФС.
>> Потому что оптимизацию надо начинать с самого узкого места
В сообщении от 8 августа 2008 10:12 Dmitry Azhichakov написал(a):
> On Thu, Aug 07, 2008 at 07:34:54PM +0400, Andrey Vasilenko wrote:
> > Если это нужно мэйнтайнерам
> > дистров, то они думаю уже собрали достаточно информации о популярности
> > тех или иных пакетов, а мне как-то и не
> > припомню к
Hello!
В сообщении от Saturday 09 August 2008 07:39:43 Artem Chuprina написал(а):
> Alexey Pechnikov -> debian-russian@lists.debian.org @ Sat, 9 Aug 2008
> 00:49:48 +0400:
>
> AP> Собственно, это как раз тот случай, когда ФС - отличная СУБД. Но я
> AP> много раз видел, как девелоперы пихают бол
Alexey Pechnikov -> debian-russian@lists.debian.org @ Sat, 9 Aug 2008 00:49:48
+0400:
AP> Собственно, это как раз тот случай, когда ФС - отличная СУБД. Но я
AP> много раз видел, как девелоперы пихают большое количество файлов в
AP> БД, мотивируя тем, что ФС, по их мнению, не умеет работать с
Murat D. Kadirov -> debian-russian@lists.debian.org @ Sat, 9 Aug 2008 04:35:47
+0600:
>> Он не то чтобы тормозить будет... Просто если сейчас типичный
>> десктоп 99% времени нифига не делает, то описанный тобой мегадесктоп
>> будет этого
MDK> Я, наверное, к словам придераюсь, но следя за т
23:59 Fri 08 Aug , Artem Chuprina написал:
> Он не то чтобы тормозить будет... Просто если сейчас типичный десктоп
> 99% времени нифига не делает, то описанный тобой мегадесктоп будет этого
Я, наверное, к словам придераюсь, но следя за трэдом эта цифра в 99% уже
звучала не раз. Года два тому
В сообщении от 8 августа 2008 16:44 Artem Chuprina написал(a):
> Это неверно. Чистить ~/tmp (нифига не включаемую в бэкап, поскольку она
> tmp по смыслу) по atime - самое оно. "Мужик, ты вот тут парочку типа
> временных файлов месяц не смотрел _никакой_ программой - они тебе точно
> нужны?" Или
Hello!
В сообщении от Friday 08 August 2008 23:59:12 Artem Chuprina написал(а):
> Кстати, к количеству файлов в директории имеет отношение скорее строение
> директории в файловой системе (directory index или сразу btree), нежели
> atime. atime тут как раз глубоко перпендикулярен.
Есть еще и dira
Dmitry Nezhevenko -> debian-russian@lists.debian.org @ Fri, 8 Aug 2008
22:50:00 +0300:
>> Современный десктоп/ноут обладают огромной вычислительной мощностью,
>> при грамотном использовании, а вот жесткий диск явно уступает, так
>> что полезны все средства, позволяющие оптимизировать операции
Alexey Pechnikov -> debian-russian@lists.debian.org @ Fri, 8 Aug 2008 23:06:25
+0400:
>> > Если вам безразлично, как эти опции скажутся на
>> > производительности, для вас нет необходимости отказываться от
>> > использования atime. Когда я планировал систему, эффективно
>> > работающую с мил
On Fri, Aug 08, 2008 at 11:06:25PM +0400, Alexey Pechnikov wrote:
>
> Современный десктоп/ноут обладают огромной вычислительной мощностью, при
> грамотном использовании, а вот жесткий диск явно уступает, так что полезны
> все средства, позволяющие оптимизировать операции доступа к файлам.
Чест
Hello!
> > Как показывает практика, и сервер и десктоп могут отлично жить с
> > отключенным atime. Если хотите использовать atime для файлов и директорий
> > - дело ваше, но вы за это платите определенным проигрышем в
> > производительности, величина которого зависит от ваших задач.
>
> Как миниму
On Fri, Aug 08, 2008 at 09:56:21PM +0400, Alexey Pechnikov wrote:
> > Автоматически удалять файл, который был создан год назад, но по каким либо
> > причинам используемый каждый день -- не совсем логично.
>
> Имхо, удалять вручную созданный файл автоматически - вообще не очень логично.
Когда я с
Alexey Pechnikov -> debian-russian@lists.debian.org @ Fri, 8 Aug 2008 21:56:21
+0400:
AP> директорий. Надеюсь, сказанное поможет топикстартеру эффективно настроить
AP> свою ФС.
Вряд ли. Поскольку под какие задачи, он не знает. Скорее всего, под
его задачи совершенно пофигу, как настраивать
от
использования atime. Когда я планировал систему, эффективно работающую с
миллионами файлов в директории (предупреждая возможные вопросы, замечу, что я
проверил работу ext3 на ноуте и сервере с директориями, содержащими многие
миллионы файлов, и результаты оказались прекрасными, при соответ
On Fri, Aug 08, 2008 at 07:10:24PM +0400, Alexey Pechnikov wrote:
>
> Если вы туда вручную их складываете, то логично вручную и удалять. Не говоря
> о
> том, что если вас интересуют файлы, созданные не более чем 2 дня назад, то
> atime как бы вовсе не причем, вы смотрите на время создания или м
Alexey Pechnikov -> debian-russian@lists.debian.org @ Fri, 8 Aug 2008 19:10:24
+0400:
>> 1. У меня /tmp на tmpfs
>> 2. Я предпочитаю делать hibernate.
>>
>> У меня привычка считать /tmp совсем временным хранилищем (которое
>> вообще не жалко потерять). А ~/tmp -- более постоянное. То есть
Hello!
В сообщении от Friday 08 August 2008 19:02:47 Dmitry Nezhevenko написал(а):
> 1. У меня /tmp на tmpfs
> 2. Я предпочитаю делать hibernate.
>
> У меня привычка считать /tmp совсем временным хранилищем (которое вообще
> не жалко потерять). А ~/tmp -- более постоянное. То есть файлы там в
> да
Результаты 1 - 100 из 417 matches
Mail list logo
