From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Date: Mon, 10 Jan 2005 19:10:17 +0300 From: Denis Smirnov To: community@altlinux.ru Subject: Re: [Comm] Re: =?koi8-r?B?6SDF3cUg18/Q0s/T?= =?koi8-r?B?INDSzw==?= lvm Message-ID: <20050110161017.GC25655@mithraen.dimline.ru> Mail-Followup-To: Denis Smirnov , community@altlinux.ru References: <41D43E5D.10703@list.ru> <20050109190331.GW24515@osdn.org.ua> <20050110090609.GA7535@mithraen.dimline.ru> <200501101754.59139.dead-md@yandex.ru> Mime-Version: 1.0 Content-Type: text/plain; charset=koi8-r Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <200501101754.59139.dead-md@yandex.ru> X-BeenThere: community@altlinux.ru X-Mailman-Version: 2.1.5 Precedence: list Reply-To: community@altlinux.ru List-Id: Mailing list for ALT Linux users List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 10 Jan 2005 16:10:18 -0000 Archived-At: List-Archive: List-Post: On Mon, Jan 10, 2005 at 05:54:58PM +0300, dm wrote: >> swap, IMHO, вполне разумно >> делать на LVM (в том числе и потому что можно поправить swapd >> на создание не файликов а разделов). d> А вот тут мы с Вами не совпадаем :-) d> ИМХО, свап (по крайней мере, основной) можно, но _не_разумно_ d> делать на LVM, по двум причинам: d> 1) Это совершенно лишние тормоза. d> 2) В этом практически не бывает реальной необходимости. Размер d> основного свап-раздела обычно не бывает смысла менять, да и не d> расширишь его особенно, предел размера, насколько я понимаю, d> никто не отменял. d> Если вдруг возникает необходимость увеличить свап на работающей d> системе без пустого места на дисках, естественно, это можно d> сделать и на LVM, причём кучей способов, но рекомендовать свап d> на LVM как типичное решение я бы поостерёгся. С первым пунктом соглашусь, со вторым нет. Ибо причины на создание всяких swapd были и есть. >> Насколько я понимаю, >> никаких проблем с корнем на LVM быть не должно (хотя сам не >> пробовал). d> Проблемы появятся сразу, как только из-за любых неполадок d> придётся грузить систему со спасательного сидюка, в котором нет d> поддержки LVM в ядре и/или соответствующих файлов в initrd. При d> том, что вероятность гибели корня из-за физической аварии d> какого-либо из дисков повышается. Вы знаете, как lvm распихает d> по физическим томам файлы корневой ФС и какие из них умрут, если d> данный конкретный диск вылетит? Я -- нет. Это раз. Но это так, d> из области маловероятных опасений. Насчёт физических томов -- я это воспринимаю, скорее как возможность облегчить переезд на новые диски. Потому как не считаю разумным использовать LVM как "нечто RAID-0 подобное". И в многодисковых конфигурациях считаю разумным иметь две группы, и систему держать в одной из них. d> А два, что гораздо важнее -- пихать корень на LVM нет смысла -- d> его размер крайне невелик, хорошо предсказуем, постоянен для d> одного дистрибутива и не меняется при установке прикладного d> софта. Если бы не менялся. Вон у нас /etc сейчас почти полсотни метров. gconf'ы всякие место десятками мегабайт едят :-))) А если совсем серьёзно -- соглашусь. Лучше сделать просто корень метров 200 и не парить себе мозги и не придумывать геморрой. -- С уважением, Денис http://freesource.info