diff options
author | Lukas Czerner | 2013-12-03 16:24:44 +0100 |
---|---|---|
committer | Karel Zak | 2013-12-12 11:14:26 +0100 |
commit | a1ca32fb3862ccac7275d6b342805b6d99f20e39 (patch) | |
tree | 5b686b55ec4fd45328d458852c9be93f93c953a3 /sys-utils/mount.8 | |
parent | textual: small inprovements to usage and man page of fstrim (diff) | |
download | kernel-qcow2-util-linux-a1ca32fb3862ccac7275d6b342805b6d99f20e39.tar.gz kernel-qcow2-util-linux-a1ca32fb3862ccac7275d6b342805b6d99f20e39.tar.xz kernel-qcow2-util-linux-a1ca32fb3862ccac7275d6b342805b6d99f20e39.zip |
libblkid: Identify extN file system properly
Currently when trying to identify extN file system we're playing games
with searching for kernel modules and parsing /proc/filesystem. All of
this just because ext4 module can be used to mount ext3 and ext2 file
systems on recent kernel and also because of ext4dev.
However all of this is not necessary. Ext4 module which does support
mounting ext2 and ext3 file system is able to recognize and mount ext2
and ext3 type so there is no need to disguise it and ext4dev should only
be ever used for testing and not as fallback when other modules are
missing (use -t instead).
This also introduces a bug when in situation that we only have ext4
modules with ext2/ext3 support which is not loaded and we try to mount
ext2 file system we will mount it incorrectly as ext4. This will not
happen if the ext4 module is already loaded.
With this patch we remove all the unnecessary checks and return the real
type of the file system which is on the device. This fixes the issue.
However on the kernel which was not compiled with EXT4_USE_FOR_EXT23
support one would have to provide file system type (-t) to be able to
mount the file system with ext4 driver.
Signed-off-by: Lukas Czerner <lczerner@redhat.com>
Signed-off-by: Karel Zak <kzak@redhat.com>
Diffstat (limited to 'sys-utils/mount.8')
0 files changed, 0 insertions, 0 deletions