remove-single-device removes mounted HDDs (kernel 2.6)

remove-single-device removes mounted HDDs (kernel 2.6)

[Harald Seipp]

[ Please CC any replies; I am not on this list]

I have two systems, each with at least two SCSI HDDs attached&mounted:
SLES 9 (2.6.5-7.151-smp)
Knoppix 3.9 (2.6.11.10)
If I execute echo "scsi remove-single-device h b t l" > /proc/scsi/scsi on
a mounted HDD target, the device will be _removed_. A subsequent echo "scsi
add-single-device h b t l" > /proc/scsi/scsi on the same target will cause
the device to be re-added, but it will appear at a different (next free)
device file (e.g. /dev/sda will become /dev/sdc when two HDDs are
attached).
This behavior does not appear when running kernel 2.4-based systems on the
same machines, the mounted HDDs will not be touched.

I assume this is a bug? How can I prevent that behavior? Can I easily query
if a device on "h b t l" is mounted to work-around?

Regards,
Harald Seipp,
IBM Systems and Technology Group

Re: remove-single-device removes mounted HDDs (kernel 2.6)

[Douglas Gilbert]

Harald Seipp wrote:
> [ Please CC any replies; I am not on this list]
> 
> I have two systems, each with at least two SCSI HDDs attached&mounted:
> SLES 9 (2.6.5-7.151-smp)
> Knoppix 3.9 (2.6.11.10)
> If I execute echo "scsi remove-single-device h b t l" > /proc/scsi/scsi on
> a mounted HDD target, the device will be _removed_. A subsequent echo "scsi
> add-single-device h b t l" > /proc/scsi/scsi on the same target will cause
> the device to be re-added, but it will appear at a different (next free)
> device file (e.g. /dev/sda will become /dev/sdc when two HDDs are
> attached).
> This behavior does not appear when running kernel 2.4-based systems on the
> same machines, the mounted HDDs will not be touched.
> 
> I assume this is a bug? How can I prevent that behavior? 

Harald,
I just tried remove-single-device followed by
add-single-device and I got /dev/sda back again.
I also placed the two commands in a script file
so they were executed with a very short delay between
the two commands.

The test was with lk 2.6.13-rc6 and a multicard
reader (4 luns) via the usb-storage driver.

BTW in lk 2.6 a SCSI device can be removed with:
echo "anything" >
    /sys/class/scsi_device/<h>:<b>:<t>:<l>/device/delete

and re-added with:
echo "<b> <t> <l>" > /sys/class/scsi_host/host<h>/scan


> Can I easily query
> if a device on "h b t l" is mounted to work-around?

ls /sys/class/scsi_device/<h>:<b>:<t>:<l>

will indicate (in the lk 2.6 series) that SCSI device
"h b t l" is present or not. As for mounted file systems
on (partitions of) a disk when its is removed and re-added,
I'm not so sure: seems like a questionable procedure IMO.

Doug Gilbert

Re: remove-single-device removes mounted HDDs (kernel 2.6)

[James Bottomley]

On Thu, 2005-08-11 at 12:09 +0200, Harald Seipp wrote:
> I assume this is a bug? How can I prevent that behavior? Can I easily query
> if a device on "h b t l" is mounted to work-around?

No, it's expected behaviour.  The mount keeps a reference to the old
device node so it can't be reused.

James

Re: remove-single-device removes mounted HDDs (kernel 2.6)

[Harald Seipp]

James Bottomley wrote on 11.08.2005 15:59:27:
> On Thu, 2005-08-11 at 12:09 +0200, Harald Seipp wrote:
> > I assume this is a bug? How can I prevent that behavior? Can I easily
query
> > if a device on "h b t l" is mounted to work-around?
>
> No, it's expected behaviour.  The mount keeps a reference to the old
> device node so it can't be reused.
Ok - but shouldn't the behavior that devices that have mounted partitions
can be removed be considered as a bug?
Linux 2.4 SCSI Subsystem Howto, proc interface: "....The removal will fail
if the device is busy (e.g. if a file system on the device is mounted)."

Harald Seipp
IBM System and Technology Group

Re: remove-single-device removes mounted HDDs (kernel 2.6)

[Matthew Wilcox]

On Thu, Aug 11, 2005 at 04:32:51PM +0200, Harald Seipp wrote:
> James Bottomley wrote on 11.08.2005 15:59:27:
> > On Thu, 2005-08-11 at 12:09 +0200, Harald Seipp wrote:
> > > I assume this is a bug? How can I prevent that behavior? Can I easily
> query
> > > if a device on "h b t l" is mounted to work-around?
> >
> > No, it's expected behaviour.  The mount keeps a reference to the old
> > device node so it can't be reused.
> Ok - but shouldn't the behavior that devices that have mounted partitions
> can be removed be considered as a bug?
> Linux 2.4 SCSI Subsystem Howto, proc interface: "....The removal will fail
> if the device is busy (e.g. if a file system on the device is mounted)."

The trouble is that users can surprise-remove drives (eg USB memory) and
there's nothing we can do about it.  So the SCSI subsystem is designed
to cope as best it can with such a scenario rather than trying to forbid
in software an action that already took place in hardware.

-- 
"Next the statesmen will invent cheap lies, putting the blame upon 
the nation that is attacked, and every man will be glad of those
conscience-soothing falsities, and will diligently study them, and refuse
to examine any refutations of them; and thus he will by and by convince 
himself that the war is just, and will thank God for the better sleep 
he enjoys after this process of grotesque self-deception." -- Mark Twain

Re: remove-single-device removes mounted HDDs (kernel 2.6)

[James Bottomley]

On Thu, 2005-08-11 at 16:32 +0200, Harald Seipp wrote:
> Ok - but shouldn't the behavior that devices that have mounted partitions
> can be removed be considered as a bug?

Not really.  We remove as much as we can and leave it up to the hotplug
scripts to detach the mount point (any further I/O's will error).

If there's a reattachment udev should identify the device (even if it's
on a different node) and do the right thing.

Essentially in 2.6 resolution of this problem is pushed up to the user
as a policy decision.

James

Re: remove-single-device removes mounted HDDs (kernel 2.6)

[Harald Seipp]

James Bottomley wrote on 11.08.2005 16:51:14:
> On Thu, 2005-08-11 at 16:32 +0200, Harald Seipp wrote:
> Not really.  We remove as much as we can and leave it up to the hotplug
> scripts to detach the mount point (any further I/O's will error).
>
> If there's a reattachment udev should identify the device (even if it's
> on a different node) and do the right thing.
>
> Essentially in 2.6 resolution of this problem is pushed up to the user
> as a policy decision.
>
Thank you for your quick responses! It finally looks like the task I need
to do - fully rescan all hosts for newly attached/changed devices - must
include the logic to skip devices with mounted fs for 2.6. This has been so
easy with 2.4...
I assume the right way would be to read the mounted fs from /etc/mtab,
identify the mounted partitions, track them back to the device Id/Lun's by
using the SCSI_IOCTL_GET_ID_LUN ioctl and put these devices into a
blacklist that will be excluded from remove-single-devices during the scan
process.
Can I rely on the mtab information? I recognized that e.g. submountd will
add permanent entries even when the devices are not present...
What about udev, devfsd, usbmount?

Harald Seipp
IBM Systems and Technology Group

RE: remove-single-device removes mounted HDDs (kernel 2.6)

[Salyzyn, Mark]

The problem with pushing this policy to the user is that software
applications have no means to determine that a device is currently
in-use. For instance, the net result of pulling a device on a mounted
filesystem is an eventual kernel panic.

There needs to be a means to reasonably *predict* the behavior of the
operating system and keep away from doing harm to oneself.

Yes, this is an old discussion, usually turned away as something that
can not be solved because of race conditions. There are users out there
that would appreciate a race condition that reduces the possibility of a
kernel panic.

Sincerely -- Mark Salyzyn

-----Original Message-----
From: linux-scsi-owner@vger.kernel.org
[mailto:linux-scsi-owner@vger.kernel.org] On Behalf Of James Bottomley
Sent: Thursday, August 11, 2005 10:51 AM
To: Harald Seipp
Cc: SCSI Mailing List
Subject: Re: remove-single-device removes mounted HDDs (kernel 2.6)

On Thu, 2005-08-11 at 16:32 +0200, Harald Seipp wrote:
> Ok - but shouldn't the behavior that devices that have mounted
partitions
> can be removed be considered as a bug?

Not really.  We remove as much as we can and leave it up to the hotplug
scripts to detach the mount point (any further I/O's will error).

If there's a reattachment udev should identify the device (even if it's
on a different node) and do the right thing.

Essentially in 2.6 resolution of this problem is pushed up to the user
as a policy decision.

James


-
To unsubscribe from this list: send the line "unsubscribe linux-scsi" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

RE: remove-single-device removes mounted HDDs (kernel 2.6)

[James Bottomley]

On Thu, 2005-08-11 at 11:51 -0400, Salyzyn, Mark wrote:
> The problem with pushing this policy to the user is that software
> applications have no means to determine that a device is currently
> in-use. For instance, the net result of pulling a device on a mounted
> filesystem is an eventual kernel panic.

The kernel only panics if you told it to with the mount option
errors=panic (or if you have errors=panic set in the superblock flags).

For file systems on removable devices you shouldn't be telling it to
panic on error, you should be telling it to continue or remount-ro.  If
you do this then you can happily yank the undelying device on a mounted
fs, which was one of the design goals of the 2.6 SCSI state model and
refcounting reworks.

James

RE: remove-single-device removes mounted HDDs (kernel 2.6)

[Salyzyn, Mark]

Cool, must try that to see if the issues are mitigated, the issues are
reported on Distributions in default configurations.

The panics I have seen have been access violations due to bugs in the
filesystem layers dealing with some of the inconsistencies. No different
to mounting a corrupted filesystem. Sometimes the filesystem driver can
see the punch coming, I contend that sometimes it does not...

Since it is a design goal to survive, then I better be putting up traces
and submitting fs patches, rather than b*&^ing eh? I'd still feel more
comfortable having the RAID management GUIs put up a popup box warning
the user that what he is about to do to a device currently in-use is
dangerous. Reporting a refcount (which covers both filesystem and direct
i/o as used by database engines) would help.

Sincerely -- Mark Salyzyn

-----Original Message-----
From: James Bottomley [mailto:James.Bottomley@SteelEye.com] 
Sent: Thursday, August 11, 2005 12:08 PM
To: Salyzyn, Mark
Cc: Harald Seipp; SCSI Mailing List
Subject: RE: remove-single-device removes mounted HDDs (kernel 2.6)

On Thu, 2005-08-11 at 11:51 -0400, Salyzyn, Mark wrote:
> The problem with pushing this policy to the user is that software
> applications have no means to determine that a device is currently
> in-use. For instance, the net result of pulling a device on a mounted
> filesystem is an eventual kernel panic.

The kernel only panics if you told it to with the mount option
errors=panic (or if you have errors=panic set in the superblock flags).

For file systems on removable devices you shouldn't be telling it to
panic on error, you should be telling it to continue or remount-ro.  If
you do this then you can happily yank the undelying device on a mounted
fs, which was one of the design goals of the 2.6 SCSI state model and
refcounting reworks.

James

Re: remove-single-device removes mounted HDDs (kernel 2.6)

[Christoph Hellwig]

On Thu, Aug 11, 2005 at 05:44:46PM +0200, Harald Seipp wrote:
> Thank you for your quick responses! It finally looks like the task I need
> to do - fully rescan all hosts for newly attached/changed devices - must
> include the logic to skip devices with mounted fs for 2.6.

Why do you want to rescan a full bus anyway?  What SCSI transport do you
want this for?  All transports where new targets can be hot-plugged should
be doing automatic scanning already.

Re: remove-single-device removes mounted HDDs (kernel 2.6)

[Harald Seipp]

Christoph Hellwig wrote on 11.08.2005 18:40:03:
> On Thu, Aug 11, 2005 at 05:44:46PM +0200, Harald Seipp wrote:
> > Thank you for your quick responses! It finally looks like the task I
need
> > to do - fully rescan all hosts for newly attached/changed devices -
must
> > include the logic to skip devices with mounted fs for 2.6.
>
> Why do you want to rescan a full bus anyway?  What SCSI transport do you
> want this for?  All transports where new targets can be hot-plugged
should
> be doing automatic scanning already.
Old-fashioned parallel SCSI bus and FC/SAN where there are no hot-plug
events AFAIK. Rescanning is required for device diagnostics. Diagnostic
usage will also demand online device exchange - testing multiple devices,
one after another.

Harald Seipp
IBM Systems and Technology Group

RE: remove-single-device removes mounted HDDs (kernel 2.6)

[James Bottomley]

On Thu, 2005-08-11 at 12:37 -0400, Salyzyn, Mark wrote:
> Cool, must try that to see if the issues are mitigated, the issues are
> reported on Distributions in default configurations.

Well ... this was one of the nastiest features to get right; we didn't
get it fully sorted out until quite recently.  I'm not sure if the
distros backported all the fixes.  However, on a modern 2.6 based
distro, it works for me and my trusty USB stick with the latest kernel.

> Since it is a design goal to survive, then I better be putting up traces
> and submitting fs patches, rather than b*&^ing eh? I'd still feel more
> comfortable having the RAID management GUIs put up a popup box warning
> the user that what he is about to do to a device currently in-use is
> dangerous. Reporting a refcount (which covers both filesystem and direct
> i/o as used by database engines) would help.

Well ... look at it this way.  The system is designed to survive
surprise ejection (that's for USB, firewire et al.)  If you want to have
a GUI that does notified ejection then that's fine too, but it's not a
kernel issue: You clean up everything from userspace by asking nicely
and then eject the device, which we see as a surprise ejection where we
think that we fortuitously have no work to do.

James

Re: remove-single-device removes mounted HDDs (kernel 2.6)

[Harald Seipp]

> Harald,
> I just tried remove-single-device followed by
> add-single-device and I got /dev/sda back again.
> I also placed the two commands in a script file
> so they were executed with a very short delay between
> the two commands.
>
> The test was with lk 2.6.13-rc6 and a multicard
> reader (4 luns) via the usb-storage driver.
Just tried on debian etc (2.6.13-rc6), two SCSI HDDs attached to an aic7xxx
- same issue, independent if I use procfs or sysfs for device removal.
But anyway, this behavior seems to be "working as designed" based on the
other feedback to this thread.
>
> > Can I easily query
> > if a device on "h b t l" is mounted to work-around?
>
> ls /sys/class/scsi_device/<h>:<b>:<t>:<l>
>
> will indicate (in the lk 2.6 series) that SCSI device
> "h b t l" is present or not. As for mounted file systems
> on (partitions of) a disk when its is removed and re-added,
> I'm not so sure: seems like a questionable procedure IMO.
This unfortunately does not tell me if there is a pending reference to the
device (e.g. due to mounted file systems). Such a reference would greatly
help to satisfy my needs.

Harald Seipp
IBM Systems and Technology Group

RE: remove-single-device removes mounted HDDs (kernel 2.6)

[Salyzyn, Mark]

Thanks for your responses thus far, James; I appreciate the education I
am getting.

RAID management applications have no idea what other applications are
doing and can not exercise such control over them. From my (flawed?)
view, there is no way to ask the OS if the target happens to be unused
and quiesced at this instant of time.

Asking the (various) applications (of which one of them is the
filesystem mounts) this question is an exercise in anger management
currently. All attempts to add such 'busy' interrogation code to the
ioctl of the driver are rejected. This code resides in the 'Adaptec
Branch' of the aacraid driver as one of our OEM added values.

Sincerely -- Mark Salyzyn

-----Original Message-----
From: James Bottomley [mailto:James.Bottomley@SteelEye.com] 
Sent: Thursday, August 11, 2005 12:53 PM
To: Salyzyn, Mark
Cc: Harald Seipp; SCSI Mailing List
Subject: RE: remove-single-device removes mounted HDDs (kernel 2.6)

On Thu, 2005-08-11 at 12:37 -0400, Salyzyn, Mark wrote:
> Cool, must try that to see if the issues are mitigated, the issues are
> reported on Distributions in default configurations.

Well ... this was one of the nastiest features to get right; we didn't
get it fully sorted out until quite recently.  I'm not sure if the
distros backported all the fixes.  However, on a modern 2.6 based
distro, it works for me and my trusty USB stick with the latest kernel.

> Since it is a design goal to survive, then I better be putting up
traces
> and submitting fs patches, rather than b*&^ing eh? I'd still feel more
> comfortable having the RAID management GUIs put up a popup box warning
> the user that what he is about to do to a device currently in-use is
> dangerous. Reporting a refcount (which covers both filesystem and
direct
> i/o as used by database engines) would help.

Well ... look at it this way.  The system is designed to survive
surprise ejection (that's for USB, firewire et al.)  If you want to have
a GUI that does notified ejection then that's fine too, but it's not a
kernel issue: You clean up everything from userspace by asking nicely
and then eject the device, which we see as a surprise ejection where we
think that we fortuitously have no work to do.

James

RE: remove-single-device removes mounted HDDs (kernel 2.6)

[Bryan Henderson]

>> The problem with pushing this policy to the user is that software
>> applications have no means to determine that a device is currently
>> in-use. For instance, the net result of pulling a device on a mounted
>> filesystem is an eventual kernel panic.
>
>The kernel only panics if you told it to with the mount option
>errors=panic (or if you have errors=panic set in the superblock flags).
>
>For file systems on removable devices ...

This is all valid argument for removable devices, but I don't think that's 
really what we're talking about here.  I think we're talking about a 
device that can't physically disappear, but can, unfortunately, logically 
disappear via remove-single-device.

For a fixed device, it is perfectly reasonable to design a system that 
assumes the device sticks around.  Any older system would definitely be 
designed that way.  Such a system, whether it technically panics or not, 
will probably utterly fail if the disk disappears.  It was accessing that 
disk for a reason.

Because removable devices exist, we do have to allow remove-single-device 
of an in-use device in general, but it would be good (and probably easy) 
to provide for the other case as well.  The code obviously knows that the 
device is in use, because /dev/sda doesn't get reused.  If there were a 
version of remove-single-device that said, "only if unused," that would 
solve the problem.  If there are synchronization issues that make that 
hard, then making it possible for the user to query that in-use state 
would still go a long way toward solving the problem.

--
Bryan Henderson                     IBM Almaden Research Center
San Jose CA                         Filesystems

Re: remove-single-device removes mounted HDDs (kernel 2.6)

[Bryan Henderson]

>Can I rely on the mtab information? I recognized that e.g. submountd will
>add permanent entries even when the devices are not present...
>What about udev, devfsd, usbmount?

Don't use /etc/mtab.  Don't use it for anything if you can help it; it was 
important technology in its day, but we can now go to the horse's mouth -- 
the kernel -- for that information.

/proc/mounts will tell you what is really mounted.

As you mentioned in another posting, this isn't really the information you 
want either -- you want to know if the SCSI disk is in use.  Being the 
device backing a conventional filesystem image is only one way a SCSI disk 
might be in use.

--
Bryan Henderson                     IBM Almaden Research Center
San Jose CA                         Filesystems

RE: remove-single-device removes mounted HDDs (kernel 2.6)

[James Bottomley]

On Thu, 2005-08-11 at 13:05 -0400, Salyzyn, Mark wrote:
> RAID management applications have no idea what other applications are
> doing and can not exercise such control over them. From my (flawed?)
> view, there is no way to ask the OS if the target happens to be unused
> and quiesced at this instant of time.

But we have userspace tools, like fuser that can get the answers

> Asking the (various) applications (of which one of them is the
> filesystem mounts) this question is an exercise in anger management
> currently. All attempts to add such 'busy' interrogation code to the
> ioctl of the driver are rejected. This code resides in the 'Adaptec
> Branch' of the aacraid driver as one of our OEM added values.

That's because such questions are 1) racy and 2) flawed.

I could export the device ref count sure enough, but it's not useful.
It's internal bookkeeping only.  It could be 1 if there's a filesystem
mounted, in which case you don't want to force an ejection without
unmounting or it could be 1 because someone's sitting in the sysfs
directory, in which case an ejection is fine.

Regardless, userspace is supposed to clean up nicely, so you
use /proc/mounts and fuser to check to see if the thing is really in use
and by whom and the user takes action accordingly (either say wait for
me to clean up manually or go ahead and kill everything to clean this
up).

James

Re: remove-single-device removes mounted HDDs (kernel 2.6)

[Stefan Richter]

Bryan Henderson wrote:
> Because removable devices exist, we do have to allow remove-single-device 
> of an in-use device in general,

Do we? I don't know of a use case of the add/remove-single-device user 
interface under Linux 2.6 as far as hotpluggable hardware is concerned.
-- 
Stefan Richter
-=====-=-=-= =--- -==--
http://arcgraph.de/sr/

Re: remove-single-device removes mounted HDDs (kernel 2.6)

[Harald Seipp]

> Don't use /etc/mtab.  Don't use it for anything if you can help it; it
was
> important technology in its day, but we can now go to the horse's mouth
--
> the kernel -- for that information.
> /proc/mounts will tell you what is really mounted.
But:
1. /proc/mounts hides the most important information - the physical device
of the root fs - it will always be /dev/root - so I don't see a way to get
down to the physical device
2. In my understanding, long-term-strategically procfs will only be used
for process information and all other information should be covered by
sysfs. So I doubt that using /proc/mounts will be a long-term solution
>
> As you mentioned in another posting, this isn't really the information
you
> want either -- you want to know if the SCSI disk is in use.  Being the
> device backing a conventional filesystem image is only one way a SCSI
disk
> might be in use.
For our usage, the device ref count information would be enough - we won't
care about the difference if the device is really mounted or if just one
process is sitting inside the sysfs tree of the device, we just would not
issue the remove-single-device to that device.

Harald Seipp
IBM Systems and Technology Group

RE: remove-single-device removes mounted HDDs (kernel 2.6)

[Salyzyn, Mark]

I am of the same mind here regarding the busy check, better to have a
coarse or overly paranoid understanding of ref count. But we desire a
ref count on the disk (/dev/sda) overall, not on the partition
(/dev/sda2) as would typically be mounted.

As for using fuser as James had suggested, needing to check each
partition for a user count is just wrong and time consuming and flawed
when someone makes their own dev 'elsewhere' to access the disk. I want
to know if the disk is busy, not the partitions, and not have to check
the multitude of individual possible access points to the disk before
satiating my need.

Our folks freaked when I suggested they use 'popen()' to pick up the
response from fuser. They view that as a security hole. And I am sure to
be flamed for this, importing open source fuser code got the
'proprietary gohds' also equally messed up (GPL infects, BSD relieves
stomach ulcers).

Sincerely -- Mark Salyzyn

-----Original Message-----
From: linux-scsi-owner@vger.kernel.org
[mailto:linux-scsi-owner@vger.kernel.org] On Behalf Of Harald Seipp
Sent: Friday, August 12, 2005 4:59 AM
To: Bryan Henderson
Cc: James Bottomley; SCSI Mailing List
Subject: Re: remove-single-device removes mounted HDDs (kernel 2.6)

> Don't use /etc/mtab.  Don't use it for anything if you can help it; it
was
> important technology in its day, but we can now go to the horse's
mouth
--
> the kernel -- for that information.
> /proc/mounts will tell you what is really mounted.
But:
1. /proc/mounts hides the most important information - the physical
device
of the root fs - it will always be /dev/root - so I don't see a way to
get
down to the physical device
2. In my understanding, long-term-strategically procfs will only be used
for process information and all other information should be covered by
sysfs. So I doubt that using /proc/mounts will be a long-term solution
>
> As you mentioned in another posting, this isn't really the information
you
> want either -- you want to know if the SCSI disk is in use.  Being the
> device backing a conventional filesystem image is only one way a SCSI
disk
> might be in use.
For our usage, the device ref count information would be enough - we
won't
care about the difference if the device is really mounted or if just one
process is sitting inside the sysfs tree of the device, we just would
not
issue the remove-single-device to that device.

Harald Seipp
IBM Systems and Technology Group

-
To unsubscribe from this list: send the line "unsubscribe linux-scsi" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: remove-single-device removes mounted HDDs (kernel 2.6)

[corene]

> From linux-scsi-owner@vger.kernel.org  Fri Aug 12 03:31:22 2005
> Subject: Re: remove-single-device removes mounted HDDs (kernel 2.6)
> To: Bryan Henderson <hbryan@us.ibm.com>
> Cc: James Bottomley <James.Bottomley@SteelEye.com>,
>    SCSI Mailing List <linux-scsi@vger.kernel.org>
> From: Harald Seipp <SEIPP@de.ibm.com>
> Date: 	Fri, 12 Aug 2005 10:59:00 +0200
>
> > Don't use /etc/mtab.  Don't use it for anything if you can help it; it
> was
> > important technology in its day, but we can now go to the horse's mouth
> --
> > the kernel -- for that information.
> > /proc/mounts will tell you what is really mounted.
> But:
> 1. /proc/mounts hides the most important information - the physical device
> of the root fs - it will always be /dev/root - so I don't see a way to get
> down to the physical device
> 2. In my understanding, long-term-strategically procfs will only be used
> for process information and all other information should be covered by
> sysfs. So I doubt that using /proc/mounts will be a long-term solution
> >
> > As you mentioned in another posting, this isn't really the information
> you
> > want either -- you want to know if the SCSI disk is in use.  Being the
> > device backing a conventional filesystem image is only one way a SCSI
> disk
> > might be in use.
> For our usage, the device ref count information would be enough - we won't
> care about the difference if the device is really mounted or if just one
> process is sitting inside the sysfs tree of the device, we just would not
> issue the remove-single-device to that device.
>

I've only been skimming this thread, so forgive me if this is completely
offtrack from what you're trying to do.  But if your goal is to determine
if the device is in-use, and you're okay with just a 'point-in-time'
reading on it (since obviously the state could change at any time),
one possible solution would be to open the disk (not the partition, the
disk itself), and do a BLKRRPART ioctl on it.  This ioctl fails
(I believe with EBUSY) if the device or any of its partitions have any
open references, so this might give you the information you want.
(Of course, it also has the effect of making the kernel update its notion
of the disk's partition table, so if you can think of a scenario where
that would cause a problem, you wouldn't want to use this approach!
Although since it only succeeds if the disk is completely not in-use,
offhand it doesn't seem like it should be a problem).
Well, just an idea.
-corene

----------------------------------------------------------------------
Corene Casper				email: corene@polyserve.com
Polyserve, Inc.

Re: remove-single-device removes mounted HDDs (kernel 2.6)

[Christoph Hellwig]

On Thu, Aug 11, 2005 at 06:50:03PM +0200, Harald Seipp wrote:
> Christoph Hellwig wrote on 11.08.2005 18:40:03:
> > On Thu, Aug 11, 2005 at 05:44:46PM +0200, Harald Seipp wrote:
> > > Thank you for your quick responses! It finally looks like the task I
> need
> > > to do - fully rescan all hosts for newly attached/changed devices -
> must
> > > include the logic to skip devices with mounted fs for 2.6.
> >
> > Why do you want to rescan a full bus anyway?  What SCSI transport do you
> > want this for?  All transports where new targets can be hot-plugged
> should
> > be doing automatic scanning already.
> Old-fashioned parallel SCSI bus and FC/SAN where there are no hot-plug
> events AFAIK.

In FC you get per-target events, although none for new LUs showing up
on a given target (in fact no SAM transport does the latter)

Re: remove-single-device removes mounted HDDs (kernel 2.6)

[Steve Byan]

On Sep 6, 2005, at 11:43 AM, Christoph Hellwig wrote:
> On Thu, Aug 11, 2005 at 06:50:03PM +0200, Harald Seipp wrote:
>> Christoph Hellwig wrote on 11.08.2005 18:40:03:
>>> On Thu, Aug 11, 2005 at 05:44:46PM +0200, Harald Seipp wrote:
>>>> Thank you for your quick responses! It finally looks like the task 
>>>> I need
>>>> to do - fully rescan all hosts for newly attached/changed devices - 
>>>> must
>>>> include the logic to skip devices with mounted fs for 2.6.
>>>
>>> Why do you want to rescan a full bus anyway?  What SCSI transport do 
>>> you
>>> want this for?  All transports where new targets can be hot-plugged 
>>> should
>>> be doing automatic scanning already.
>> Old-fashioned parallel SCSI bus and FC/SAN where there are no hot-plug
>> events AFAIK.
>
> In FC you get per-target events, although none for new LUs showing up
> on a given target (in fact no SAM transport does the latter)

I believe some Fibre Channel storage arrays generate RSCN's when new 
logical units are created (although I don't know if the existing Linux 
Fibre Channel HBA drivers propagate these registered state change 
notifications to the hot-plug subsystem).

I understand that many iSCSI storage arrays will generate a SCSI 
Asynchronous Event Notification for the REPORTED LUNS DATA HAS CHANGED 
Unit Attention condition that SPC-3 says shall be generated when a 
target changes its logical unit inventory, provided that AEN's are 
enabled in the control mode page.

So there are SAM transports that generate events when a new LU shows up.

I'm curious as to what plans, if any, exist for handling these events 
in Linux.

Regards,
-Steve
--------
Steve Byan <smb@egenera.com>
Software Architect
Egenera, Inc.
165 Forest Street
Marlboro, MA 01752
(508) 858-3125