You are not logged in.

#1 2007-01-29 04:00:51

_Pi
Member
From: CT
Registered: 2005-07-07
Posts: 26

USB Stick Woes.

Now I can see a reason for this, me being not the safest with my USB devices but I'm wondering why not include automatic, forced and full deregistering of usb devices when the plug is pulled out of the computer. As of current I'm too lazy to use ABS to build my own kernel so I'm just wondering why not include this just for comfort and my/other people's laziness, of not having to type:

mount /dev/sdb1 /mnt/stick
copy do work whatever.
umount /dev/sdb1
rmmod usb_storage (just for the "integrity" of your device)

And then pulling out the stick. If not do this automatically please just insert forced module unloading into the kernel so some of us aren't stuck with a reboot because we're too arrogant to type in a couple of commands into the console.

Uhh, is anyone with me?


Ehh by the way, I dunno if it's that way on the standard kernel but I'm using kernel26ck and I can tell you it's not.

Last edited by _Pi (2007-01-29 04:07:11)

Offline

#2 2007-01-29 10:25:02

iphitus
Forum Fellow
From: Melbourne, Australia
Registered: 2004-10-09
Posts: 4,927

Re: USB Stick Woes.

_Pi wrote:

Now I can see a reason for this, me being not the safest with my USB devices but I'm wondering why not include automatic, forced and full deregistering of usb devices when the plug is pulled out of the computer. As of current I'm too lazy to use ABS to build my own kernel so I'm just wondering why not include this just for comfort and my/other people's laziness, of not having to type:

mount /dev/sdb1 /mnt/stick
copy do work whatever.
umount /dev/sdb1
rmmod usb_storage (just for the "integrity" of your device)

There is no damage that can occur to your flash drive, and no danger in removing it before unloading the module. The reason why windows has "safely remove" -- is so that it can unmount it and make sure everything is written to the device, not to unload the driver.

Mounting and unmounting can be done in gnome and kde by their respective daemons, and outside of that, by ivman and other programs.

What you're attempting otherwise with loading and unloading of the module is really quite pointless.

James

Last edited by iphitus (2007-01-29 10:25:50)

Offline

#3 2007-01-29 11:48:28

T-Dawg
Forum Fellow
From: Charlotte, NC
Registered: 2005-01-29
Posts: 2,736

Re: USB Stick Woes.

why not include automatic, forced and full deregistering of usb devices when the plug is pulled out of the computer.

I think you're missing the point. When you issue commands to like cp to your flash drive, they are not necessarily executed at that time. It can be several seconds before the data is written. I believe the reasoning behind it is for performance -the data is cached in ram for quick retrieval then actually written at a better time. When you umount, you are forcing all pending data to be written to the disk at that time. I believe there is an option you can use in fstab called something like async to write the data on demand.

Offline

#4 2007-01-30 00:05:26

_Pi
Member
From: CT
Registered: 2005-07-07
Posts: 26

Re: USB Stick Woes.

You both missed the point. If I in my haste decide to rip my usb stick out, the device /dev/sdb and /dev/sdb1 are removed in udev but aren't removed in mount, and the usb_storage module doesn't get a responce when it probes the hardware and becomes busy, which can result in two things. Either the module is fine, and the next time I stick any usb storage device in it will turn to /dev/sdc or the module is busy with hardware that doesn't exist on the system physically and denies me the recognition of a different device, forcing me to reboot to fix the problem since force module unloading isn't in the kernel.

Basically my problem is laziness, but I'm just wondering why forced unloading and dynamic deregistering isn't in the kernel config.

Last edited by _Pi (2007-01-30 00:06:23)

Offline

#5 2007-01-30 00:38:03

brain0
Developer
From: Aachen - Germany
Registered: 2005-01-03
Posts: 1,382

Re: USB Stick Woes.

There is no way to make "ripping the USB stick out" without umounting work smoothly. You can mount it with the sync option to avoid data loss, but not umounting it will still result in weird effects.

Offline

#6 2007-01-30 01:08:27

_Pi
Member
From: CT
Registered: 2005-07-07
Posts: 26

Re: USB Stick Woes.

Last time I configured a kernel (3 months ago) on CRUX I made it work, there's a mount option for plug and play somewhere I forget where it is, but it would work if the kernel was configured for forced removal.

Offline

#7 2007-01-30 08:53:09

brain0
Developer
From: Aachen - Germany
Registered: 2005-01-03
Posts: 1,382

Re: USB Stick Woes.

_Pi wrote:

but it would work if the kernel was configured for forced removal.

What kernel option would that be?

Offline

#8 2007-01-30 09:13:09

iphitus
Forum Fellow
From: Melbourne, Australia
Registered: 2004-10-09
Posts: 4,927

Re: USB Stick Woes.

_Pi wrote:

You both missed the point. If I in my haste decide to rip my usb stick out, the device /dev/sdb and /dev/sdb1 are removed in udev but aren't removed in mount, and the usb_storage module doesn't get a responce when it probes the hardware and becomes busy, which can result in two things. Either the module is fine, and the next time I stick any usb storage device in it will turn to /dev/sdc or the module is busy with hardware that doesn't exist on the system physically and denies me the recognition of a different device, forcing me to reboot to fix the problem since force module unloading isn't in the kernel.

Or, you could use it as you should correctly and unmount. You don't remove PCI cards and system memory without shutting down the system, why improperly remove usb devices?

Crux did not operate how you are describing. If it did, that's a hideous hideous hack.

And if you remove a device without unmounting, there's no need to reboot. Just unmount the directory.

Basically my problem is laziness, but I'm just wondering why forced unloading and dynamic deregistering isn't in the kernel config.

There is no need. You are abusing those features for purposes other than their design. Forcing removal does have consequences too, and may lead to instability, and sometimes just doesnt work.

brain0: Loadable Module Support -> Forced module unloading (CONFIG_MODULE_FORCE_UNLOAD)

Currently disabled in all Arch kernels, and i'm yet to see a reason to do otherwise.

This option allows you to force a module to unload, even if the kernel believes it is unsafe: the kernel will remove the module without waiting for anyone to stop using it (using the -f option to rmmod).  This is mainly for kernel developers and desperate users. If unsure, say N.

James

Offline

Board footer

Powered by FluxBB