From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Message-ID: <4252553A.8000905@freesource.info> Date: Tue, 05 Apr 2005 13:07:06 +0400 From: Denis Smirnov User-Agent: Mozilla Thunderbird 1.0 (X11/20050202) X-Accept-Language: en-us, en MIME-Version: 1.0 To: led@ukr-fin.com.ua Subject: Re: [sisyphus] e2compr References: <200503171507.55580.led@ukr-fin.com.ua> <200504041133.27942.led@ukr-fin.com.ua> <20050404172206.GA12379@mithraen.dimline.ru> <200504042036.28303.led@ukr-fin.com.ua> In-Reply-To: <200504042036.28303.led@ukr-fin.com.ua> Content-Type: text/plain; charset=KOI8-R; format=flowed Content-Transfer-Encoding: 8bit Cc: sisyphus@altlinux.ru X-BeenThere: sisyphus@altlinux.ru X-Mailman-Version: 2.1.5 Precedence: list Reply-To: ALT Linux Sisyphus discussion list List-Id: ALT Linux Sisyphus discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 05 Apr 2005 09:06:20 -0000 Archived-At: List-Archive: Led wrote: >>>>Но как ни >>>>крути, а если есть ценные данные, именно их -- на отдельный ext3 раздел. >>>> >>>> >>L> Ценные данные - на любой раздел, и регулярные бекапы, в том числе и на >>внешние L> носители:) >> >>Как я уже говорил, это никак не связано. Наличие бэкапа не освобождает от >>необходимости уменьшать вероятность необходимости им воспользоваться. >> >> > >Без комментариев (здесь тот случай, когда вы правы потому как хотите им быть и >никакаие аргументы мои не помогут:)) > > Бр-р-р-р. Вы действительно не согласны с тем, что _и_ бэкап обязателен, _и_ вся система хранения данных должна быть надёжна? И что бэкап это на критический случай, возникновение которого во многих случаях уже есть повод дать админу пяткой в лоб (ибо простой на время развёртывания бэкапа, а также потеря данных, который пришли со времени последнего backup'а могут быть важными?). Я делаю ежедневные backup'ы. Но при этом понимаю, что потеря одного письма по e-mail'у может мне стоить живых денег. Сравнимых со стоимостью пары новых хардов. Поэтому я никогда не восприму "должен быть backup" как агрумент в споре касаемо файловых систем, и совсем не понимаю зачем вы его сюда приплетаете. >>>>Если есть мультимедиа, то xfs с большими файлами ведёт себя получше. >>>> >>>> >>L> Для больших файлов журналируемость ФС ИМХО вобще бесполезна:) >> >>Зато XFS с ними действительно работает быстро и эффективно. >> >> > >Быстро и эффективно обрабатываются большие файлы, если они не >фрагментированны. Вы хотите сказать, что по какой-то причине XFS значительно >меньше их фрагментирует? Сорри, но позвольте мне не поверить Вам:) > > А вы подумайте, почему журналируемость может заметно уменьшить фрагментацию файловой системы, если она сделана с умом (а XFS сделана с умом). И вы сразу поймёте бредовость вашей мысли о бесполезности журналируемости для больших файлов. Hint: XFS умеет выполнять размещение файла не в момент его создания (вызова creat), а сильно, сильно позже. А именно в тот момент, когда первый блок будет сбрасываться на диск. ..Есть ещё одна фишка, не знаю реализована ли она в XFS, но >>>>Хочу напомнить, что в 2.6 ext3/ext2 умеют быстро работать с каталоги где >>>>множество файлов, если вспомнить про tunefs -O dir_index. >>>> >>>> >>L> Как давно 2.6 стало (и стала ли) повсеместно ставиться на сервера? >> >>Кое-где уже начала. >> >> > >"Кое-где" и "уже начала" - это ещё не повод говорить об "опыте эксплуатации", >не находите?:) > > Прошло достаточно времени с выпуска 2.6.0, чтобы считать по крайней мере эту фичу стабильной. Благо в неё уже давно никто модификаций не вносил. А опыта эксплуатации reiserfs нет ни у кого вообще -- потому что он непрерывно разрабатывается. И заведомо отлаженого долгоживущего кода нет. Так что это тоже не аргумент. >А кто-то помнит ещё такой прикол где-то год назад, когда xine стартовал фильм >около 30 секунд на ext3 и почти мгновенно на reiserfs?:) Потом вроде >исправили в xine этот прикол:) До сих пор не догадываюсь, в чём была >заморочка, но была, проверялась на разных машинах, почитателями ext3. > > Увы, не слышал. Буду рад точной ссылке.