[nylug-talk] Re :Re: extfs journalling percentage (Chris Knadle)

[Joseph A. Maffia]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1


www.joemaffia.com



Chris Knadle wrote:
| On Tuesday 27 May 2008, Michael Bubb wrote:
|>> From: Chris Knadle <Chris.Knadle at coredump.us>
| ...
|>>> If I understand correctly the actual journal is not that big. Most of
|>>> this 5% is reserved so that a superuser has access to  an otherwise
|>>> full partition. Do you need 5% for this? (ie if you have a 250G
|>>> parttion do you need 13G reserved).
|
| ...
|>>   I'm not 100% positive, but I don't think the ext3 journal counts in
|>> that 5% reserved for root-only usage.  Mainly I think that this is space
|>> set aside for root for having a place to do emergency filesystem repair,
|>> like using debugfs or similar utilities.
|
| ...
|> Thank you Chris.
|> Now I am intruiged as to how to use this admin space in an actual
|> crash.  Guess I will try and google more on the purpose for this.
|
|    I've only had to rescue an ext3 partition once.  It happened 
because of an
| overloaded circuit breaker due to not monitoring how much power we were
| running through a circuit, repeatedly bringing down half an entire server
| room, including the local mail server -- which corrupted the /var 
partition
| that was using ext3.  In this case any attempt at mounting the /var 
partition
| on the mail server would cause the kernel to hang hard without even a 
kernel
| panic as to why.  We assumed that the disk had been in the middle of a 
write
| operation (logs) when the power dropped and thus did something 
unexpected to
| the disk.  We were forced to use debugfs to glean what information 
from the
| unmounted /var partition that we could, onto another partition.  
Hitting the
| trouble spot even with debugfs would hang the kernel hard, so we had to be
| careful to avoid that spot... once we "found out" where that was... by 
trial
| and error.
|    We then re-made the ext3 filesystem on the /var partition, mounted 
it, and
| copied the data that we had acquired back.
|
|    I believe doing the above required booting into a Red Hat 7.2 rescue
| envionment, which by default did not have device names made for the 
disk that
| had the problem, so we had to use mknod to make those before doing the 
work.  
| So on every "trial and error" miss we had to re-make these devices as 
well as
| run an fsck on the ext3 partitions that had been mounted when the 
kernel hung
| during the rescue work.
|    These days with udev the missing devices are likely no longer a 
problem.
|
|    Now, I don't think we used the 5% "admin" space on any of the ext3
| parititions in the above case, however if all of the various 
filesystems were
| FULL, then that admin space would have been all we had to work with to 
rescue
| the /var partition.  So I can understand why it's needed even if I haven't
| actually had to use it.  ;-)
|
|    -- Chris
|
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.4-svn0 (GNU/Linux)
Comment: Using GnuPG with SUSE - http://enigmail.mozdev.org

iD8DBQFIP9+x1Zo2InkR90QRAtc2AJ9a9viQVEpYgadohmEUIPd0+WyUNgCeJGtI
mYPbiZHD4tmzoS5ShCrKmkw=
=Ag57
-----END PGP SIGNATURE-----