Re: USB stick access freezing up system?

Begin <fj6bul$dj$2@xxxxxxxxxxxxxxxxxxxxxxx>
On 5 Dec 2007 14:17:57 GMT, Richard Tobin <richard@xxxxxxxxxxxxxxx> wrote:
In article <slrnfld340.lee.read_the_sig@xxxxxxxxxxxxxx>,
jpd <read_the_sig@xxxxxxxxxxxxxxxxxxxxxx> wrote:

I'm also confused why FreeBSD panics when the stick is removed. I
would expect the application to fail, but the stick is just a mount in
the app's directory tree, nothing essential...

You know that but your system does not know that. FreeBSD does not make
a distinction between disks and flash, or cds, or whatever. A mount is a
mount. If the reader could signal the event you could set it up so that
it'll force-unmount the disk, but you risk data loss and even filesystem
corruption that way.

How can it corrupt a filesystem on a device that's been removed? Or
did you mean corrupt some other filesystem (surely not).

Removing a device will probably result in data loss and perhaps
corruption of its filesystem, but panic()ing rather than forced
unmounting does nothing not fix that.

I was talking about losing partial writes and metadata problems. Of
course, the medium itself won't be available for further scribbling, but
what if your medium happens to need signals from the hardware to finish
up a session? This is not unheard of. Drives might need parking[1], CDs
might need their session closed[2], etc.

As to the rest of the storage, probably not directly, but ``surely not''
is an assumption that you can't prove to be true for all cases. I could
conceive of side effects, programs concluding to go on and scribble
elsewhere, causing inconsistencies and whatnot. Far-fetched but again
not inconceivable. Reparability of that I won't speculate on.


So I guess you must just mean that it would be bad to get in the habit
of unplugging devices because you can get away with it, but I don't
see panic()ing as an appropriate way to discourage that.

You'd be guessing wrong. As currently setup, removing storage without
unmounting is a very clear no-no, but it's not done just to discourage
people from doing it.


[1] I have transported an MFM disk that had not been parked with the
proper utility before powering down. Damage had resulted.
This was on an old XT running DOS.
[2] CD burners usually lock their tray while busy, but that is besides
the point. They need that peace and quiet to do their thing.

--
j p d (at) d s b (dot) t u d e l f t (dot) n l .
This message was originally posted on Usenet in plain text.
Any other representation, additions, or changes do not have my
consent and may be a violation of international copyright law.
.

Relevant Pages

  • Re: multi volume with tar
    ... a disk definitely won't result in a filesystem-like structure. ... won't mount that floppy. ... You *never* write to the raw device node of a mounted filesystem ... because writing directly to the device mangled the ...
    (comp.os.linux.misc)
  • Re: e2fsck prog errors, bad HD, or am I a bonehead?? Help!
    ... >corruption, which means you lose random data on the disk. ... It is possible to just run fsck with the filesystem ...
    (comp.os.linux.hardware)
  • Hints for precision benchmarking...
    ... and run into the usual problem of noisy data preventing any ... * Don't mount filesystems you do not need. ... This removes atime updates to disk from your I/O picture. ... This results in a consistent filesystem layout. ...
    (freebsd-current)
  • Re: having trouble mounting disk image on loopback device
    ... a dd image taken from a physical disk. ... Therefore, to mount each partition, I used these commands: ... mount command will not suffice...For that matter, ... The device must contain a filesystem recognizable ...
    (comp.os.linux.misc)
  • Re: mount --bind question.
    ... I would *highly* suggest more than two partitions; ... something specific for whatever disk space you have left. ... >back into the right place in the filesystem through symlinks in the root ... but I'm wondering if it would be better to use mount ...
    (comp.os.linux.misc)