[Gllug] What are the best practices for Linux partitioning & Mount points for Production systems

John Hearns hearnsj at googlemail.com
Fri Mar 2 10:35:48 UTC 2012


nk.oorda - this stuff about the external sectors of a hard disk is all
well and good.
However, in these days you should not be planning partitions on disk
to put the most heavily accessed data there.

For a production system, specify a mirrored pair off system disks for
the / /usr /var  (etc. etc.) partitions

Put your  /work space on a SEPARATE set of RAID disks, on a RAID controller.
Remember - there are memory buffers in RAID controllers.
Either internal to the box, or if you have big data requirements on an
external array.
And as has been said above consider solid state drives.


On 02/03/2012, Andrew Farnsworth <farnsaw at stonedoor.com> wrote:
> I have not noticed a significant performance difference in disk access
> speeds relating to the external vs internal tracks on a platter.
>
> If you are this concerned about throughput you would be better off adding
> and SSD to your system and placing the most highly utilized files there.
>  For example, placing a DB on the SSD can show dramatic improvements in
> performance, just be aware of the limited life span of an SSD and keep your
> backups current.
>
> Andy
>
> On Fri, Mar 2, 2012 at 11:05 AM, nk oorda <nk.oorda at gmail.com> wrote:
>
>>
>>
>> On Fri, Mar 2, 2012 at 3:23 PM, Andrew Farnsworth
>> <farnsaw at stonedoor.com>wrote:
>>
>>> I'll Second this with one caveat.  If you are running an active system
>>> that is generating a lot of logs (read production public facing web/app
>>> server) then you might want a separate partition for /var/log and/or any
>>> other log directories that are in non-standard locations.  My experience
>>> is
>>> that invariably you will end up wanting more space for the logs or to
>>> tightly monitor disk space used by the logs and this makes both very
>>> simple.
>>>
>>> Andy
>>>
>>
>> Thanks Andy & Tet for the reply,
>>
>> I also have heard that data on the external part of a Hard Disk are faster
>> to access because external sectors have a bigger circumference than inner
>> sectors. so that also matters what sequence you are following for
>> partition.
>>
>> e.g
>>
>> When setting up partitions it is hence better to begin with the one
>> needing faster disk access, so that they will be located on the external
>> part of the disk.
>>
>> /boot
>> Swap
>> /
>> /var
>>
>> suggestions >?
>>
>>
>> --N
>>
>>
>>>
>>>
>>> On Fri, Mar 2, 2012 at 10:45 AM, Tethys <sta296 at astradyne.co.uk> wrote:
>>>
>>>>
>>>> nk oorda writes:
>>>>
>>>> >What are the best practices for Linux partitioning & Mount points for
>>>> >Production systems
>>>>
>>>> I generally go for:
>>>>
>>>> - /boot (ext3, about 1GB)
>>>> - /boot2 (ext3, about 1GB)
>>>> - LVM for the rest of the "disk" (which is usually an array
>>>>  rather than a single disk)
>>>>
>>>> The two /boot filesystems allow distribution upgrades with rollback.
>>>> LVM gives you the flexibility to do what you want with the rest.
>>>> It's less important than it used to be, and there's an argument for
>>>> just sticking the rest of the OS on a single filesystem, but personally
>>>> I still go for separate /usr, /tmp and /var. The latter two prevent the
>>>> system falling over as badly when a rogue process spams the disk with
>>>> crap, and I have a read only /usr (which I haven't managed to achieve
>>>> at boot time with bind mounts, despite the claims accompanying the
>>>> misguided removal of support for a separate /usr in recent Fedora
>>>> releases).
>>>>
>>>> Tet
>>>> --
>>>> Gllug mailing list  -  Gllug at gllug.org.uk
>>>> http://lists.gllug.org.uk/mailman/listinfo/gllug
>>>>
>>>
>>>
>>> --
>>> Gllug mailing list  -  Gllug at gllug.org.uk
>>> http://lists.gllug.org.uk/mailman/listinfo/gllug
>>>
>>>
>>
>> --
>> Gllug mailing list  -  Gllug at gllug.org.uk
>> http://lists.gllug.org.uk/mailman/listinfo/gllug
>>
>>
>
--
Gllug mailing list  -  Gllug at gllug.org.uk
http://lists.gllug.org.uk/mailman/listinfo/gllug




More information about the GLLUG mailing list