Category : Linux Files
Archive   : E2FSPRG3.ZIP
Filename : EXT2FS.FAQ

FAQ for the second extended file system
Last updated on 93/03/29


This file contains the answers to some frequently asked questions
regarding the second extended file system.

Q: I have created an ext 2 fs on my root file system and, every time I boot
Linux, I see these messages :
MINIX-fs magic match failed
EXT-fs: magic match failed
Does it mean that Linux doesn't recognize my root file system ?

A: No.
When Linux boots, it tries to mount the root file system using the
different file system types :
- it first tries to mount / as a minix file system, discovers that it
is not a minix fs and displays the first error message,
- then it tries to mount / as an extended file system, discovers that
it is not an extended fs and displays the second error message.

Q: After the two error messages, I see :
[EXT II FS 0.2c, 93/03/06, bs=1024, fs=1024, gc=##, bpg=##, ipg=####]
EXT2-fs warning: mounting non valid file system
Does it mean that there is a problem with the file system ?

A: Usually no.
In fact, the ext 2 fs keeps a valid flag on the disk. This flag is set to
0 when the file system is mounted and set to 1 when it is unmounted. The
valid flag is checked by e2fsck to know if a file system needs checking (if
the flag is set to 1, e2fsck assumes that the file system is clean and does
not check it).

The root file system is the only fs which cannot be unmounted so the valid
flag is always set to 0. When booting, the kernel mounts it and checks its
valid flag. As this flag is set to 0, it displays a warning.

You can safely ignore this warning for the root file system. Note that it
is a good idea to run e2fsck on the fs.

Q: I have tried to create an ext 2 file system with mke2fs and it dies with
'Out of memory'. What is the problem ?

A: The problem comes from mke2fs itself. mke2fs eats lots of memory to create
a file system since it creates a memory copy of the inode table. The
problem has been fixed in recent versions (0.2c+ or above). Note that
e2fsck still has the same problem.

Q: I have tried to create an ext 2 fs with mke2fs and it dies with the
message :
mke2fs: Unable to find a block for the block bitmap
or :
mke2fs: Unable to find a block for the inode bitmap
or:
mke2fs: Unable to find a block for the inode table
What is the problem ?

A: An ext 2 fs is made of several blocks groups. Each group contains a copy
of the super block, a copy of the fs descriptors, two bitmap blocks and
a part of the inode table. Each group is 8192 blocks long.

When you create a file system, mke2fs divides the total number of blocks by
8192 to compute the number of groups. Then, it tries to write the control
informations into each group. Sometimes, the last group may be too small to
contain these informations and mke2fs simply dies when it detects the
problem. This (stupid) behaviour will be fixed in a future release.

With the current release, you can bypass the problem by creating a smaller
or bigger file system (i.e. decrease or increase the blocks count).

Q: When I run df, it shows that my ext 2 fs is more than 100% full. Is it
normal ?

A: Yes.

Each ext 2 fs contains some blocks which are reserved for the super user
(i.e. which cannot be allocated to normal users). df uses the statfs()
system call which returns a structure containing :
- f_blocks : the total count of allocated blocks,
- f_bfree : the total count of free blocks,
- f_bavail : the count of free blocks available to normal user.

df divides f_blocks by f_bavail to compute the block allocation percentage.
In an ext 2 fs where root has allocated most of the block, f_blocks is
greater than f_bavail so the allocation percentage is greater than 100%.