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

[nk oorda]

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
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.lug.org.uk/pipermail/gllug/attachments/20120302/3603b959/attachment.html>
-------------- next part --------------
--
Gllug mailing list  -  Gllug at gllug.org.uk
http://lists.gllug.org.uk/mailman/listinfo/gllug