Re: [RFC] mount can figure out fstype automatically

On Sat, Jul 08, 2006 at 12:57:21PM -0600, Scott Long wrote:
Craig Rodrigues wrote:

On Sat, Jul 08, 2006 at 09:05:51AM -0700, Sam Leffler wrote:
Linux has -t auto; haven't looked at how it works.
I didn't want to implement -t auto, in
case that would confuse things in case someone gets around
to implementing autofs for FreeBSD, so I just used -t "".
It appears you just try a series of fs types; can't you read the device
to infer the filesystem?
I was thinking of doing something like that. You can basically
get the same info by doing something like:
file - < /dev/ad0s1e
/dev/stdin: Unix Fast File system (little-endian)
file - < /dev/ad0s4
/dev/stdin: SGI XFS filesystem
I leaned away from this approach in mount(8) because:
- I didn't want to tie mount(8) to file(1)
- I didn't want to build up a table of known superblocks
inside mount(8) because every time a new filesystem is
added to FreeBSD, mount(8) would need to be updated
If there was a way, maybe at the GEOM or filesystem level to
"taste" what type of filesystem existed on a device, and/or
have a filesystem advertise what type of superblock it has,
then that would be a nice way to do it, but I couldn't figure
out a way to easily do it.

Well, by running through a list of possible filesystems and trying
each one, you are effectively 'tasting' them. In a brute force way,
but still the exact same idea. [...]

One thing I don't like about this idea, is that simple mount(8) command
will load all file system kernel modules if we give for example device
with no file system on it.
Currently I think there is no way to tell from userland mount(8) that
because of our call, the kernel has loaded file system module.
We could load it from mount(8) instead of waiting for the kernel to do
it and then unload if we don't such such file system on the given
device...

[...] But really, it's not like filesystems
are sprouting up every day, so I don't see the need to spend a lot of
time making this elegant and highly extensible.

What Craig was trying to do over the last few weeks/months was to remove
file systems specific code out of mount(8), so this will be a step
backwards, I think...

--
Pawel Jakub Dawidek http://www.wheel.pl
pjd@xxxxxxxxxxx http://www.FreeBSD.org
FreeBSD committer Am I Evil? Yes, I Am!

Attachment: pgpzpglJu6Ibl.pgp
Description: PGP signature

Relevant Pages

  • Re: [linux-pm] Re: Hibernation considerations
    ... filesystem you're dealing with. ... >>> the work of the second kernel. ... > the current suspend projects. ... I would argue writing to existing blocks of a file (not thorugh the filesystem, just getting their blocsk from the file system) should be safe, but it occurs to me that may not be the case if your fsck and bmap move data blocks from some update log to the file system. ...
    (Linux-Kernel)
  • Re: FreeBSD Locked Up
    ... > Is this because FreeBSD doesn't use a journalling filesystem? ... inevitable if the file system is dirty. ...
    (freebsd-questions)
  • Filesystem turns read-only for no reason.
    ... figure out the reason. ... A filesystem would suddenly go 'read-only' ... it will say 'read-only file system', ... I have upgraded to Redhat EL4 with a 2.6 kernel. ...
    (comp.os.linux.misc)
  • SUMMARY: how do I REALLY delete a file?
    ... leaving the rest of the file system intact. ... Wipedrive doesn't seem to be available for Solaris, but might be of interest to ... run this on each filesystem where the files from ... >Solaris' UFS] do not satisfy this assumption." ...
    (SunManagers)
  • Re: GEOM portable filesystem abstraction?
    ... >> can write the reverse engineered NTFS filesystem. ... I'd think most file system developers have their hands ... closely integrates with other sections of the kernel impedes portability. ... > real file system on it, it should work on FreeBSD, Linux, and Solaris. ...
    (freebsd-current)