<br><br><div class="gmail_quote">On Fri, Mar 2, 2012 at 4:05 PM, John Hearns <span dir="ltr"><<a href="mailto:hearnsj@googlemail.com">hearnsj@googlemail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
nk.oorda - this stuff about the external sectors of a hard disk is all<br>
well and good.<br>
However, in these days you should not be planning partitions on disk<br>
to put the most heavily accessed data there.<br>
<br>
For a production system, specify a mirrored pair off system disks for<br>
the / /usr /var  (etc. etc.) partitions<br>
<br>
Put your  /work space on a SEPARATE set of RAID disks, on a RAID controller.<br>
Remember - there are memory buffers in RAID controllers.<br>
Either internal to the box, or if you have big data requirements on an<br>
external array.<br>
And as has been said above consider solid state drives.<br>
<div class="HOEnZb"><div class="h5"><br>
<br> </div></div></blockquote><div class="h5"><br>Thanks John <br></div><div>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.<br>
<br>so is <br>/<br>/boot<br>/usr<br>/var<br>/work <br><br>is a good scheme to go with right.....i am also interesting to know about the mount arguments.<br>thanks again.<br><br>--N<br></div><div><br><br> </div><blockquote class="gmail_quote" style="margin:0pt 0pt 0pt 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
<div class="HOEnZb"><div class="h5">
On 02/03/2012, Andrew Farnsworth <<a href="mailto:farnsaw@stonedoor.com">farnsaw@stonedoor.com</a>> wrote:<br>
> I have not noticed a significant performance difference in disk access<br>
> speeds relating to the external vs internal tracks on a platter.<br>
><br>
> If you are this concerned about throughput you would be better off adding<br>
> and SSD to your system and placing the most highly utilized files there.<br>
>  For example, placing a DB on the SSD can show dramatic improvements in<br>
> performance, just be aware of the limited life span of an SSD and keep your<br>
> backups current.<br>
><br>
> Andy<br>
><br>
> On Fri, Mar 2, 2012 at 11:05 AM, nk oorda <<a href="mailto:nk.oorda@gmail.com">nk.oorda@gmail.com</a>> wrote:<br>
><br>
>><br>
>><br>
>> On Fri, Mar 2, 2012 at 3:23 PM, Andrew Farnsworth<br>
>> <<a href="mailto:farnsaw@stonedoor.com">farnsaw@stonedoor.com</a>>wrote:<br>
>><br>
>>> I'll Second this with one caveat.  If you are running an active system<br>
>>> that is generating a lot of logs (read production public facing web/app<br>
>>> server) then you might want a separate partition for /var/log and/or any<br>
>>> other log directories that are in non-standard locations.  My experience<br>
>>> is<br>
>>> that invariably you will end up wanting more space for the logs or to<br>
>>> tightly monitor disk space used by the logs and this makes both very<br>
>>> simple.<br>
>>><br>
>>> Andy<br>
>>><br>
>><br>
>> Thanks Andy & Tet for the reply,<br>
>><br>
>> I also have heard that data on the external part of a Hard Disk are faster<br>
>> to access because external sectors have a bigger circumference than inner<br>
>> sectors. so that also matters what sequence you are following for<br>
>> partition.<br>
>><br>
>> e.g<br>
>><br>
>> When setting up partitions it is hence better to begin with the one<br>
>> needing faster disk access, so that they will be located on the external<br>
>> part of the disk.<br>
>><br>
>> /boot<br>
>> Swap<br>
>> /<br>
>> /var<br>
>><br>
>> suggestions >?<br>
>><br>
>><br>
>> --N<br>
>><br>
>><br>
>>><br>
>>><br>
>>> On Fri, Mar 2, 2012 at 10:45 AM, Tethys <<a href="mailto:sta296@astradyne.co.uk">sta296@astradyne.co.uk</a>> wrote:<br>
>>><br>
>>>><br>
>>>> nk oorda writes:<br>
>>>><br>
>>>> >What are the best practices for Linux partitioning & Mount points for<br>
>>>> >Production systems<br>
>>>><br>
>>>> I generally go for:<br>
>>>><br>
>>>> - /boot (ext3, about 1GB)<br>
>>>> - /boot2 (ext3, about 1GB)<br>
>>>> - LVM for the rest of the "disk" (which is usually an array<br>
>>>>  rather than a single disk)<br>
>>>><br>
>>>> The two /boot filesystems allow distribution upgrades with rollback.<br>
>>>> LVM gives you the flexibility to do what you want with the rest.<br>
>>>> It's less important than it used to be, and there's an argument for<br>
>>>> just sticking the rest of the OS on a single filesystem, but personally<br>
>>>> I still go for separate /usr, /tmp and /var. The latter two prevent the<br>
>>>> system falling over as badly when a rogue process spams the disk with<br>
>>>> crap, and I have a read only /usr (which I haven't managed to achieve<br>
>>>> at boot time with bind mounts, despite the claims accompanying the<br>
>>>> misguided removal of support for a separate /usr in recent Fedora<br>
>>>> releases).<br>
>>>><br>
>>>> Tet<br>
>>>> --<br>
>>>> Gllug mailing list  -  <a href="mailto:Gllug@gllug.org.uk">Gllug@gllug.org.uk</a><br>
>>>> <a href="http://lists.gllug.org.uk/mailman/listinfo/gllug" target="_blank">http://lists.gllug.org.uk/mailman/listinfo/gllug</a><br>
>>>><br>
>>><br>
>>><br>
>>> --<br>
>>> Gllug mailing list  -  <a href="mailto:Gllug@gllug.org.uk">Gllug@gllug.org.uk</a><br>
>>> <a href="http://lists.gllug.org.uk/mailman/listinfo/gllug" target="_blank">http://lists.gllug.org.uk/mailman/listinfo/gllug</a><br>
>>><br>
>>><br>
>><br>
>> --<br>
>> Gllug mailing list  -  <a href="mailto:Gllug@gllug.org.uk">Gllug@gllug.org.uk</a><br>
>> <a href="http://lists.gllug.org.uk/mailman/listinfo/gllug" target="_blank">http://lists.gllug.org.uk/mailman/listinfo/gllug</a><br>
>><br>
>><br>
><br>
--<br>
Gllug mailing list  -  <a href="mailto:Gllug@gllug.org.uk">Gllug@gllug.org.uk</a><br>
<a href="http://lists.gllug.org.uk/mailman/listinfo/gllug" target="_blank">http://lists.gllug.org.uk/mailman/listinfo/gllug</a><br>
</div></div></blockquote></div><br>