[nylug-talk] Ext3 Disk Reservation and Defaults -- WAS: extfs journalling percentage

[Bryan J. Smith]

Michael Bubb wrote:
> 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.

Chris Knadle wrote:  
> I've only had to rescue an ext3 partition once ...

I do not believe this is accurate, not for Ext3 and definitely not for
XFS either.  Both e2fsck and xfs_repair run out of memory.  I know this
for even XFS because large XFS filesystems take _forever_ to run
xfs_repair on (I learned that down to the finest detail ;).

[ It's also why I don't believe in "one big, huge filesystem," but
that's another topic. ]

If anything, they would use "swap" for any "scratch."  To do otherwise
would be "unsafe."  The filesystem is read-only, with only "targeted"
writes to specific areas.  In fact, on many OSes, fsck is a _character_
(byte-by-byte) device operation -- not sure about Linux (the devices are
block, but they may point to generic ones for fsck).

The "admin" reservation is for fixing issues, yes, so you have the room
to do so.  But it's not repairing the filesystem during an e2fsck or
xfs_repair.  I almost want to say it's a bit dangerous to assume such.
I can think of several reasons, but I won't tangent further.

[ I've already been warned of doing that prior. ]

Chris Knadle wrote: 
> Ah.  Yeah, at boot time the normal periodic fsck of ext3, when I
> used it, usually noted about 4% "non-continuous", i.e. fragmentation,
> if I remember correctly.

> I'm mostly using XFS currently, in which an fsck at boot time is
> essentially a no-op.

Unlike Ext3, XFS actually does many things simultaneous with mounting.
Unfortunately, sometimes XFS will mount, then realize its meta-data
journal replay has failed.  It will then make itself unavailable, after
already making itself available.

I assume you've never had to run "xfs_repair", it's off-line fsck?  ;)

BTW, one of the reasons I _never_ used ReiserFS is because their
off-line fsck was constantly "out-of-sync" with the in-kernel,
structural implementations.  So even if ReiserFS was solid in the
kernel, and its meta-data journaling was often, if the journal replay
failed, you were at the mercy of its off-line fsck.

It wasn't pretty every time I had to drop to that.

Ext3 and XFS are virtually unchanged, structurally, for over the past
decade (yes, even when XFS came from Irix to Linux, virtually nothing
was changed structurally).  There have been a few meta-data changes in
the superblock (e.g., UUID into kernel 2.2, which I just recently
explained on another list), and organizational improvements of inode
trees and block entries (for performance).

But the structure is largely unchanged.

> Interesting.

Extents are a blessing and a curse.  Again, I'd _never_ use XFS for /tmp
or /var.

> The default of 5% seems like a reasonable value as far as I can tell.

The potential benefits of reserving 5% outweigh the storage loss.  It's
all about cost v. risk.


-- 
Bryan J  Smith              Professional, Technical Annoyance
mailto:b.j.smith at ieee.org  http://www.linkedin.com/in/bjsmith
-------------------------------------------------------------
           Fission Power:  An Inconvenient Solution