Date: Fri, 24 Feb 2012 09:23:53 -0700 From: Ian Lepore <freebsd@damnhippie.dyndns.org> To: Erich Dollansky <erichfreebsdlist@ovitrap.com> Cc: freebsd-stable@freebsd.org, Stefan Bethke <stb@lassitu.de> Subject: Re: random problem with 8.3 from yesterday Message-ID: <1330100633.7317.41.camel@revolution.hippie.lan> In-Reply-To: <201202241350.56933.erichfreebsdlist@ovitrap.com> References: <201202221334.36484.erich@alogreentechnologies.com> <64FF3DF7-6EEA-480D-85AA-5784AF013EA8@lassitu.de> <201202241350.56933.erichfreebsdlist@ovitrap.com>
next in thread | previous in thread | raw e-mail | index | archive | help
On Fri, 2012-02-24 at 13:50 +0700, Erich Dollansky wrote:
> Hi,
>
> On Thursday 23 February 2012 20:22:57 Stefan Bethke wrote:
> > Am 22.02.2012 um 07:34 schrieb Erich Dollansky:
> >
> > >
> > > tunefs -L NewDeviceName /dev/da0a
> > >
> > > Either this call or the mount command does not work randomly.
> > >
> > > When I then try to mount the device on /dev/da0a it does not work always.
> > >
> > > I do not know what this causes, I am only randomly able to reproduce it.
> > >
> > > It might be affected by removing the device or keeping it plugged in.
> >
> > You need to be more specific: what "does not work" mean? Output, results?
> >
> it seems that I forgot to copy the console output for this.
>
> Ok, as far as I remember, tunefs said something like it does not recognise the slice.
>
> Mount has had two different messages. One also said that it could not find/recognise the slice. The other one said that the file system was unknown despite just running a newfs on it.
>
> I am very much aware that this kind of errors are very hard to find especially if they are not reproduceable.
>
> Erich
>
> >
> > Stefan
> >
> > --
> > Stefan Bethke <stb@lassitu.de> Fon +49 151 14070811
I've been putting up with problems like this since first upgrading to
8.2. I guess I haven't dug deeper into them because it's actually a
huge improvement from what I was used to in 6.x and 7.x where complete
system lockups were more common with removable usb drives. Here's an
example sequence that just happened to me with a compact flash card in a
usb multi-card reader...
revolution # ll /dev/da*
crw-r----- 1 root operator 0, 246 Feb 24 08:21 /dev/da0
crw-r----- 1 root operator 1, 26 Feb 24 08:21 /dev/da0s1
crw-r----- 1 root operator 1, 39 Feb 24 08:21 /dev/da0s1a
crw-r----- 1 root operator 1, 40 Feb 24 08:21 /dev/da0s1e
crw-r----- 1 root operator 1, 27 Feb 24 08:21 /dev/da0s2
crw-r----- 1 root operator 1, 29 Feb 24 08:21 /dev/da0s2a
crw-r----- 1 root operator 1, 30 Feb 24 08:21 /dev/da0s2e
crw-r----- 1 root operator 1, 28 Feb 24 08:21 /dev/da0s3
crw-r----- 1 root operator 1, 32 Feb 24 08:21 /dev/da0s3a
crw-r----- 1 root operator 0, 248 Feb 23 12:01 /dev/da1
crw-r----- 1 root operator 0, 249 Feb 23 12:01 /dev/da2
crw-r----- 1 root operator 0, 250 Feb 23 12:01 /dev/da3
crw-r----- 1 root operator 1, 44 Feb 24 08:54 /dev/da4
revolution # mount /dev/da0s1a /mnt
mount: /dev/da0s1a : Invalid argument
revolution # fsck -y /dev/da0s1a
fsck: Could not determine filesystem type
revolution # fsck -t ufs -y /dev/da0s1a
** /dev/da0s1a
Cannot find file system superblock
ioctl (GCINFO): Inappropriate ioctl for device
fsck_ufs: /dev/da0s1a: can't read disk label
At this point I unplug the multi-card reader and plug it back in.
revolution # fsck -y /dev/da0s1a
fsck: Could not determine filesystem type
revolution # fsck -t ufs -y /dev/da0s1a
** /dev/da0s1a
** Last Mounted on /
** Phase 1 - Check Blocks and Sizes
** Phase 2 - Check Pathnames
** Phase 3 - Check Connectivity
** Phase 4 - Check Reference Counts
** Phase 5 - Check Cyl groups
1932 files, 45569 used, 385214 free (54 frags, 48145 blocks,
0.0% fragmentation)
***** FILE SYSTEM IS CLEAN *****
revolution # mount /dev/da0s1a /mnt
At this point everything is fine and I can access the card. Sometimes I
have to do the unplug/replug dance and sometimes I don't. I've always
suspected something in the geom layer isn't noticing that a CF or SD
card in the reader got removed/inserted/reformatted, and un-/re-plugging
the whole reader (making the cam layer destroy and recreate the devices)
makes geom aware of the change.
Oh, a datapoint... notice how the timestamps on the /dev/da0* files
above are all 08:21? I had just inserted that card at 08:57 when I ran
the command sequence above, but apparently the geom layer was still
reporting on a different card that was used and removed earlier this
morning.
I'm not sure whether or not this is related to the problem Erich
originally reported, but there are some similarities in symptoms such as
the inability to recognize the filesystem type, so I thought I'd mention
it. This happens to me several times a week (often several times a day)
so if anyone has suggestions on information-gathering I'll probably have
lots of opportunities.
-- Ian
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?1330100633.7317.41.camel>