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%.