Re: Filesystem and Disk Partitioning for New Server Setup

An LVM gives you more options.

Without an LVM you would add a disk to the system, create a tablespace, and
then move some of your tables over to the new disk. Or, you'd take a full
backup, rebuild your file system, and then restore from backup onto the
newer, larger disk configuration. Or you'd make softlinks to pg_log or
pg_xlog or something to stick the extra disk in your system somehow.

You can do that with an LVM too. However, with an LVM you can add the disk
to the system, extend the file system, and just keep running. Live. No
need to figure out which tables or files should go where.

Sometimes it is really nice to have that option.

On Wed, Feb 24, 2016 at 9:25 AM, Dave Stibrany <dstibrany(at)gmail(dot)com> wrote:

> Thanks for the advice, Rick.
>
> I have an 8 disk chassis, so possible extension paths down the line are
> adding raid1 for WALs, adding another RAID10, or creating a 8 disk RAID10.
> Would LVM make this type of addition easier?
>
>
> On Wed, Feb 24, 2016 at 6:08 AM, Rick Otten <rottenwindfish(at)gmail(dot)com>
> wrote:
>
>>
>> 1) I'd go with xfs. zfs might be a good alternative, but the last time I
>> tried it, it was really unstable (on Linux). I may have gotten a lot
>> better, but xfs is a safe bet and well understood.
>>
>> 2) An LVM is just an extra couple of commands. These days that is not a
>> lot of complexity given what you gain. The main advantage is that you can
>> extend or grow the file system on the fly. Over the life of the database
>> it is quite possible you'll find yourself pressed for disk space - either
>> to drop in more csv files to load with the 'copy' command, to store more
>> logs (because you need to turn up logging verbosity, etc...), you need more
>> transaction logs live on the system, you need to take a quick database
>> dump, or simply you collect more data than you expected. It is not always
>> convenient to change the log location, or move tablespaces around to make
>> room. In the cloud you might provision more volumes and attach them to the
>> server. On a SAN you might attach more disk, and with a stand alone
>> server, you might stick more disks on the server. In all those scenarios,
>> being able to simply merge them into your existing volume can be really
>> handy.
>>
>> 3) The main advantage of partitioning a single volume (these days) is
>> simply that if one partition fills up, it doesn't impact the rest of the
>> system. Putting things that are likely to fill up the disk on their own
>> partition is generally a good practice. User home directories is one
>> example. System logs. That sort of thing. Isolating them on their own
>> partition will improve the long term reliability of your database. The
>> main disadvantage is those things get boxed into a much smaller amount of
>> space than they would normally have if they could share a partition with
>> the whole system.
>>
>>
>> On Tue, Feb 23, 2016 at 11:28 PM, dstibrany <dstibrany(at)gmail(dot)com> wrote:
>>
>>> I'm about to install a new production server and wanted some advice
>>> regarding
>>> filesystems and disk partitioning.
>>>
>>> The server is:
>>> - Dell PowerEdge R430
>>> - 1 x Intel Xeon E5-2620 2.4GHz
>>> - 32 GB RAM
>>> - 4 x 600GB 10k SAS
>>> - PERC H730P Raid Controller with 2GB cache
>>>
>>> The drives will be set up in one RAID-10 volume and I'll be installing
>>> Ubuntu 14.04 LTS as the OS. The server will be dedicated to running
>>> PostgreSQL.
>>>
>>> I'm trying to decide:
>>>
>>> 1) Which filesystem to use (most people seem to suggest xfs).
>>> 2) Whether to use LVM (I'm leaning against it because it seems like it
>>> adds
>>> additional complexity).
>>> 3) How to partition the volume. Should I just create one partition on /
>>> and
>>> create a 16-32GB swap partition? Any reason to get fancy with additional
>>> partitions given it's all on one volume?
>>>
>>> I'd like to keep things simple to start, but not shoot myself in the
>>> foot at
>>> the same time.
>>>
>>> Thanks!
>>>
>>> Dave
>>>
>>>
>>>
>>> --
>>> View this message in context:
>>> http://postgresql.nabble.com/Filesystem-and-Disk-Partitioning-for-New-Server-Setup-tp5889074.html
>>> Sent from the PostgreSQL - performance mailing list archive at
>>> Nabble.com.
>>>
>>>
>>> --
>>> Sent via pgsql-performance mailing list (
>>> pgsql-performance(at)postgresql(dot)org)
>>> To make changes to your subscription:
>>> http://www.postgresql.org/mailpref/pgsql-performance
>>>
>>
>>
>>
>
>
> --
> *THIS IS A TEST*
>