how to identify filesystem type

Hi,

I need your help, in understanding filesystems. Kindly let me know how to identify the filesystem in an image file or block device.

thanks in advance and regards,

Pankaj Agarwal

Use file:

# file -s /dev/hda3
/dev/hda3: ReiserFS V3.6 block size 4096 (mounted or unclean) num blocks 9500285 r5 hash

Andreas.

Andreas Schwab, SuSE Labs, [email protected]
SuSE Linux AG, Maxfeldstraße 5, 90409 Nürnberg, Germany
Key fingerprint = 58CA 54C7 6D53 942B 1756  01D3 44D5 214B 8276 4ED5
"And now for something completely different."

Hi Andreas,

this is the output when you have a mounted block device.....you can only mount when you know the filesystem ....thats wat i wanna know...hoe to identify filesytems...on ablockdevice.

thanks anyways, looking forward for more information on this

Pankaj

----- Original Message -----
From: "Andreas Schwab" <[email protected]>
To: "Pankaj Agarwal" <[email protected]>
Cc: <[email protected]>
Sent: Thursday, August 19, 2004 3:16 PM
Subject: Re: how to identify filesystem type

Use file:

# file -s /dev/hda3
/dev/hda3: ReiserFS V3.6 block size 4096 (mounted or unclean) num blocks
9500285 r5 hash

Andreas.

--
Andreas Schwab, SuSE Labs, [email protected]
SuSE Linux AG, Maxfeldstraße 5, 90409 Nürnberg, Germany
Key fingerprint = 58CA 54C7 6D53 942B 1756 01D3 44D5 214B 8276 4ED5 "And now for something completely different."
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/

And when it's not mounted, the output is still enough:

zassenhaus /root# grep /dev/hda7 /proc/mounts
zassenhaus /root# file -s /dev/hda7
/dev/hda7: ReiserFS V3.6 block size 4096 num blocks 11378028 r5 hash

galois fst/tmp# grep /dev/hda8 /proc/mounts
galois fst/tmp# file -s /dev/hda8
/dev/hda8: Linux rev 1.0 ext3 filesystem data

That's all you need to know...

Dipl.-Inform. Frank Steiner   Web:  http://www.bio.ifi.lmu.de/~steiner/
Lehrstuhl f. Bioinformatik    Mail: http://www.bio.ifi.lmu.de/~steiner/m/
LMU, Amalienstr. 17           Phone: +49 89 2180-4049
80333 Muenchen, Germany       Fax:   +49 89 2180-99-4049

There is a tool available as part of e2fsprogs (1.34 maybe?) which is called "blkid" that identifies block devices. Currently fsck uses this to know what fsck.fstype to use, and it was my hope to have mount(8) use this also (never got around to doing that work).

The benefits of blkid are that you can use it as a regular user, even without read access to the disk (it will return cached values generated by root if you don't have read access to the block device), it also will print LABEL and UUID information to identify the filesystem, if you use it repeatedly from some application it doesn't re-scan all of the devices each time (important for large numbers of block devices).

Cheers, Andreas
--
Andreas Dilger
http://sourceforge.net/projects/ext2resize/
http://members.shaw.ca/adilger/ http://members.shaw.ca/golinux/

I suppose this code started as part of mount(8). For example,

# mount --guess-fstype /dev/hdb2
reiserfs

However, I cannot stress often enough that these are unreliable guesses. It is really undesirable when standard infrastructure starts depending on 99.7% guesses.

Consequently, "blkid" is a really bad name. It gives no indication of the guessed nature of its results.

(I see that my current version is also broken:

# blkid -v
blkid 1.0.0 (12-Feb-2003)
# blkid
...
/dev/sda4: LABEL="ZIP-100" UUID="34D8-1C07" TYPE="msdos" 
/dev/sda1: UUID="1ac5969c-8fdf-4f69-934a-c6103d93c05d" TYPE="ext2" 
/dev/sdb4: LABEL="ZIP-100" UUID="34D8-1C07" TYPE="msdos" 
/dev/sdb1: LABEL="CF_CARD032M" UUID="2001-1207" TYPE="msdos" 
...
Here no /dev/sda1 and no /dev/sdb4 exist.)

Andries

Actually, it was fsck's filesystem type detection code, and it's since been completely rewritten.

It's certainly possible for mistakes to be made, but it is really quite reliable at this point --- escpecially since various filesystem's mkfs programs and various lvm partition initialization progams are pretty good about erasing other filesystems' signatures as part of the mkfs/partition init process.

Everything is really a "guess" at some level; there is no guarantee that /etc/fstab is 100% accurate, or that the partition table's type fields are accurate. I will say that the ID code in the blkid library is pretty paranoid about sanity checks, although of course it could be better.

Blkid deliberately doesn't revalidate devices without any command-line arguments, because certain devices might timeout or block for a long-time. If you use "blkid /dev/sdb4", or use the library interfaces, it will revalidate any entries found in the cache file before returning them.

- Ted

Yes:

# blkid
...
/dev/sda4: LABEL="ZIP-100" UUID="34D8-1C07" TYPE="msdos"
/dev/sda1: UUID="1ac5969c-8fdf-4f69-934a-c6103d93c05d" TYPE="ext2" 
/dev/sdb4: LABEL="ZIP-100" UUID="34D8-1C07" TYPE="msdos" 
...
# blkid /dev/sda1
# blkid /dev/sdb4
# blkid
...
/dev/sda4: LABEL="ZIP-100" UUID="34D8-1C07" TYPE="msdos"
/dev/sda1: UUID="1ac5969c-8fdf-4f69-934a-c6103d93c05d" TYPE="ext2"
/dev/sdb4: LABEL="ZIP-100" UUID="34D8-1C07" TYPE="msdos"
...
#

So, the cache file is not updated.
Moreover, the cache file has never been correct - there is only one ZIP drive here and it is /dev/sda. The disk inside has only one nonempty partition, and it is /dev/sda4.
The command # blkid -c /dev/null does not list these two bogus entries, and a new /etc/blkid.tab is written, but a subsequent command # blkid again lists the bogus entries.
Doing # rm /etc/blkid.tab* by hand helps.

Andries