Re: [PATCH 2/3] block: fail SCSI passthrough ioctls on partition devices

From: Willy Tarreau
Date: Fri Dec 23 2011 - 04:45:18 EST


On Fri, Dec 23, 2011 at 01:22:24AM -0800, Linus Torvalds wrote:
> On Thu, Dec 22, 2011 at 10:26 PM, Willy Tarreau <w@xxxxxx> wrote:
> >
> > Call me dumb, but why would someone use "eject" on a non-physically
> > ejectable device such as a memory stick ?
>
> Perhaps because that's the operation that works everywhere and is the
> simplest one?

I didn't know people were doing that. For me eject was just used to
activate the motor of ejectable devices. I've just found this in the
man which explains what you're doing and which I did not know :

If the device is currently mounted, it is unmounted before
ejecting.

> Just look at the icon on your desktop - it probably has "Eject" above
> the silly "Safely remove drive" when you right-click it. It has for
> me.
>
> And I've taught myself (and my wife) to always eject media before
> removing them. I don't "unmount" them, because then for cdroms I need
> to first unmount them and then eject them. Or I'd need to do different
> operations for different devices. Both of which are just stupid.

It makes sense. However it requires setting user permissions on a device,
which "umount" would not require.

> So yes, I claim that "eject" is actually the *natural* thing to do
> before you physically remove the medium, because it works across
> different media.
>
> But more importantly, we don't break what works. So what the f&^k was
> the point of even asking? THAT was the "dumb" thing here.

The point was that I didn't even imagine people were using this command
for this. It did not seem more natural to me than to use "mt", "chvt" or
"stty" to unmount this type of device precisely because there was no motor
to eject the device. The way you present it kind of makes sense and explains
why people are doing it this way.

Thanks,
Willy

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/