public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
From: Michael Tokarev <mjt@tls.msk.ru>
To: Kernel Mailing List <linux-kernel@vger.kernel.org>
Subject: data corruption: revalidating a (removable) hdd/flash on re-insert
Date: Fri, 31 Oct 2008 18:38:01 +0300	[thread overview]
Message-ID: <490B2659.9010304@msgid.tls.msk.ru> (raw)

To make a long story short: is there a way to force kernel
to re-validate a replaced usb-connected hard drive (or a
flash) *automatically*?

Because right now, the kernel does not see that the drive
has been replaced, and uses *some* old cached values, which
results in random data corruption here and there, and other
similar odd things.

For example, I've an USB flash reader (Carry Computer Eng.,
Co., Ltd 6-in-1 Card Reader, but that's not really relevant).
Among other things it has a compact flash slot.  And I've
2 differently-size CF cards.

So I turn the machine on, insert one CF card, mount it, do
something with its vfat filesystem, umount it and remove
it.  Next I insert another card, and when trying to mount
it, the kernel says:

FAT: invalid media value (0x1e)
VFS: Can't find a valid FAT filesystem on dev sdb1.

When trying to run cfdisk for example, it complains that
"partition 0 ends after end of the drive" (or something
similar).

Sometimes the mount succeeds, but there are all sorts of
errors here in there, the filesystem is messed up, whith
parts of the files "from" just-removed card, and parts
from the new card.

And sure enough, when I, forgetting the issue, trying
to WRITE something to the card, it becomes almost 100%
messy...

What helps is to run, for example,

  blockdev --rereadpt /dev/sdb

manually, after replacing the card.

The first thing I was thinking of when saw the whole mess
is: there must be some process like hald/udev/whatever
messy subsystem du jur, which holds the device node open
and prevents the kernel from re-reading the drive by its
own as it correctly did in the past.  Nope, I've shut down
everything, and the same happens when only shell process
running INSTEAD of init (booting with init=/bin/sh option).

So at some point the kernel stopped noticing the drive
change in this configuration some time ago.  I can't say
when exactly, since I didn't use the card reader for over
a year, and certainly didn't try it with more than one
card in a row for even longer time.   It worked in the
past, that's for sure.  And it definitely does not work
(resulting in the above mess) with 2.6.25, 2.6.26 and 2.6.27.

Help?

Thanks!

/mjt

             reply	other threads:[~2008-10-31 15:38 UTC|newest]

Thread overview: 14+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2008-10-31 15:38 Michael Tokarev [this message]
2008-10-31 15:59 ` data corruption: revalidating a (removable) hdd/flash on re-insert Lennart Sorensen
2008-10-31 16:10   ` Michael Tokarev
2008-10-31 18:28     ` Lennart Sorensen
2008-10-31 16:10 ` Kay Sievers
2008-10-31 17:39   ` Michael Tokarev
2008-10-31 18:49     ` Kay Sievers
2008-11-04 19:57   ` Pavel Machek
2008-11-04 20:13     ` Kay Sievers
2008-11-04 20:20       ` Pavel Machek
2008-11-04 21:22         ` Michael Tokarev
2008-11-04 21:28           ` Pavel Machek
2008-11-05  8:04             ` Michael Tokarev
2008-11-05  0:29           ` Kay Sievers

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=490B2659.9010304@msgid.tls.msk.ru \
    --to=mjt@tls.msk.ru \
    --cc=linux-kernel@vger.kernel.org \
    /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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox