[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: regards the /



On Thu, 22 Sep 2011 09:06:07 -0500, Stan Hoeppner wrote:

> On 9/21/2011 10:43 AM, Camaleón wrote:
> 
>> ...in my case, was
>> flooding the "/var/log/syslog" file. Then it's too late and your system
>> may become unstable and slow meaning that you are royaly hosed :-)
> 
> Which is why every old school Unix guru (and younger smart ones as well)
> will tell you to put /var on a separate filesystem (partition), and
> better yet on a separate physical device.  

Fair enough with some "buts".

> The first protects against a single full filesystem taking the system
> down.  

When you have a hard disk of 8 GiB (and you have installed a full DE plus 
1GiB for swap) you have not much room to make such experiments. When disk 
space is a constraint, your "/var" partition, whatever it is located, can 
be easily flooded in the same way.

The above experience I posted it happened on a VM I have to run testing 
for well... "testing" purposes. I wanted to try something (don't remember 
exactly what, either "hibernation" or "suspension") and something went 
wrong so one of the logs was being flooded with errors. The experiment 
(suspension or hibernation) did not succeed and after a hard reset, once 
a I logged I received a message popup stating that fact, then issued "df -
h" to check, went to /var/log and saw the big file. I deleted and all 
were happy again.

> The second does the same and also makes sure all log related
> disk bandwidth is on a separate spindle, thus avoiding the performance
> degradation when a runaway process spams the log file with dozens or
> hundreds of IOs per second. Note that 7.2k SATA drives can only tackle
> about 150 IOPS.  5.2k laptop drives about 100.

Can you imagine any real performance gain with that setup on a VM machine 
that runs over an emulated Pentium M (486, no smp) with 1.5 GiB of RAM 
and using a virtual hard disk controller?

That's true for certain environments but it can pass unnoticed on others.

> Even low end SSD can do 2500 IOPS, 15x that of a 7.2k drive.  And most
> SSDs are small.  So if you have an SSD in this runaway logging scenario
> you could potentially fill the log filesystem in a matter of minutes.
> 
> Moral of the story:  Keep /var/log on a separate filesystem for laptops
> and desktops.  Keep it on a separate physical device on servers.  With a
> RAID setup, a separate partition on the LUN/virtual disk serves the same
> purpose.  Unrelated to this particular problem, but valuable knowledge
> nonetheless, is to have a boot partition separate from the / partition
> as well.

I'm afraid you ask for too much :-)
 
> Ease of use and "Linux on every desktop" proponents evangelize using a
> single partition/filesystem, which is the default Microsoft setup BTW,
> so it's simpler for the non technical user, though inherently less safe.

I see disk partitioning as a thing of the past. I would prefer using a 
flexible volume manager (such LVM or volume "spanning") although I have 
to add an additional layer of complexity. While I agree that 2 TiB for a 
single partition is not desiderable for small amounts (<500 GiB) is not 
that bad if you take additional precautions (backups, raid and secondary 
disks you can use to quickly add more space if needed).

>   Those who have used *nix for a while, especially server
> administrators, who have seen problems like this first hand, evangelize
> separate partitions/filesystems for reliability, resiliency, and
> recovery.

(...)

Yes, that's what I've heard and read everywhere (manuals, faqs, technical 
books, speciallized sites...), and not only for linux based systems but 
also for windows.
 
Greetings,

-- 
Camaleón


Reply to: