On Wed, January 29, 2014 11:57, Lists wrote: > On 01/29/2014 08:15 AM, Matt wrote: >> If I am putting both 4TB drives in a single RAID1 array for /vz would >> there be any advantage to using LVM on it? > > My (sometimes unpopular) advice is to set up the partitions on servers > into two categories: > > 1) OS > 2) Data > > OS partitions don't really grow much. Most of our servers' OS partitions > total less than 10 GB of used space after years of 24x7 use. I recommend > keeping things *very* *simple* here, avoid LVM. I use simple software > RAID1 with bare partitions. > > Data partitions, by definition, would be much more flexible. As your > service becomes more popular, you can get caught in a double bind that > can be very hard to escape: On one hand, you need to add capacity > without causing downtime because people are *using* your service > extensively, but on the other hand you can't easily handle a day or so > to transfer TBs of data because people are *relying* on your service > extensively. To handle these cases you need something that gives you the > ability to add capacity without (much) downtime. > > LVM can be very useful here, because you can add/upgrade storage without > taking the system offline, and although there *is* some downtime when > you have to grow the filesystem (EG when using Ext* file systems) it's > pretty minimal. > > So I would strongly recommend using something to manage large amounts of > data with minimal downtime if/when that becomes a likely scenario. > > Comparing LVM+XFS to ZFS, ZFS wins IMHO. You get all the benefits of LVM > and the file system, along with the almost magical properties that you > can get when you combine them into a single, integrated whole. Some of > ZFS' data integrity features (See RAIDZ) are in "you can do that?" > territory. The main downsides are the slightly higher risk that ZFS on > Linux' "non-native" status can cause problems, though in my case, that's > no worry since we'll be testing any updates carefully prior to roll out. > > In any event, realize that any solution like this (LVM + XFS/Ext, ZFS, > or BTRFS) will have a significant learning curve. Give yourself *time* > to understand exactly what you're working with, and use that time > carefully. Our default partitioning scheme for new hosts, whether virtualised or not, looks something like this: df Filesystem 1K-blocks Used Available Use% Mounted on /dev/mapper/vg_inet01b-lv_root 8063408 1811192 5842616 24% / tmpfs 1961368 0 1961368 0% /dev/shm /dev/vda1 495844 118294 351950 26% /boot /dev/mapper/vg_inet01b-lv_tmp 1007896 51800 904896 6% /tmp /dev/mapper/vg_inet01b-lv_log 1007896 45084 911612 5% /var/log /dev/mapper/vg_inet01b-lv_spool 8063408 150488 7503320 2% /var/spool The capacities assigned initially vary based on expected need and available disk. As everything is an lv expanding volume sizes when required is not exceedingly burdensome. I used to keep / as a non-lv but for the past few years, since CentOS-5 I think, I have made that an lv as well and my experience to date has been positive. Anything expected to continually increase over time goes under /var as a new lv. For example: On systems with business applications that store transaction files we have a dedicated lv mounted at /var/data/appname (for web apps) or /var/spool/appname (for everything else). On a system hosting an RDBMS we generally give /var/lib or var/lib/dbmsname its own lv although on the dedicated dbms hosts we typically just mount all of /var as an lv. This is based on past experience, usually bad, where the root file-system became filled by unmanaged processes (lack of trimming stale files), or DOS attacks (log files generally), or unexpectedly large transaction volumes (/var/spool). As all but one of our hosts have no local users besides administrative accounts /home is left in root. On the remaining host that has local user accounts /home is an lv as well. -- *** E-Mail is NOT a SECURE channel *** James B. Byrne mailto:ByrneJB at Harte-Lyne.ca Harte & Lyne Limited http://www.harte-lyne.ca 9 Brockley Drive vox: +1 905 561 1241 Hamilton, Ontario fax: +1 905 561 0757 Canada L8E 3C3