John Hearns | 1 Mar 12:17 2012

Guardian editorial on Raspberry Pi

http://www.guardian.co.uk/commentisfree/2012/mar/01/raspberry-pi-computing-under-bonnet

"As for software, no one, no matter how bright, can flower into a
boffin without the chance to tinker around with code. Proprietary
platforms like Windows make that difficult – the bonnet is welded shut
– so the Pi will run on open-source Linux."
--
Gllug mailing list  -  Gllug <at> gllug.org.uk
http://lists.gllug.org.uk/mailman/listinfo/gllug

nk oorda | 2 Mar 10:04 2012
Picon

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

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

 

Hi

i need some suggestion for defining the partition size for my production systems.  we are going to use CentOS 6.2 (64 bit)

- Partition size
- Mount points

What i am able to get from the google search is:

/            Root File System (/bin , /sbin , /dev , /root
/usr       program and source code                                                      
/var        variable data
/boot     boot kernels
/tmp      temp file locations
/work     to do your work here "you can name it anything"
Swap

  • /home - Set option nosuid, and nodev with diskquota option
  • /usr - Set option nodev
  • /tmp - Set option nodev, nosuid, noexec option must be enabled
  • /var   local,nodev,nosuid


Most of the server will be running
- Apache
-Tomcat
-SOLR

and few of them would be running MySQL as data base.


what is concern is that one of the developer accidentally deleted the /usr files with sudo access. if somehow i can protect the core system from the developers mistake that would be really good.

Thanks in advance for help.

--
Gllug mailing list  -  Gllug <at> gllug.org.uk
http://lists.gllug.org.uk/mailman/listinfo/gllug
Tethys | 2 Mar 10:45 2012
X-Face
Picon

Re: What are the best practices for Linux partitioning & Mount points for Production systems


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

Andrew Farnsworth | 2 Mar 10:53 2012

Re: What are the best practices for Linux partitioning & Mount points for Production systems

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

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
nk oorda | 2 Mar 11:05 2012
Picon

Re: What are the best practices for Linux partitioning & Mount points for Production systems



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
Andrew Farnsworth | 2 Mar 11:14 2012

Re: What are the best practices for Linux partitioning & Mount points for Production systems

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
John Hearns | 2 Mar 11:35 2012

Re: What are the best practices for Linux partitioning & Mount points for Production systems

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

nk oorda | 2 Mar 11:42 2012
Picon

Re: What are the best practices for Linux partitioning & Mount points for Production systems



On Fri, Mar 2, 2012 at 4:05 PM, John Hearns <hearnsj <at> googlemail.com> wrote:
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.



Thanks John
yes we do  have SSD disk and /work is mounted on that. we are really getting good performance number  for our indexing server which is running on SOLR.

so is
/
/boot
/usr
/var
/work

is a good scheme to go with right.....i am also interesting to know about the mount arguments.
thanks again.

--N


 
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

--
Gllug mailing list  -  Gllug <at> gllug.org.uk
http://lists.gllug.org.uk/mailman/listinfo/gllug
t.clarke | 2 Mar 11:08 2012
Picon

Re: What are the best practices for Linux partitioning & Mount

With regard to disc partitioning, something else to consider when creating
partitions is what you are going to put on them....

For example, if you have a lot of important data that changes very dynamically,
then despite having RAID of one sort or another you really need to back that
data up frequently to other media,  be it CD, DVD, external usb disc, tape,
whatever.

Having that data on a separate filesystem can speed up the time taken to
backup considerably,  especially if you do a partition-image copy using dd

Tim
--
Gllug mailing list  -  Gllug <at> gllug.org.uk
http://lists.gllug.org.uk/mailman/listinfo/gllug

nk oorda | 2 Mar 12:12 2012
Picon

Re: What are the best practices for Linux partitioning & Mount



On Fri, Mar 2, 2012 at 3:38 PM, t.clarke <tim <at> seacon.co.uk> wrote:
With regard to disc partitioning, something else to consider when creating
partitions is what you are going to put on them....

For example, if you have a lot of important data that changes very dynamically,
then despite having RAID of one sort or another you really need to back that
data up frequently to other media,  be it CD, DVD, external usb disc, tape,
whatever.

Having that data on a separate filesystem can speed up the time taken to
backup considerably,  especially if you do a partition-image copy using dd

Tim
--


Thanks Tim

Most of the servers are web server having apache/tomcat running.
all of our hardware is with RAID 5 configured.

--N
--
Gllug mailing list  -  Gllug <at> gllug.org.uk
http://lists.gllug.org.uk/mailman/listinfo/gllug

Gmane