-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
So I've noticed, again, much annoyed, that if I rely on -t auto,
horrible horrible things happen.
I have had floppies and compact flash cards that I've done mkfs.vfat to
make fat32 filesystems on (not fat16), and mounting them brings the
thing on as msdos by default (autodetect). Furthermore, I build msdos
out, and mount says the msdos FS isn't supported. In either case I need
to use -t vfat.
Vfat is much more common and should be backwards compatible with msdos.
When there's a ton of foo~1 files around after mounting, something's
wrong.
Shouldn't vfat be the automatic default? Or at least, if only vfat and
not msdos is available, use vfat. For that matter, can msdos and vfat
be collapsed? As I recall, the difference is that vfat makes more
inodes to store long file names, one for each 13 characters (in reverse?)
I dunno. I can never understand the innards of the kernel devs' minds.
- --
All content of all messages exchanged herein are left in the
Public Domain, unless otherwise explicitly stated.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.5 (GNU/Linux)
Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org
iD8DBQFCBaw3hDd4aOud5P8RAtBGAJsE8I1510nLSNqM6MRwPFGnl9l2UQCfSaGy
HPGDuNVPvMZq8nkI34DlfPI=
=uNx9
-----END PGP SIGNATURE-----
On Sun, Feb 06, 2005 at 12:33:43AM -0500, John Richard Moser wrote:
> I dunno. I can never understand the innards of the kernel devs' minds.
filesystem detection isn't handled at the kerne level.
Hello John,
Am 2005-02-06 00:33:43, schrieb John Richard Moser:
> So I've noticed, again, much annoyed, that if I rely on -t auto,
> horrible horrible things happen.
Maybe you add the file
__( '/etc/filesystems' )______________________________________________
/
| ext3
| ext2
| minix
| vfat
| msdos
| iso9660
| hfsplus
| hfs
| nodev proc
\______________________________________________________________________
and if you use 'mount -t auto ...' it
will try the filesystems in this order.
Greetings
Michelle
--
Linux-User #280138 with the Linux Counter, http://counter.li.org/
Michelle Konzack Apt. 917 ICQ #328449886
50, rue de Soultz MSM LinuxMichi
0033/3/88452356 67100 Strasbourg/France IRC #Debian (irc.icq.com)
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Christoph Hellwig wrote:
> On Sun, Feb 06, 2005 at 12:33:43AM -0500, John Richard Moser wrote:
>
>>I dunno. I can never understand the innards of the kernel devs' minds.
>
>
> filesystem detection isn't handled at the kerne level.
>
o_o
. . . then I shall bug baselayout@!
>
- --
All content of all messages exchanged herein are left in the
Public Domain, unless otherwise explicitly stated.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.5 (GNU/Linux)
Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org
iD8DBQFCBkXqhDd4aOud5P8RAt3CAJ4uOZFfhAIDlF8crE4SXfLSoDLDrACfSDWG
LSaHLkMAGdKq8TuNFIHNQXM=
=SbC+
-----END PGP SIGNATURE-----
On Sun, Feb 06, 2005 at 07:06:59AM +0000, Christoph Hellwig wrote:
> On Sun, Feb 06, 2005 at 12:33:43AM -0500, John Richard Moser wrote:
> > I dunno. I can never understand the innards of the kernel devs' minds.
>
> filesystem detection isn't handled at the kerne level.
Yeah, but the link order could be changed... Patch inlined.
--
pozsy
diff -Naurd a/fs/Makefile b/fs/Makefile
--- a/fs/Makefile 2004-08-04 10:52:28.000000000 +0200
+++ b/fs/Makefile 2004-08-04 11:32:04.510913663 +0200
@@ -57,8 +57,8 @@
obj-$(CONFIG_MINIX_FS) += minix/
obj-$(CONFIG_FAT_FS) += fat/
obj-$(CONFIG_UMSDOS_FS) += umsdos/
-obj-$(CONFIG_MSDOS_FS) += msdos/
obj-$(CONFIG_VFAT_FS) += vfat/
+obj-$(CONFIG_MSDOS_FS) += msdos/
obj-$(CONFIG_BFS_FS) += bfs/
obj-$(CONFIG_ISO9660_FS) += isofs/
obj-$(CONFIG_DEVFS_FS) += devfs/
Signed-off-by: Pozsar Balazs <[email protected]>
On Mon, Feb 07, 2005 at 12:21:08AM +0100, Pozsar Balazs wrote:
> On Sun, Feb 06, 2005 at 07:06:59AM +0000, Christoph Hellwig wrote:
> > On Sun, Feb 06, 2005 at 12:33:43AM -0500, John Richard Moser wrote:
> > > I dunno. I can never understand the innards of the kernel devs' minds.
> >
> > filesystem detection isn't handled at the kerne level.
>
> Yeah, but the link order could be changed... Patch inlined.
And just what does the link order (or changes thereof) have to do with that?
On Mon, Feb 07, 2005 at 12:36:10AM +0000, Al Viro wrote:
> On Mon, Feb 07, 2005 at 12:21:08AM +0100, Pozsar Balazs wrote:
> > On Sun, Feb 06, 2005 at 07:06:59AM +0000, Christoph Hellwig wrote:
> > > On Sun, Feb 06, 2005 at 12:33:43AM -0500, John Richard Moser wrote:
> > > > I dunno. I can never understand the innards of the kernel devs' minds.
> > >
> > > filesystem detection isn't handled at the kerne level.
> >
> > Yeah, but the link order could be changed... Patch inlined.
>
> And just what does the link order (or changes thereof) have to do with that?
IIRC currently if both msdos and vfat are compiled in (not modules), and
you try to mount a vfat filesystem without explicitly specifying the fs
type, it will be mounted with the msdos type. With the, it will mounted
vfat.
--
pozsy
On 2005.02.07 00:42, Pozs?r Bal?zs wrote:
> On Mon, Feb 07, 2005 at 12:36:10AM +0000, Al Viro wrote:
> > On Mon, Feb 07, 2005 at 12:21:08AM +0100, Pozsar Balazs wrote:
> > > On Sun, Feb 06, 2005 at 07:06:59AM +0000, Christoph Hellwig wrote:
> > > > filesystem detection isn't handled at the kerne level.
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
>
> IIRC currently if both msdos and vfat are compiled in (not modules),
> and
>
> you try to mount a vfat filesystem without explicitly specifying the fs
> type, it will be mounted with the msdos type. With the, it will mounted
> vfat.
>
But since filesystem detection isn't handled in the kernel, changing the
link order is pointless. Please fix your /etc/filesystems instead.
~# grep camera /etc/fstab
/dev/sda1 /mnt/camera auto users,noauto 0 0
~# strace -o mount.trace mount /mnt/camera
~# grep filesystems mount.trace
open("/etc/filesystems", O_RDONLY|O_LARGEFILE) = 3
~# cat /etc/filesystems
ext2
ext3
nodev proc
nodev devpts
iso9660
reiserfs
vfat
udf
Also check man 8 mount, specifically option -t:
[...] Creating a file /etc/filesystems can be useful to change the probe
order (e.g., to try vfat before msdos) ...
This is from man-pages 1.66, btw.
Regards,
Nuno
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
On 02/07/2005 09:36 AM, Al Viro wrote:
> On Mon, Feb 07, 2005 at 12:21:08AM +0100, Pozsar Balazs wrote:
>
>>On Sun, Feb 06, 2005 at 07:06:59AM +0000, Christoph Hellwig wrote:
>>
>>>On Sun, Feb 06, 2005 at 12:33:43AM -0500, John Richard Moser wrote:
>>>
>>>>I dunno. I can never understand the innards of the kernel devs' minds.
>>>
>>>filesystem detection isn't handled at the kerne level.
>>
>>Yeah, but the link order could be changed... Patch inlined.
>
>
> And just what does the link order (or changes thereof) have to do with that?
because some distributions (eg gentoo) make a symlink to /proc/filesystems
jupiter root # ls -l /etc/filesystems
lrwxrwxrwx 1 root root 19 Oct 25 11:18 /etc/filesystems ->
../proc/filesystems
and then its impossible to change the order. (unless you make a "hand
made" file of course).
- --
[ Clemens Schwaighofer -----=====:::::~ ]
[ TBWA\ && TEQUILA\ Japan IT Group ]
[ 6-17-2 Ginza Chuo-ku, Tokyo 104-0061, JAPAN ]
[ Tel: +81-(0)3-3545-7703 Fax: +81-(0)3-3545-7343 ]
[ http://www.tequila.co.jp http://www.tbwajapan.co.jp ]
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.6 (GNU/Linux)
Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org
iD8DBQFCBxBLjBz/yQjBxz8RAsCXAKCHwURn6UJjrtEOhjaXHa0min94NQCdFlBa
EgBrVpGuASFNepZigjV1p5E=
=ol2B
-----END PGP SIGNATURE-----
On Mon, Feb 07, 2005 at 02:48:00AM +0000, Nuno Monteiro wrote:
>
> On 2005.02.07 00:42, Pozs?r Bal?zs wrote:
> >On Mon, Feb 07, 2005 at 12:36:10AM +0000, Al Viro wrote:
> >> On Mon, Feb 07, 2005 at 12:21:08AM +0100, Pozsar Balazs wrote:
> >> > On Sun, Feb 06, 2005 at 07:06:59AM +0000, Christoph Hellwig wrote:
> >> > > filesystem detection isn't handled at the kerne level.
> ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
> But since filesystem detection isn't handled in the kernel, changing the
> link order is pointless. Please fix your /etc/filesystems instead.
But the contents of /proc/filesystems comes from the kernel. And the
order of filesystems comes from the link order.
Let me show you, why it is _not_ pointless:
If you do not have /etc/filesystems, mount will read /proc/filesystems:
# strace -o mount.trace mount -t auto /dev/sda1 /mnt
# grep filesystems mount.trace
open("/etc/filesystems", O_RDONLY|O_LARGEFILE) = -1 ENOENT (No such file or directory)
open("/proc/filesystems", O_RDONLY|O_LARGEFILE) = 3
# grep ^mount mount.trace
mount("/dev/sda1", "/mnt", "squashfs", 0xc0ed0000, 0) = -1 EINVAL (Invalid argument)
mount("/dev/sda1", "/mnt", "vfat", 0xc0ed0000, 0) = 0
See? I _have_ that patch applied, that's why it tried vfat and not msdos
first.
Granted, I could override the default order by using a /etc/filesystems
file. But the kernel should have a much more sane default on its own,
namely "try vfat before msdos".
--
pozsy
On Mon, Feb 07, 2005 at 03:53:00PM +0900, Clemens Schwaighofer wrote:
> >>Yeah, but the link order could be changed... Patch inlined.
> >
> > And just what does the link order (or changes thereof) have to do with that?
>
> because some distributions (eg gentoo) make a symlink to /proc/filesystems
>
> jupiter root # ls -l /etc/filesystems
> lrwxrwxrwx 1 root root 19 Oct 25 11:18 /etc/filesystems ->
> ../proc/filesystems
>
> and then its impossible to change the order. (unless you make a "hand
> made" file of course).
Ah, I had not met this particular form of brokenness before.
If one does not specify a filesystem type to mount,
mount will try its own collection of heuristics, looking for
known magic numbers. This stuff comes in two versions, depending
on whether mount was linked against the blkid library or not.
When no magic is recognized, mount will try all filesystems
listed in /proc/filesystems that were not rejected already
because of wrong magic. The list in /proc/filesystems can
be overridden by the file /etc/filesystems. That is useful
for two reasons: (i) sometimes the kernel crashes when one
tries to mount something with the wrong type, so
/etc/filesystems can skip the types that must never be tried,
and (ii) sometimes several types would succeed (e.g. msdos/vfat)
and the user can override the kernel order.
Making a symlink /etc/filesystems -> /proc/filesystems is
meaningless.
By the way, it is best to consider the kernel order as undefined.
It plays a role when mounting the rootfs. If you get undesirable
results at boot time, specify the rootfstype= boot option.
It plays a role when generating /proc/filesystems.
If you get undesirable results, adapt /etc/filesystems.
It is not true that vfat is universally better than msdos.
Some need one, some need the other.
Instead of having a global order, one can have a per-mountpoint
list in /etc/fstab. For example,
/dev/foo /mnt ext2,msdos noauto 0 0
Finally, guessing is always bad. It is convenient in the short run
but may lead to crashes and data loss in the long run.
Andries
On Mon, Feb 07, 2005 at 12:29:14PM +0100, Andries Brouwer wrote:
> and (ii) sometimes several types would succeed (e.g. msdos/vfat)
> and the user can override the kernel order.
But we are talking about the default order.
> By the way, it is best to consider the kernel order as undefined.
But it is not undefined, and if it is a well-defined order (and it is),
then it should have a sane order.
> It is not true that vfat is universally better than msdos.
> Some need one, some need the other.
> Finally, guessing is always bad. It is convenient in the short run
> but may lead to crashes and data loss in the long run.
Well, it can be bad, maybe it should be avoided. But if someone wants
guessing, why not provide him a (imho) more reasonable order of
guessing? I do think vfat should be tried first. If you are doing for
example some kind of recovery you wont bet on autoguessing. But if you
just want to use it, use might, and in that case you want long
filenames, ie vfat.
--
pozsy
Am 2005-02-07 09:47:09, schrieb Pozs?r Bal?zs:
> See? I _have_ that patch applied, that's why it tried vfat and not msdos
> first.
With this, you will nerver mount a Filesystem "msdos".
Because "vfat" IS "msdos" + "lfn".
You can attach to ALL "msdos" media "lfn" and you will have "vfat".
> Granted, I could override the default order by using a /etc/filesystems
> file. But the kernel should have a much more sane default on its own,
> namely "try vfat before msdos".
This will give many errors here at work...
Greetings
Michelle
--
Linux-User #280138 with the Linux Counter, http://counter.li.org/
Michelle Konzack Apt. 917 ICQ #328449886
50, rue de Soultz MSM LinuxMichi
0033/3/88452356 67100 Strasbourg/France IRC #Debian (irc.icq.com)
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
On 07.02.2005 20:29, Andries Brouwer wrote:
> Making a symlink /etc/filesystems -> /proc/filesystems is
> meaningless.
well to be honest, I didn't even know Gentoo makes a symlink here, but
I'll definitly will make bug entry for that.
Perhaps its a default setting. eg Debian doesn't have a /etc/filesystems
file by defauly anyway.
> It is not true that vfat is universally better than msdos.
> Some need one, some need the other.
but to be honest, most times I need vfat, and I actually haven't
encountered a time when I need msdos.
lg, clemens
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.1 (MingW32)
Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org
iD4DBQFCB3RpjBz/yQjBxz8RAlQBAJjj0IIhxCPWvWinMpi6J5UOJ9bBAJ9oQnI4
A6sIi+MzKiFbvpLIiQI1YQ==
=rmlN
-----END PGP SIGNATURE-----
On 2005.02.07 08:47, Pozs?r Bal?zs wrote:
> On Mon, Feb 07, 2005 at 02:48:00AM +0000, Nuno Monteiro wrote:
> >
>
> But the contents of /proc/filesystems comes from the kernel. And the
> order of filesystems comes from the link order.
>
Yes, but /proc/filesystems is only processed after two other checks have
failed first: specifying a filesystem type (-t), and reading /etc/
filesystems. Relying on mount to do the guesswork is asking for trouble
if you realy value your data. And /etc/filesystems is the mechanism mount
(8) has in place to change the probe order, in case you really want that.
This is entirely a userspace problem, the kernel shouldn't have anything
to do with it.
But, anyway, for the sake of argument let's suppose link order is
effectively changed. You just effectively broke people's working setups,
because like you want to rely on fs/ link order to mount your vfats as
vfat and not as msdos, there's people out there relying on that (broken)
assumption to have their msdos filesystems mounted as msdos. Now, with
the new link order, they'll be mounted as vfat, and pop-goes-the-weasel.
Tomorrow, someone unhappy that their msdos fs is now mounted as vfat will
send a patch changing it back, thus breaking vfats. Rinse, repeat. ;-)
See? This is just wrong. This is why mount(8) has a mechanism to change
the probe order. Everybody's happy that way, and no one has to rely on
the broken assumption that the kernel knows how you want your filesystems
mounted.
So, to sum things up: this is entirely an userspace problem. Yours just
appears to be in need of fixing or tuning.
Regards,
Nuno
Michelle Konzack schrieb:
> Am 2005-02-07 09:47:09, schrieb Pozs?r Bal?zs:
> > See? I _have_ that patch applied, that's why it tried vfat and not msdos
> > first.
>
> With this, you will nerver mount a Filesystem "msdos".
>
> Because "vfat" IS "msdos" + "lfn".
>
> You can attach to ALL "msdos" media "lfn" and you will have "vfat".
So msdos is vfat WITHOUT lfn, which is a a restriction like noatime
or mounting ext3 as ext2.
That's why the default should be vfat indeed and the restriction should be
"nolfn", which will not allow lfns to be created and is what you actually
intend, right?
But this will break API today, so it should be added to list of
features that will change.
Regards
Ingo Oeser
Clemens Schwaighofer <[email protected]> said:
[...]
> but to be honest, most times I need vfat, and I actually haven't
> encountered a time when I need msdos.
But writing MSDOS on a VFAT filesystem is a sure way to screw it up, and
AFAIU vice-versa.
--
Dr. Horst H. von Brand User #22616 counter.li.org
Departamento de Informatica Fono: +56 32 654431
Universidad Tecnica Federico Santa Maria +56 32 654239
Casilla 110-V, Valparaiso, Chile Fax: +56 32 797513
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
On 02/08/2005 09:23 AM, Horst von Brand wrote:
> Clemens Schwaighofer <[email protected]> said:
>
> [...]
>>but to be honest, most times I need vfat, and I actually haven't
>>encountered a time when I need msdos.
>
> But writing MSDOS on a VFAT filesystem is a sure way to screw it up, and
> AFAIU vice-versa.
well it doesn't screw it up if you write MS DOS on a VFAT, you just
loose a lot of data.
I was kinda surprised when I came home and plugged in my USB stick to
see just A3.CB instead of a nice long filename :)
- --
[ Clemens Schwaighofer -----=====:::::~ ]
[ TBWA\ && TEQUILA\ Japan IT Group ]
[ 6-17-2 Ginza Chuo-ku, Tokyo 104-0061, JAPAN ]
[ Tel: +81-(0)3-3545-7703 Fax: +81-(0)3-3545-7343 ]
[ http://www.tequila.co.jp http://www.tbwajapan.co.jp ]
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.6 (GNU/Linux)
Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org
iD8DBQFCCCLljBz/yQjBxz8RAvgyAJ4zRyjszLLuBeZz5lBAyegCTbm1ygCfYf2E
UJKEEU0HJuLRTAjec3aEQ3s=
=g+L4
-----END PGP SIGNATURE-----
Followup to: <[email protected]>
By author: =?iso-8859-1?Q?Pozs=E1r_Bal=E1zs?= <[email protected]>
In newsgroup: linux.dev.kernel
>
> Granted, I could override the default order by using a /etc/filesystems
> file. But the kernel should have a much more sane default on its own,
> namely "try vfat before msdos".
>
What it really means is that mount(8) should know this is a special
case; presumably it already knows to try ext3 over ext2.
-hpa