df incorrectly reports 100% usage after power down

df incorrectly reports 100% usage after power down

Post by Pierre Roya » Thu, 22 May 2003 08:40:00



My system has restarted after a power failure. Now df reports no free disk
space and 100% usage even if it does have space. I ran e2fsck without any
success. Sendmail cannot start because it does not have free space and I
cannot put a file by ftp to the system. I can however write to the disk.

Do I have to repartition and format the disk to fix it? I also tried
e2fsck -b 8193 . That did not work neither.

Pierre Royal

 
 
 

df incorrectly reports 100% usage after power down

Post by Peter T. Breue » Thu, 22 May 2003 08:42:38



> My system has restarted after a power failure. Now df reports no free disk
> space and 100% usage even if it does have space. I ran e2fsck without any
> success. Sendmail cannot start because it does not have free space and I
> cannot put a file by ftp to the system. I can however write to the disk.

Show us the output of df and du (appropriately selected)! Don't
interpret! To me it sounds as though nothing is wrong except possibly
your own hysteria, so calm down and show data ...

Peter

 
 
 

df incorrectly reports 100% usage after power down

Post by Pierre Roya » Thu, 22 May 2003 10:30:16




>> My system has restarted after a power failure. Now df reports no free
>> disk space and 100% usage even if it does have space. I ran e2fsck
>> without any success. Sendmail cannot start because it does not have free
>> space and I cannot put a file by ftp to the system. I can however write
>> to the disk.

> Show us the output of df and du (appropriately selected)! Don't interpret!
> To me it sounds as though nothing is wrong except possibly your own
> hysteria, so calm down and show data ...

> Peter

Here are the outputs:

# df
Filesystem           1k-blocks      Used Available Use% Mounted on
/dev/hda1               896280    853660         0 100% /

# du -s
853552  .

# ps ax
--- cut ---
 1423 ?        S      0:00 sendmail: rejecting connections on port 25: min free: 100
--- cut ---

 
 
 

df incorrectly reports 100% usage after power down

Post by Eric Moor » Thu, 22 May 2003 14:56:08





>>> My system has restarted after a power failure. Now df reports no free
>>> disk space and 100% usage even if it does have space. I ran e2fsck
>>> without any success. Sendmail cannot start because it does not have
>>> free space and I cannot put a file by ftp to the system. I can however
>>> write to the disk.

>> Show us the output of df and du (appropriately selected)! Don't
>> interpret! To me it sounds as though nothing is wrong except possibly
>> your own hysteria, so calm down and show data ...

>> Peter

> Here are the outputs:

> # df
> Filesystem           1k-blocks      Used Available Use% Mounted on
> /dev/hda1               896280    853660         0 100% /

it's filled up to 100%. Ther remainder of the free space is reserved
for root, mortal users are not allowed to fill it. remove the stuff you
don't need. Check /var and /tmp for big logs.

Eric

 
 
 

df incorrectly reports 100% usage after power down

Post by Peter T. Breue » Thu, 22 May 2003 19:03:33





>>> My system has restarted after a power failure. Now df reports no free
>>> disk space and 100% usage even if it does have space. I ran e2fsck
>>> without any success. Sendmail cannot start because it does not have free
>>> space and I cannot put a file by ftp to the system. I can however write
>>> to the disk.

>> Show us the output of df and du (appropriately selected)! Don't interpret!
>> To me it sounds as though nothing is wrong except possibly your own
>> hysteria, so calm down and show data ...
> Here are the outputs:
> # df
> Filesystem           1k-blocks      Used Available Use% Mounted on
> /dev/hda1               896280    853660         0 100% /
> # du -s
> 853552     .

This is fine. Your root is full. Delete something. There is no
discrepancy - the df report shows the space available to non-root
users. Situation normal.

Quote:> # ps ax
> --- cut ---
>  1423 ?        S      0:00 sendmail: rejecting connections on port 25: min free: 100
> --- cut ---

And not surprising.  Please go to a "decent" partition layout, with
nothing in the root file system except /bin /etc /lib /sbin /boot and
/root.  /var and /tmp and /usr should or could be elsewhere.

Peter

 
 
 

df incorrectly reports 100% usage after power down

Post by n.. » Fri, 23 May 2003 19:03:06


Quote:> # df
> Filesystem           1k-blocks      Used Available Use% Mounted on
> /dev/hda1               896280    853660         0 100% /


Quote:> And not surprising.  Please go to a "decent" partition layout, with
> nothing in the root file system except /bin /etc /lib /sbin /boot and
> /root.  /var and /tmp and /usr should or could be elsewhere.

How would that help? If the OP's only got 8Gb then s/he's only got
8Gb. Changing the partition layout would, if anything, reduce the usability
of that space (as one could then end up with space being on the "wrong" partition), and so the disk full situation would happen sooner.

The only useful two possibilities here are (a) delete some files, (b)
install another disk.

Chris

until$s[$i];$c=$s[$i];print$c;undef$s[$i];$i=($i+(ord$c))%$l}

 
 
 

df incorrectly reports 100% usage after power down

Post by Peter T. Breue » Fri, 23 May 2003 19:14:17



>> # df
>> Filesystem           1k-blocks      Used Available Use% Mounted on
>> /dev/hda1               896280    853660         0 100% /

>> And not surprising.  Please go to a "decent" partition layout, with
>> nothing in the root file system except /bin /etc /lib /sbin /boot and
>> /root.  /var and /tmp and /usr should or could be elsewhere.
> How would that help? If the OP's only got 8Gb then s/he's only got

It would stop his whatever writing in the root partition, and hence
leave the root partition comfortably empty.

Quote:> 8Gb. Changing the partition layout would, if anything, reduce the usability
> of that space (as one could then end up with space being on the "wrong" partition), and so the disk full situation would happen sooner.

Nonsense. Where do you get this logic from? I suppose you think that
leaving the toilet door open to the whole house won't stink the whole
house out? Great idea .. let the effluent overflow to the whole house
and therefore there's no overflow problem because there is more room
for the effluent and hence it's better!

Quote:> The only useful two possibilities here are (a) delete some files, (b)
> install another disk.

Nonsense.

Peter

 
 
 

df incorrectly reports 100% usage after power down

Post by Tobias Bro » Fri, 23 May 2003 21:27:23



(OP: sendmail won't accept mail - no disk space)

Quote:> And not surprising.  Please go to a "decent" partition layout, with
> nothing in the root file system except /bin /etc /lib /sbin /boot and
> /root.  /var and /tmp and /usr should or could be elsewhere.

The problem would generally not have been solved this way.  If we
disregard the possibility that the system administrator accidentally
would fill the disk, the /var-partition usually is the first one to go
full.  

I've written some scripts that do the logrotating and "cleaning" of
old temporary files, etc, only when the hard disk space is running low
(and the scripts will do this ever more strictly and start sending
emails when the hard disk space is really low); this is an elegant
solution I think.  Resource management can also be done through the
kernel by setting limits and quotas.  But I digress..

I used to do such partitionating before, but I've always regretted it.

Harddisk partitions are very inflexible, almost always there will be a
lot of free space at some of the partitions, and too little at others.
Then, eventually, the only easy way to "adjust" the limits is to move
some files forth and back across the partition boundaries.  That's not
elegant, it's not the Right thing to do, and it does require a lot of
work.  By now I think one big partition is best - unless there are
some specific needs or reasons for doing otherwise.

If having a network with several Linux (or Unix) boxes, particularly
if running a homogenous environment, I'd recommend having /usr at a
separate partition at _one_ of the computers, and mount it up through
nfs at the other computers.  A separate partition here is quite
important because there is no real access control in the NFS server,
and because this partition should be mounted read-only when not
installing new software.  A lot of disk space can be saved this way,
and the speed hit is not that big at a regular 100Mbps network.  It's
not that many years ago we were running a big computer lab with only
totally diskless computers at a 10Mbps network at my university -
unfortunately this is "out of fashion" by now.

Another thing that might defend a partitionating if taking backup of
whole partitions; this might be a smart thing to do if it's important
to get the box quickly up again after a hard disk crash or whatever.
Certainly, partitions like /usr and / shouldn't need frequent backups
with the scheme suggested above, while /home and /var probably does ..
and /tmp/ probably wouldn't need backup at all.

--
Check our new Mobster game at http://hstudd.cs.uit.no/mobster/
(web game, updates every 4th hour, no payment, no commercials)

 
 
 

df incorrectly reports 100% usage after power down

Post by Tobias Bro » Fri, 23 May 2003 21:39:47



Quote:> Nonsense. Where do you get this logic from? I suppose you think that
> leaving the toilet door open to the whole house won't stink the whole
> house out? Great idea .. let the effluent overflow to the whole house
> and therefore there's no overflow problem because there is more room
> for the effluent and hence it's better!

There are two possible problems;

a) the disk gets filled up with "rubbish".  This might be because of
overflooding log files, software bug producing i.e. temporary files at
a great speed, unaware users, malicious users, etc.

b) the disk gets blanked.  This might be because of bugs, malicious
users or mistakes.

In some situations, the hard disk partition will really be a barrier.
Particularly if the root partition has been mounted read only.  But is
this "security barrier" useful enough to excuse it's cost?

In any case, my experience is that when _one_ partition runs full
or gets accidentally deleted, things usually stops working anyway, and
in the latter case you'd have to run for the backups anyway.

I have finally concluded that, in the very most cases, partitionating
is _not_ worth the costs.

--
Check our new Mobster game at http://hstudd.cs.uit.no/mobster/
(web game, updates every 4th hour, no payment, no commercials)

 
 
 

df incorrectly reports 100% usage after power down

Post by Tobias Bro » Fri, 23 May 2003 21:42:42



> it's filled up to 100%. Ther remainder of the free space is reserved
> for root, mortal users are not allowed to fill it. remove the stuff you
> don't need. Check /var and /tmp for big logs.

Is it possible to adjust those limits?  Sometimes they're just too
ridiculous.  Like when having a work station with a very big disk -
I've seen a gigabyte "disappear" because of this, it's a sad story.

--
Check our new Mobster game at http://hstudd.cs.uit.no/mobster/
(web game, updates every 4th hour, no payment, no commercials)

 
 
 

df incorrectly reports 100% usage after power down

Post by Jean-David Beye » Fri, 23 May 2003 22:03:43



 >
 >> Nonsense. Where do you get this logic from? I suppose you think
 >> that leaving the toilet door open to the whole house won't stink
 >> the whole house out? Great idea .. let the effluent overflow to the
 >> whole house and therefore there's no overflow problem because there
 >> is more room for the effluent and hence it's better!
 >
 >
 > There are two possible problems;
 >
 > a) the disk gets filled up with "rubbish".  This might be because of
 > overflooding log files, software bug producing i.e. temporary files
 > at a great speed, unaware users, malicious users, etc.

I think what Peter was getting at is that if you separate /var and /tmp
from the / partition you _could_ make / read-only. I do not even know if
that is necessary or not. But the main advantage I see in separating out
/var and /tmp is that they are the ones that, if filled up, can pretty
well cripple a system even if it is not technically crashed. There seem
to be two big advantages in separating them out:

1.) You can set disk quotas on / that prevent normal users from writing
there even if the / partition is not read-only.

2.) You can set disk quotas on /var and /tmp that keep any particular
user from hogging the space. This will stop any one user (or group,
depending how you set up the disk quotas) from filling up /var or /tmp
with "rubbish."

As far as logfiles are concerned, if you run something like logrotate on
a regular basis, your log files should be controllable.
 >
 > b) the disk gets blanked.  This might be because of bugs, malicious
 > users or mistakes.
 >
I am not sure I know what you mean by "blanked." Do you mean something
like rm -fr * at the top of the file system? Or something like if=dd
/dev/zero of=/ ?

Here, too, unless the superuser is doing it, permissions on the
directories and disk quotas should protect you pretty well.

 > In some situations, the hard disk partition will really be a barrier.
 >  Particularly if the root partition has been mounted read only.  But
 > is this "security barrier" useful enough to excuse it's cost?

The only cost I see is if you did a poor partitioning in the first place
and assigned too much space to one file system that was mostly empty,
and not enough to another that was too full.

Over the years, my partitioning seems pretty good for my needs. I used
to have something like 16 partitions for a desktop system. I have now
cut that down to 9, spread over two hard drives. And most people in my
situation would omit /data1 and /data2 that are reserved for IBM's DB2
dbms. If I were to do it over again, I would move /var from sda to sdb
and steal more space from /home to double its size. I have not run out,
but it gets close sometimes (old tripwire reports and up2date files).

Filesystem           1k-blocks      Used Available Use% Mounted on
/dev/sda1                49558     25060     21939  54% /boot
/dev/sda2              5365176   2152984   2939656  43% /
/dev/sda3              2015824    181652   1731772  10% /data1
/dev/sda5              1007880    529460    427224  56% /opt
/dev/sda6               190387      5669    174889   4% /tmp
/dev/sda7               192352     60613    121807  34% /var
/dev/sdb1              5780400   1055148   4431624  20% /home
/dev/sdb2              2015824    181844   1731580  10% /data2
/dev/sdb3              1048576                       5% [swap]
 >
 > In any case, my experience is that when _one_ partition runs full or
 > gets accidentally deleted, things usually stops working anyway, and
 > in the latter case you'd have to run for the backups anyway.
 >
 > I have finally concluded that, in the very most cases, partitionating
 >  is _not_ worth the costs.
 >
What are the costs of partitioning? With a little experience, you should
be able to get it right for you and your users.

--
   .~.  Jean-David Beyer           Registered Linux User 85642.
   /V\                             Registered Machine    73926.
  /( )\ Shrewsbury, New Jersey     http://counter.li.org
  ^^-^^ 8:40am up 3 days, 14:14, 4 users, load average: 2.22, 2.14, 2.10

 
 
 

df incorrectly reports 100% usage after power down

Post by Jean-David Beye » Fri, 23 May 2003 22:11:20




>>it's filled up to 100%. Ther remainder of the free space is reserved
>>for root, mortal users are not allowed to fill it. remove the stuff you
>>don't need. Check /var and /tmp for big logs.

> Is it possible to adjust those limits?

It certainly is: man mke2fs

the -m flag is the one to use. If omitted, you get 5% reserved for
superuser. That might make sense for /tmp and /var, but it is silly for
some others.

Quote:> Sometimes they're just too
> ridiculous.  Like when having a work station with a very big disk -
> I've seen a gigabyte "disappear" because of this, it's a sad story.

--
   .~.  Jean-David Beyer           Registered Linux User 85642.
   /V\                             Registered Machine    73926.
  /( )\ Shrewsbury, New Jersey     http://counter.li.org
  ^^-^^ 9:05am up 3 days, 14:39, 4 users, load average: 2.08, 2.14, 2.16
 
 
 

df incorrectly reports 100% usage after power down

Post by Tobias Bro » Fri, 23 May 2003 22:41:14



> I think what Peter was getting at is that if you separate /var and /tmp
> from the / partition you _could_ make / read-only.

Having all file-systems with executables read-only would probably be a
good idea.

Quote:> I do not even know if
> that is necessary or not. But the main advantage I see in separating out
> /var and /tmp is that they are the ones that, if filled up, can pretty
> well cripple a system even if it is not technically crashed.

If /var or /tmp is full, and the system is "crippled but not
technically crashed", then the system is just "crippled but not
technically crashed" no matter how many partitions there are.

A full disk partition might and might not be a problem no matter how
many partitions there are.  If a full disk is a problem, it is because
a process "needs" to write something to disk.  If the disk is full, it
might have been because just that process did write something to the
disk.  The same partition would get full anyway.  In my experience, at
least, the frequency of "full disk problem" was much higher while
running mulitple partitions.

Yeah, add in a 100+ of users without disk qoutas set .. and give all
of 'em write access to /tmp and /home, which is at the root partition
- and you'll run into problems fast.  In such a case there really is a
need for separate partitions.  I haven't been administrating such
boxes, only boxes with 0-5 login-users.  The "newbies" are usually
running work stations with 1-2 real users, sometimes even sharing the
same login.

Quote:> There seem
> to be two big advantages in separating them out:
> 1.) You can set disk quotas on / that prevent normal users from writing
> there even if the / partition is not read-only.

Split out /, and "normal users" should not have write-permission (even
if it's not read-only).  Users should generally not have write access
anywhere else than /home and /tmp, and eventually indirectly to /var.
If the user wants to fill up the database server with crap, disk
qoutas won't stop him.  Except for a disk quota for the database
server - but then the database service would fail anyway.

It's many years since last time I was fiddling with disk quotas - but
is it really impossible to set it up different quotas on different
hierarchies within the same file system?

Quote:>  > b) the disk gets blanked.  This might be because of bugs, malicious
>  > users or mistakes.

> I am not sure I know what you mean by "blanked." Do you mean something
> like rm -fr * at the top of the file system? Or something like if=dd
> /dev/zero of=/ ?

Imprecise language.  "corrupted" would be a more inclusive word.  It
might be because of hardware failures as well.  Oh, yes, if the root
disk is corrupted it probably wouldn't be possible to boot.  But as I
said, it's needed to run for the backups anyway - and you do have a
backup booting solution as well, don't you?  In RedHat a /boot
partition is first mounted as the root partition, that's not a bad
solution to the booting problem.

Quote:> The only cost I see is if you did a poor partitioning in the first place
> and assigned too much space to one file system that was mostly empty,
> and not enough to another that was too full.

People do "poor partitionating" unless they know exactly how much they
will need in advance, and sticks to it.  That's why I think that
anyone that don't know for sure /why/ they need to partitionate the
disk should not do that at all.

Anyway it's not possible to plan for a longer timespan.  Sometimes
you'd like to upgrade or install new software - so it's needed to have
some spare capacity at /usr and /usr/local.  Even the real root stuff
in /bin, /lib and /sbin might need an upgrade, so you need to have
some spare capacity there, too.  Sooner or later one of the partitions
will run out of spare capacity, while the others have spare capacity
en-gross.

/tmp and /var will grow and shrink over time.  Having them on the same
partition might be a bad idea because anybody can fill up /tmp, while
/var have more restrictions.  Then again, the total capacity is much
better when there is no solid boundary between those partitions. It
can be compared with networking; it's much better for 32 persons to
share one 2MB-link than for them to have each their 64 kbps leased
line.

--
Check our new Mobster game at http://hstudd.cs.uit.no/mobster/
(web game, updates every 4th hour, no payment, no commercials)

 
 
 

df incorrectly reports 100% usage after power down

Post by Tobias Bro » Fri, 23 May 2003 22:48:59



> Imprecise language.  "corrupted" would be a more inclusive word.  It
> might be because of hardware failures as well.  Oh, yes, if the root
> disk is corrupted it probably wouldn't be possible to boot.  But as I
> said, it's needed to run for the backups anyway - and you do have a
> backup booting solution as well, don't you?  In RedHat a /boot
> partition is first mounted as the root partition, that's not a bad
> solution to the booting problem.

Nah .. I'm wrong.  Depending on the backup scheme, it's much
easier to recover if one small partition is broken than if all the
root partition is broken.  I'd admit that.

--
Check our new Mobster game at http://hstudd.cs.uit.no/mobster/
(web game, updates every 4th hour, no payment, no commercials)

 
 
 

df incorrectly reports 100% usage after power down

Post by Jean-David Beye » Fri, 23 May 2003 23:20:59


Tobias Brox wrote:

 > In article <3ECCCAAF.4020...@exit109.com> you wrote:
 >
 >> I think what Peter was getting at is that if you separate /var and
 >> /tmp from the / partition you _could_ make / read-only.
 >
 >
 > Having all file-systems with executables read-only would probably be
 > a good idea.
 >
 >
 >> I do not even know if that is necessary or not. But the main
 >> advantage I see in separating out /var and /tmp is that they are
 >> the ones that, if filled up, can pretty well cripple a system even
 >> if it is not technically crashed.
 >
 >
 > If /var or /tmp is full, and the system is "crippled but not
 > technically crashed", then the system is just "crippled but not
 > technically crashed" no matter how many partitions there are.

Agreed. But if /var and /tmp are separate partitions, you can control
how much any one user or group can write into them, and prevent runaway
programs from putting too much in them.

The nearest thing to a problem might be if you were running iptables
doing heavy logging of rejects, and someone tried a denial of service
attack on you, filling up /var/log/messages. But you can configure
iptables to throttle the logging if you wish.
 >
 > A full disk partition might and might not be a problem no matter how
 > many partitions there are.  If a full disk is a problem, it is
 > because a process "needs" to write something to disk.

Not necessarily. It might be because a runaway process is filling the
disk, and the runaway process might be a programming error or a virus.
In both those cases, while the program might think it needs all the disk
space ever manufactured, a sensible sysadmin would know that X megabytes
were enough.

 > If the disk is
 > full, it might have been because just that process did write
 > something to the disk.  The same partition would get full anyway.  In
 > my experience, at least, the frequency of "full disk problem" was
 > much higher while running mulitple partitions.
 >
 > Yeah, add in a 100+ of users without disk qoutas set .. and give all
 > of 'em write access to /tmp and /home, which is at the root partition
 >  - and you'll run into problems fast.  In such a case there really is
 > a need for separate partitions.  I haven't been administrating such
 > boxes, only boxes with 0-5 login-users.  The "newbies" are usually
 > running work stations with 1-2 real users, sometimes even sharing the
 >  same login.

In that case, it should be a simple matter to give them quotas of 1
block in / and a modest amount in /var and /tmp. You could even put them
all in group newbie and assign a group quota.

If you let them share a login, I think you are crazy. Putting them all
in the same group (newbie?), not default in Red Hat, would sure make sense.
 >
 >
 >> There seem to be two big advantages in separating them out:
 >
 >
 >> 1.) You can set disk quotas on / that prevent normal users from
 >> writing there even if the / partition is not read-only.
 >
 >
 > Split out /, and "normal users" should not have write-permission
 > (even if it's not read-only).  Users should generally not have write
 > access anywhere else than /home and /tmp, and eventually indirectly
 > to /var. If the user wants to fill up the database server with crap,
 > disk qoutas won't stop him.  Except for a disk quota for the database
 >  server - but then the database service would fail anyway.

Well, if your users get a lot of spam in the e-mail, /var/spool/mail/
can sure fill up. Or if they never delete their e-mails.

I run my database server in its own partition(s). I know who the users
are. I could give them read-only access to the databases. If I were
concerned with newbies, I would only allow them to create databases in
partition /newbie or something. Now the dbms makes some temporary files
in /var/db2 and in /var/IBMdb2, and in principle they could get quite
large. But they do not hang around very long.
 >
 > It's many years since last time I was fiddling with disk quotas - but
 >  is it really impossible to set it up different quotas on different
 > hierarchies within the same file system?

AFAIK, it is impossible. Within a file system (and by that I mean
partition), you can set a different quota on each user if you wish,
including as little as one block.
 >
 >>> b) the disk gets blanked.  This might be because of bugs,
 >>> malicious users or mistakes.
 >>>
 >> I am not sure I know what you mean by "blanked." Do you mean
 >> something like rm -fr * at the top of the file system? Or something
 >> like dd if=/dev/zero of=/ ?
 >
 >
 > Imprecise language.  "corrupted" would be a more inclusive word.  It
 > might be because of hardware failures as well.  Oh, yes, if the root
 > disk is corrupted it probably wouldn't be possible to boot.  But as I
 >  said, it's needed to run for the backups anyway - and you do have a
 > backup booting solution as well, don't you?  In RedHat a /boot
 > partition is first mounted as the root partition, that's not a bad
 > solution to the booting problem.

I am not sure I understand what you are talking about. I normally let
grub boot my system. I make a new boot disk everytime I change the
kernel. I also make a _total_ backup every morning when I am asleep onto
removeable tape. And monthly I make a Crash Recovery tape and two
floppies, so if I must put in new hard drives or something, I can
restore the system exactly to the most recent monthly tape (I keep 12 of
these), and then update it to the most recent total backup so I should
never lose more than 24 hours of files. If I do that, it will surely boot.
 >
 >
 >> The only cost I see is if you did a poor partitioning in the first
 >> place and assigned too much space to one file system that was
 >> mostly empty, and not enough to another that was too full.
 >
 >
 > People do "poor partitionating" unless they know exactly how much
 > they will need in advance, and sticks to it.  That's why I think that
 >  anyone that don't know for sure /why/ they need to partitionate the
 > disk should not do that at all.

Well, perhaps they could do as I did. When I first installed Linux
(R.H.L. 5.0), I read up on partitioning. I had run the UNIX OS since the
mid 1970s until about 1994, so I knew what partitions were, and the
general idea of partitioning was familiar to me. I then followed some of
the suggestions of Red Hat and came up with 16 partitions, or something
like that. It became clear immediately that it was a dumb partitioning,
so, since I did not have much commitment, I just reinstalled it with
better partitioning. It was not too bad, but when I installed R.H.L.
6.0, I changed it quite a bit, and I had a year's use, so I knew the
amounts of stuff that tended to get into each of the partitions. So I
reduced the number of partitions somewhat more, and improved their
sizes. I actually have two machines, so when I installed the other, my
partitioning was even better even though it had two Linux hard drives
(the old machine has a Windows 95 partition that consumes an entire hard
drive as well). I did not change the partitioning around until I put
R.H.L. 7.3 on the machine, and even then, I just fine-tuned the sizes a
little bit.
 >
 > Anyway it's not possible to plan for a longer timespan.  Sometimes
 > you'd like to upgrade or install new software - so it's needed to
 > have some spare capacity at /usr and /usr/local.  Even the real root
 > stuff in /bin, /lib and /sbin might need an upgrade, so you need to
 > have some spare capacity there, too.  Sooner or later one of the
 > partitions will run out of spare capacity, while the others have
 > spare capacity en-gross.
 >
 > /tmp and /var will grow and shrink over time.  Having them on the
 > same partition might be a bad idea because anybody can fill up /tmp,
 > while /var have more restrictions.

While I suppose you could put /var and /tmp in the same partition, I
have never done that: each gets a partition of its own.

 > Then again, the total capacity is
 > much better when there is no solid boundary between those partitions.
 > It can be compared with networking; it's much better for 32 persons
 > to share one 2MB-link than for them to have each their 64 kbps leased
 >  line.
 >
I think that would depend on their useage patterns and whether the
network were ethernet with all its collisions, or some other type of
network. If you said 32 users sharing one 4MB link than each their own
64KB link, I would agree because at that load, the collisions on an
ethernet would not be too bad (most of the time).

But the fragmentation you allude to, and having the free space in the
wrong file-system is a problem that requires attention. It just seems to
me that if you have some experience, and the restraint to not make too
many partitions, this should not be much of a problem. If you are
running out of disk space too often, and your partitioning is pretty
good, it is time to add another hard drive to your system.

--
   .~.  Jean-David Beyer           Registered Linux User 85642.
   /V\                             Registered Machine    73926.
  /( )\ Shrewsbury, New Jersey     http://counter.li.org
  ^^-^^ 9:45am up 3 days, 15:19, 4 users, load average: 2.07, 2.09, 2.10

 
 
 

1. 100% power suppply Loss of AC Power Report by root mail

Hi,

    I getting following error message from root mail...

A Problem was detected on Tue Sep 1 04:01:05 EDT 1998

The Service Request Number(s) /Error Code(s).
  805-805:   Error Log Analysis indicates the following problems:

Probable Cause or Causes:
- 100%  power supply   00-00             Loss of AC Power.

This is a new system (running about 3-days) 7043-140 AIX 4.2.1.  The system
is not really losing power (if that is what the error is implying).

This error happens every day at the same time,  the root mail reports this
every few seconds for about 10 min.
This system has a 128 port Async adapter with 2 Remote  Async  16-ports.
The system otherwise is functioning properly.

2. ttysnoop questions

3. df not reporting root filesystem usage (but is reporting mounted dos drives)

4. xntpd with DeLorme Tripmate

5. df incorrectly reports remaining space in 2.4

6. When You Hear The Heavy Accent & The Poor Phone Connection... HANG UP!!! _____ t6045ksmJPo

7. df incorrectly reports remaining space (Solaris 2.4)

8. Phone Blaster with Solarisx86

9. df reports disk 100% in use

10. df misreporting 100% usage on 25% full filesystem

11. HELP: df reports hd=100% FULL...incorrect!!!

12. prevent powering down Blade 100

13. df shows 100% used, after I removed files, it's still 100% used