From: "Theodore Ts'o" <tytso@mit.edu>
To: Andries Brouwer <aebr@win.tue.nl>
Cc: Pankaj Agarwal <pankaj@pnpexports.com>,
Andreas Schwab <schwab@suse.de>,
linux-kernel@vger.kernel.org
Subject: Re: how to identify filesystem type
Date: Fri, 20 Aug 2004 23:25:21 -0400 [thread overview]
Message-ID: <20040821032520.GA15772@thunk.org> (raw)
In-Reply-To: <20040820215858.GA5771@pclin040.win.tue.nl>
On Fri, Aug 20, 2004 at 11:58:58PM +0200, Andries Brouwer wrote:
>
> I suppose this code started as part of mount(8). For example,
>
> # mount --guess-fstype /dev/hdb2
> reiserfs
Actually, it was fsck's filesystem type detection code, and it's since
been completely rewritten.
> However, I cannot stress often enough that these are unreliable guesses.
> It is really undesirable when standard infrastructure starts depending
> on 99.7% guesses.
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.
> 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.)
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
next prev parent reply other threads:[~2004-08-21 3:25 UTC|newest]
Thread overview: 13+ messages / expand[flat|nested] mbox.gz Atom feed top
2004-08-19 9:07 how to identify filesystem type Pankaj Agarwal
2004-08-19 9:46 ` Andreas Schwab
2004-08-19 14:03 ` Pankaj Agarwal
2004-08-20 15:36 ` Frank Steiner
2004-08-20 20:46 ` Andreas Dilger
2004-08-20 21:58 ` Andries Brouwer
2004-08-21 3:25 ` Theodore Ts'o [this message]
2004-08-21 8:51 ` Andries Brouwer
-- strict thread matches above, loose matches on Subject: below --
2004-08-19 3:22 Pankaj Agarwal
2004-08-19 8:13 ` ippi
2004-08-19 9:06 ` ippi
2004-08-19 9:07 ` Pankaj Agarwal
2004-08-19 9:48 ` ippi
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20040821032520.GA15772@thunk.org \
--to=tytso@mit.edu \
--cc=aebr@win.tue.nl \
--cc=linux-kernel@vger.kernel.org \
--cc=pankaj@pnpexports.com \
--cc=schwab@suse.de \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.