SEO

I have a usb mp3 player that mounts as:
mount -t msdos /dev/sdb1 /mp3player

After such a mounting I stupidly disconnected the player without
umounting the device. Thereafter I couldn't re-connect the
player, or anything else on the usb port.

I was able to recover by restoring my complete /etc directory
from backup, but there has to be a simpler way. I think it
has to do with mtab, but just restoring that file isn't
the trick.


What is the correct method of recovery after a disconnect without
umounting?

I am running Slack 10.2 with a 2.6.16 kernel.

TIA

root <NoEMail@home.org> wrote:
> I have a usb mp3 player that mounts as:
> mount -t msdos /dev/sdb1 /mp3player
>
> After such a mounting I stupidly disconnected the player without
> umounting the device. Thereafter I couldn't re-connect the
> player, or anything else on the usb port.
>
> I was able to recover by restoring my complete /etc directory
> from backup, but there has to be a simpler way. I think it
> has to do with mtab, but just restoring that file isn't
> the trick.
>
>
> What is the correct method of recovery after a disconnect without
> umounting?
>
> I am running Slack 10.2 with a 2.6.16 kernel.
>
> TIA
>

I think I have figured out what happens when you disconnect
without umounting: you have an error in the file system
around the file /etc/mtab and the mount point.


When you mount a device your system keeps information about
the device in your file system. Upon umounting that device
your system writes that information back to the device
and releases the information from your system. Without
umounting that writeback doesn't occur and your file
system is corrupted. What you have to do is reboot the
system with a repair disk and run a file check on your
file system.

root (you wouldn't _really_ do things that don't require root privilege
as root, would you?) wrote:

> I was able to recover by restoring my complete /etc directory from
> backup, but there has to be a simpler way. I think it has to do with
> mtab, but just restoring that file isn't the trick.

See also /proc/mounts

I've never done what you're trying to recover from, so I'm not 100%
certain that you'll be able to do anything with that (virtual) file,
but it should give you the idea that you need to affect more than a
change to /etc/mtab.

> When you mount a device your system keeps information about
> the device in your file system.

Well, the system keeps a table of mounted file systems in the running
kernel. I'm quite certain that /etc/mtab exists primarily for the
convenience of the humans using the system. (and the umount command,
perhaps, though I'm surprised that doesn't just read /proc/mounts.)

> Upon umounting that device your system writes that information back
> to the device and releases the information from your system.

Almost: what it's writing to the disk at umount-time is any cached data
that were not yet written to the disk when the file system was in use.

> Without umounting that writeback doesn't occur and your file system
> is corrupted.

you're correct on this count. The more cached data that wasn't written,
the greater the file-system corruption. If the disk was mounted
read-only, for example, nothing will have changed on the filesystem
anyway, so there won't be any corruption, and you only need to convince
the system to unmount it. If the disk had synced before you prematurely
unplugged it, for example, it might also have very minimal file-system
corruption.

> What you have to do is reboot the system with a repair disk and run
> a file check on your file system.

You can fsck the file system without rebooting the system, but you need
to convince the system that the device that holds that filesystem isn't
already mounted. See the various options to umount for any that might
help (f?).

--
----------------------------------------------------------------------
Sylvain Robitaille syl@alcor.concordia.ca

Systems and Network analyst Concordia University
Instructional & Information Technology Montreal, Quebec, Canada
----------------------------------------------------------------------

root <NoEMail@home.org> wrote:
> I have a usb mp3 player that mounts as:
> mount -t msdos /dev/sdb1 /mp3player

Not a foolowup to your problem, but probably "-t vfat" will
work better (let's you preserve "long filenames" etc. without
disturbing the player itself.

> What is the correct method of recovery after a disconnect without
> umounting?

Rebooting mostly works well <grin>
--
************************************************** ******************
** Eef Hartman, Delft University of Technology, dept. EWI/TW **
** e-mail: E.J.M.Hartman@math.tudelft.nl, fax: +31-15-278 7295 **
** snail-mail: P.O. Box 5031, 2600 GA Delft, The Netherlands **
************************************************** ******************

Eef Hartman <E.J.M.Hartman@math.tudelft.nl> wrote:
> root <NoEMail@home.org> wrote:
>> I have a usb mp3 player that mounts as:
>> mount -t msdos /dev/sdb1 /mp3player
>
> Not a foolowup to your problem, but probably "-t vfat" will
> work better (let's you preserve "long filenames" etc. without
> disturbing the player itself.
>

The player is *msdos* and only sees 8.3 file names.

>> What is the correct method of recovery after a disconnect without
>> umounting?
>
> Rebooting mostly works well <grin>

Here is the really nasty thing that should be avoided. You can
go on for hours without realizing what you have done after
pulling the plug on the player. The next time you reboot
it may or may not cause an fsck. In my case I had file
corruption for several weeks, permeating throughout all
my sequence of backups.

root <NoEMail@home.org> wrote:
>Eef Hartman <E.J.M.Hartman@math.tudelft.nl> wrote:
>> root <NoEMail@home.org> wrote:
>>> I have a usb mp3 player that mounts as:
>>> mount -t msdos /dev/sdb1 /mp3player
>>
>> Not a foolowup to your problem, but probably "-t vfat" will
>> work better (let's you preserve "long filenames" etc. without
>> disturbing the player itself.
>>
>
>The player is *msdos* and only sees 8.3 file names.
>
>>> What is the correct method of recovery after a disconnect without
>>> umounting?
>>
>> Rebooting mostly works well <grin>
>
>Here is the really nasty thing that should be avoided. You can
>go on for hours without realizing what you have done after
>pulling the plug on the player. The next time you reboot
>it may or may not cause an fsck. In my case I had file
>corruption for several weeks, permeating throughout all
>my sequence of backups.

If that is so, one thing is clear: it isn't related
to your above question at all.

--
Floyd L. Davidson <http://www.apaflo.com/floyd_davidson>
Ukpeagvik (Barrow, Alaska) floyd@apaflo.com

root <NoEMail@home.org> wrote:
> The player is *msdos* and only sees 8.3 file names.

Mounted as "msdos" filenames will be CUTOFF to 8+3,
mounted as vfat unique 8+3 filenames will be created, just
like in Windows-9x (names like songnr~1.mp3, songnr~2.mp3).

Ok, there MAY be players around that don't like the "long"
filenames to be present too, but vfat _does_ have 8+3 filenames
too, as it is an extension to the old DOS (6.x and before) fs.

Example (I just tested on my own vfat memstick):
copying the files
SearchingForYou.mp3
SearchingSoLong.mp3
(ok, I did search for two songs that were identical in the first
8 chars) to the memory stick mounted as "vfat" gives the 8+3 names:
search~1.mp3
search~2.mp3
while, when I copy the same files again, mounted as "msdos" only
gives me a single file
searchin.mp3
--
************************************************** ******************
** Eef Hartman, Delft University of Technology, dept. EWI/TW **
** e-mail: E.J.M.Hartman@math.tudelft.nl, fax: +31-15-278 7295 **
** snail-mail: P.O. Box 5031, 2600 GA Delft, The Netherlands **
************************************************** ******************