Linux-kernel mailing list archive 1999-37,: Re: strange mounting problem

# Re: strange mounting problem

Andreas Tobler (toa@pop.agri.ch)
Thu, 16 Sep 1999 23:53:09 +0200

- Messages sorted by: [ date ][ thread ][ subject ][ author ]
- Next message: Arthur: "Re: cannot login after 2.3.18ac4"
- Previous message: Theodore Y. Ts'o: "Re: Ext3 filesystem info?"
- Maybe in reply to: Andreas Tobler: "strange mounting problem"

Hi,

thanks for your participation.
Right now I'm limited to follow your wishes. The machine, espescially
the drive is overheated. I 'll send you the info's you'll wanted.
Also I have the strace's at hand.

But this will follow tomorrow in the aftenoon since I have to follow
other things...

But, why is it not so strange 'hfs' ??

Well, one point I HAVE to say, when you take a fully SCSI-REV 2 dev then
it works !!
Only on my old MO it gives such strange behaves like that.
The other MO for comparisons works ok.

Thanks anyway

Andreas

Guest section DW wrote:
>
> From: Andreas Tobler <toa@pop.agri.ch>, reporting on a kernel cache bug:
>
> when mounting the device with the fstab mountpoint, the mount command
> takes the entry from there about fs. In my case ext2. So it doesn't
> really check if it is so.
>
> when mounting with /dev/sdc <mountpoint> mount takes 'hfs' for the
> default fs entry. ?? Hfs_fs checks that there is NO hfs fs. So I imagine
> that the original entry about my Aside is flushed.
>
> OK. That mount comes with "hfs" is not so strange:
> ---------------------------------------------------------------------
> Correct use of mount is via "mount device mountpoint -t type".
> Since people are lazy, abbreviations like "mount device"
> or "mount mountpoint" or "mount device mountpoint"
> are accepted in case mount can guess what you may have meant.
>
> But the only sure use of mount is the full "mount device mountpoint -t type".
>
> How does the guessing work?
> If you specified only one of device and mountpoint, then the other,
> and the type, are found in /etc/fstab. If you specify device and
> mountpoint but not the type, or when /etc/fstab contains the type "auto",
> then mount guesses the type. First it looks for well known magic numbers.
> It knows such numbers for minix, ext, ext2, xiafs, iso9660, romfs,
> ufs, ntfs, qnx4, bfs. [PLUG: magic recognition for other fss is welcome.]
> If the magic is recognized, the corresponding type is tried.
> If no well-known magic is found, mount tries a mount system call, with
> as type each of the filesystem types found in /etc/filesystems in turn.
>
> If you compiled hfs in the kernel, or have a hfs module loaded, then also
> hfs will be tried.
> ---------------------------------------------------------------------
>
> A new mount with a cartridge in is the successful because the the
> previous entry about the Aside is away.
>
> As told by Andries, mount is not kernel related?. my mount has version 2.9o
> So where do I ask or is this place still ok?
>
> mount-2.9o is OK - quite recent in fact; we have mount-2.9x today.
> This place is also OK. You are reporting a serious kernel bug somewhere,
> namely that the cache is not invalidated when you remove and reinsert
> this MO disk, and only try to mount it as ext2.
>
> Then you come with a side remark that if mount tries a whole lot of filesystems
> then after all that the cache *is* invalidated. Since that is correct behaviour
> it is less interesting.
>
> Do you see messages like
> VFS: Disk change detected on device ...
> in syslog or on the console?
>
> > > There may well be a kernel bug somewhere here,
> > > where perhaps check_media_change is not done right.
>
> > MO-C1716T
> > ---------
> >
> > kernel 2.2.13pre8
> > platform LinuxPPC1999
> >
> ...
> > ----------------------------------------------
> > the same sequence is done via the fstab entry:
> > ----------------------------------------------
> > /dev/sdc /mnt/Aopto ext2 noauto 0 0
> >
> > cartridge in A-side:
> > --------------------
> > mount /mnt/Aopto
> > cd Aopto
> > ls -> ASIDE
> > cd ..
> > umount /mnt/Aopto
> > eject /mnt/Aopto
> >
> > cartridge out:
> > --------------
> > mount /mnt/Aopto
> >
> > pm7200 kernel: SCSI disk error : host 1 channel 0 id 5 lun 0 return code = 8000000
> > pm7200 kernel: [valid=0] Info fld=0x0, Current sd08:20: sense key Not Ready
> > pm7200 kernel: Additional sense indicates Medium not present
> > pm7200 kernel: scsidisk I/O error: dev 08:20, sector 2
>
> And what is the mount error? Or does the mount succeed?
> "cat /proc/mounts" shows the newly mounted device?
> Since the mount call does a read_super(), this can only work if this block is still in cache.
>
> > umount /mnt/Aopto
> >
> > pm7200 kernel: SCSI disk error : host 1 channel 0 id 5 lun 0 return code = 8000000
> > pm7200 kernel: [valid=0] Info fld=0x0, Current sd08:20: sense key Not Ready
> > pm7200 kernel: Additional sense indicates Medium not present
> > pm7200 kernel: scsidisk I/O error: dev 08:20, sector 2
>
> > mount /mnt/Aopto
> >
> > pm7200 kernel: SCSI disk error : host 1 channel 0 id 5 lun 0 return code = 8000000
> > pm7200 kernel: [valid=0] Info fld=0x0, Current sd08:20: sense key Not Ready
> > pm7200 kernel: Additional sense indicates Medium not present
> > pm7200 kernel: scsidisk I/O error: dev 08:20, sector 2
> > pm7200 kernel: EXT2-fs: unable to read superblock
> > mount: wrong fs type, bad option, bad superblock on /dev/sdc
> > or too many mounted file systems
>
> Very strange.. This is the EINVAL error return, not the EIO error that I expected.
>
> > unmount /mnt/Aopto
> > umount: /mnt/Aopto/: not mounted
>
> > cartridge in B-side:
> > --------------------
> > mount /mnt/Bopto
> > cd Bopto
> > ls -> ASIDE <---------WRONG it is physically BSIDE
> > cd ..
> > umount /mnt/Bopto
> > eject /mnt/Bopto
>
> Yes, so you see the cache problems after turning the cartridge,
> but already the fact that the mount without cartridge succeeds is very bad.
>
> Let me leave it at this - I have no time right now to fetch 2.2.13pre8
> and look at the source. Maybe later if no-one else does it.
> Can you confirm that the mount without cartridge succeeded?
>
> Andries
>
> -
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to majordomo@vger.rutgers.edu
> Please read the FAQ at http://www.tux.org/lkml/

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu
Please read the FAQ at http://www.tux.org/lkml/

- Next message: Arthur: "Re: cannot login after 2.3.18ac4"
- Previous message: Theodore Y. Ts'o: "Re: Ext3 filesystem info?"
- Maybe in reply to: Andreas Tobler: "strange mounting problem"