losetup -d --force for zombie loop devices?

losetup -d --force for zombie loop devices?

[Thomas Orgis]

[-- Attachment #1: Type: text/plain, Size: 4391 bytes --]

Hi,

I am having an issue with a loop device that used to be connected to a file on NFS.
Not sure if this is actually a kernel bug, but I assume (perhaps ignorantly so)
that losetup could resolve the situation anyways.

0. have NFS share on /mnt/nfs  (rw,users,noexec,nosuid,nodev,hard,intr)
1. losetup --show -f /mnt/nfs/file.img
   /dev/loop0
# actually, it was using cryptsetup luksOpen/Close
2. mount /dev/loop0 && do_work && umount /dev/loop0
3. loose connection to NFS server (it went offline, client machine (laptop) switched networks ...)
4. umount -l /mnt/nfs
5. be reminded about stale loop device because of
  losetup --show -f /some/other.img
hanging (at accessing /dev/loop0, I presume), in need of kill -9
6. reconnect to NFS server, mount /mnt/nfs, hoping that that resolves the hang
7. does resolve hang, but now any operation on /dev/loop0 failing with "device or resource busy"

Well, at this point I just want to get rid of the stale loop device and I bump against this:

# strace losetup -d /dev/loop0
execve("/sbin/losetup", ["losetup", "-d", "/dev/loop0"], [/* 44 vars */]) = 0
brk(0)                                  = 0x1494000
mmap(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0x2ac8a5568000
access("/etc/ld.so.preload", R_OK)      = 0
open("/etc/ld.so.preload", O_RDONLY)    = 3
fstat(3, {st_mode=S_IFREG|0644, st_size=23, ...}) = 0
mmap(NULL, 23, PROT_READ|PROT_WRITE, MAP_PRIVATE, 3, 0) = 0x2ac8a5569000
close(3)                                = 0
munmap(0x2ac8a5569000, 23)              = 0
open("/etc/ld.so.cache", O_RDONLY)      = 3
fstat(3, {st_mode=S_IFREG|0644, st_size=194473, ...}) = 0
mmap(NULL, 194473, PROT_READ, MAP_PRIVATE, 3, 0) = 0x2ac8a5569000
close(3)                                = 0
open("/lib/libc.so.6", O_RDONLY)        = 3
read(3, "\177ELF\2\1\1\0\0\0\0\0\0\0\0\0\3\0>\0\1\0\0\0p\354\1\0\0\0\0\0@"..., 832) = 832
fstat(3, {st_mode=S_IFREG|0755, st_size=8820786, ...}) = 0
mmap(NULL, 3524616, PROT_READ|PROT_EXEC, MAP_PRIVATE|MAP_DENYWRITE, 3, 0) = 0x2ac8a576a000
mprotect(0x2ac8a58bd000, 2097152, PROT_NONE) = 0
mmap(0x2ac8a5abd000, 20480, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXED|MAP_DENYWRITE, 3, 0x153000) = 0x2ac8a5abd000
mmap(0x2ac8a5ac2000, 18440, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXED|MAP_ANONYMOUS, -1, 0) = 0x2ac8a5ac2000
close(3)                                = 0
mmap(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0x2ac8a5ac7000
mmap(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0x2ac8a5ac8000
arch_prctl(ARCH_SET_FS, 0x2ac8a5ac7b20) = 0
mprotect(0x2ac8a5abd000, 16384, PROT_READ) = 0
mprotect(0x2ac8a5767000, 4096, PROT_READ) = 0
munmap(0x2ac8a5569000, 194473)          = 0
brk(0)                                  = 0x1494000
brk(0x14b5000)                          = 0x14b5000
close(0)                                = 0
close(0)                                = -1 EBADF (Bad file descriptor)
uname({sys="Linux", node="dunkelstern", ...}) = 0
stat("/dev/loop-control", {st_mode=S_IFCHR|0600, st_rdev=makedev(10, 237), ...}) = 0
open("/dev/loop0", O_RDONLY)            = 0
ioctl(0, 0x4c01, 0)                     = -1 EBUSY (Device or resource busy)
write(2, "losetup: "..., 9losetup: )             = 9
write(2, "/dev/loop0: detach failed"..., 25/dev/loop0: detach failed) = 25
write(2, ": "..., 2: )                    = 2
write(2, "Device or resource busy\n"..., 24Device or resource busy
) = 24
close(0)                                = 0
exit_group(1)                           = ?

So I see that it might be tricky for losetup to decide on itself that the file
is not busy but actually a zombie. but is there a way to enforce deletion
of the loop device, ignoring the failing ioctl?

# I know what I'm doing, just get rid of the loop device.
losetup --force -d /dev/loop0

I did notice that this must be something peculiar with NFS ... 
well, for completeness, I am on vanilla linux 3.2.1 (plus ASPM patch for
that power management regression) on x86-64 and until-linux 2.21.1.
Distro is rather custom (it's an install of Source Mage).

In the case this is an obscure kernel/NFS bug/feature, I still would like to
know if such enforced delete could work from losetup ... sometimes we
have to live with bugs in other software.


Alrighty then,

Thomas

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 197 bytes --]

Re: losetup -d --force for zombie loop devices?

[Mike Frysinger]

[-- Attachment #1: Type: Text/Plain, Size: 342 bytes --]

On Tuesday 17 April 2012 04:03:46 Thomas Orgis wrote:
> ioctl(0, 0x4c01, 0)                     = -1 EBUSY (Device or resource
> busy)

that's LOOP_CLR_FD returning EBUSY.  so there isn't much (afaik) that 
userspace can do here.  you'd have to start a thread on lkml first to add 
support for lazy/force loop device detaching.
-mike

[-- Attachment #2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 836 bytes --]

Re: losetup -d --force for zombie loop devices?

[Thomas Orgis]

[-- Attachment #1: Type: text/plain, Size: 599 bytes --]

Am Tue, 17 Apr 2012 10:58:22 -0400
schrieb Mike Frysinger <vapier@gentoo.org>: 

> that's LOOP_CLR_FD returning EBUSY.  so there isn't much (afaik) that 
> userspace can do here.  you'd have to start a thread on lkml first to add 
> support for lazy/force loop device detaching.

Hm, I feared such ... now the question is if folks would support that
move. Well, one will not find out without asking. Perhaps I should try
to reproduce the scheme with another machine first. Not that this
situation is something that "just does not happen", except in my case.


Alrighty then,

Thomas

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 197 bytes --]

Re: losetup -d --force for zombie loop devices?

[Phillip Susi]

On 4/17/2012 4:03 AM, Thomas Orgis wrote:
> Hi,
>
> I am having an issue with a loop device that used to be connected to a file on NFS.
> Not sure if this is actually a kernel bug, but I assume (perhaps ignorantly so)
> that losetup could resolve the situation anyways.
>
> 0. have NFS share on /mnt/nfs  (rw,users,noexec,nosuid,nodev,hard,intr)
> 1. losetup --show -f /mnt/nfs/file.img
>     /dev/loop0
> # actually, it was using cryptsetup luksOpen/Close
> 2. mount /dev/loop0&&  do_work&&  umount /dev/loop0
> 3. loose connection to NFS server (it went offline, client machine (laptop) switched networks ...)
> 4. umount -l /mnt/nfs

This is the problem with umount -l: all it does is remove the path from 
the namespace, leaving the device still mounted.  Unfortunately umount 
-f is not properly supported.  The proper fix for this is to have the 
kernel support umount -f, and do away with the brain damaged umount -l.

Re: losetup -d --force for zombie loop devices?

[Mike Frysinger]

[-- Attachment #1: Type: Text/Plain, Size: 1218 bytes --]

On Monday 30 April 2012 16:03:39 Phillip Susi wrote:
> On 4/17/2012 4:03 AM, Thomas Orgis wrote:
> > I am having an issue with a loop device that used to be connected to a
> > file on NFS. Not sure if this is actually a kernel bug, but I assume
> > (perhaps ignorantly so) that losetup could resolve the situation
> > anyways.
> > 
> > 0. have NFS share on /mnt/nfs  (rw,users,noexec,nosuid,nodev,hard,intr)
> > 1. losetup --show -f /mnt/nfs/file.img
> > 
> >     /dev/loop0
> > 
> > # actually, it was using cryptsetup luksOpen/Close
> > 2. mount /dev/loop0&&  do_work&&  umount /dev/loop0
> > 3. loose connection to NFS server (it went offline, client machine
> > (laptop) switched networks ...) 4. umount -l /mnt/nfs
> 
> This is the problem with umount -l: all it does is remove the path from
> the namespace, leaving the device still mounted.  Unfortunately umount
> -f is not properly supported.  The proper fix for this is to have the
> kernel support umount -f, and do away with the brain damaged umount -l.

`umount -l` has its place -- there are cases where you want those semantics.  
granted, most people actually want a `umount -f`, but the two aren't mutually 
exclusive.
-mike

[-- Attachment #2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 836 bytes --]

Re: losetup -d --force for zombie loop devices?

[Phillip Susi]

On 4/30/2012 4:07 PM, Mike Frysinger wrote:
> `umount -l` has its place -- there are cases where you want those semantics.
> granted, most people actually want a `umount -f`, but the two aren't mutually
> exclusive.
> -mike

If you want to prevent processes from opening new files on the mount 
point, it would be much more sane to mount --move it somewhere hidden. 
When you detach it entirely from the namespace, you can't even be aware 
that the mount still exists, let alone change your mind and reattach it. 
  Having a device that is still mounted, but appears not to be to all 
tools that normally check for such things ( partitioning tools, auto 
mounters, etc ) is broken.

It is very confusing when you later try to change the cd in the drive 
and can't mount it because the old one is still mounted, yet lsof, 
mount, etc offer no evidence that this is the case, and you can't track 
down the process that is still holding an open fd and kill it.

Re: losetup -d --force for zombie loop devices?

[Mike Frysinger]

[-- Attachment #1: Type: Text/Plain, Size: 1986 bytes --]

On Tuesday 01 May 2012 11:23:42 Phillip Susi wrote:
> On 4/30/2012 4:07 PM, Mike Frysinger wrote:
> > `umount -l` has its place -- there are cases where you want those
> > semantics. granted, most people actually want a `umount -f`, but the two
> > aren't mutually exclusive.
> 
> If you want to prevent processes from opening new files on the mount
> point, it would be much more sane to mount --move it somewhere hidden.

there's really no difference at all here.  the active process will still have 
the same capabilities to modify their open handles, and attempting to open new 
paths in the fs will fail because they'll be expecting the mount at one place 
but you relocated it elsewhere  (ignoring the accesses down via the *at funcs 
which will work the same).

> When you detach it entirely from the namespace, you can't even be aware
> that the mount still exists, let alone change your mind and reattach it.

you can re-attach it by mounting it again

>   Having a device that is still mounted, but appears not to be to all
> tools that normally check for such things ( partitioning tools, auto
> mounters, etc ) is broken.

conversely, having a mount point removed from the perspective of userspace can 
be useful.  like with tools that stubbornly enumerate all mounts, or 
attempting to shutdown your system with known unreachable network mounts.  
you, as the admin, know these things are gone and beyond accessible, so having 
the ability to remove them all manually and reboot cleanly (w/out ridiculous 
long retries/timeouts) is a good thing.

> It is very confusing when you later try to change the cd in the drive
> and can't mount it because the old one is still mounted, yet lsof,
> mount, etc offer no evidence that this is the case, and you can't track
> down the process that is still holding an open fd and kill it.

are you sure that's true ?  `lsof -n` seems to report open handles to 
unmounted filesystems to me.
-mike

[-- Attachment #2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 836 bytes --]

Re: losetup -d --force for zombie loop devices?

[Phillip Susi]

On 5/3/2012 12:43 AM, Mike Frysinger wrote:
>> When you detach it entirely from the namespace, you can't even be aware
>> that the mount still exists, let alone change your mind and reattach it.
>
> you can re-attach it by mounting it again

The last time I tried this, you couldn't and that made sense because 
most filesystems require exclusive access to the block device, which 
they can't get with the other ghost mount still hanging around. 
Mounting the same block device twice would cause massive corruption. 
Now that I try it again, it appears to let you.  Based on the kernel 
prints, it looks like it is somehow magically reattaching the existing 
mount instead of creating a new one.  Oddly though, the reattached mount 
can be unmounted without -l, even though it is still in use.

I'll have to test with removable media again.  Presumably this new 
reattach behavior would cause the contents of the old cd to show up 
again while dmesg spews IO errors, which may be slightly better than the 
old behavior of simply being unable to mount the drive with no 
explanation as to why, but is still very much not good.

> conversely, having a mount point removed from the perspective of userspace can
> be useful.  like with tools that stubbornly enumerate all mounts, or
> attempting to shutdown your system with known unreachable network mounts.
> you, as the admin, know these things are gone and beyond accessible, so having
> the ability to remove them all manually and reboot cleanly (w/out ridiculous
> long retries/timeouts) is a good thing.

If you want to hide mounts from certain processes, that is what unshare 
is for.  Hiding a mount from all processes does not make sense.  If you 
know a mount is gone and beyond recovery ( like in this loop over nfs 
case, or removed media ), then it should be forcibly unmounted, not 
simply made invisible and doomed to remain a zombie mount until the 
system is rebooted.

>> It is very confusing when you later try to change the cd in the drive
>> and can't mount it because the old one is still mounted, yet lsof,
>> mount, etc offer no evidence that this is the case, and you can't track
>> down the process that is still holding an open fd and kill it.
>
> are you sure that's true ?  `lsof -n` seems to report open handles to
> unmounted filesystems to me.
> -mike

It does, but they have been reparrented as if the filesystem was mounted 
in the root, so you can't search for the files using their previous 
mount point.

Re: losetup -d --force for zombie loop devices?

[Mike Frysinger]

[-- Attachment #1: Type: Text/Plain, Size: 1523 bytes --]

On Thursday 03 May 2012 10:29:07 Phillip Susi wrote:
> On 5/3/2012 12:43 AM, Mike Frysinger wrote:
> > conversely, having a mount point removed from the perspective of
> > userspace can be useful.  like with tools that stubbornly enumerate all
> > mounts, or attempting to shutdown your system with known unreachable
> > network mounts. you, as the admin, know these things are gone and beyond
> > accessible, so having the ability to remove them all manually and reboot
> > cleanly (w/out ridiculous long retries/timeouts) is a good thing.
> 
> If you want to hide mounts from certain processes, that is what unshare
> is for.  Hiding a mount from all processes does not make sense.  If you
> know a mount is gone and beyond recovery ( like in this loop over nfs
> case, or removed media ), then it should be forcibly unmounted, not
> simply made invisible and doomed to remain a zombie mount until the
> system is rebooted.

in an ideal world, maybe unshare might work.  in the real world, it doesn't.  
you can use it only on *new* processes, not ones that are already running.  
nor can you do `unshare shutdown` and have it work since that simply signals a 
long running init process to initiate a shutdown.

an nfs server goes afk and attempts to `umount` it timeout, as well as many 
desktop programs (like kde io daemons that like to walk available mount 
points) or shutdown processes.  no call to `unshare` will fix this, but 
certainly forcibly removing it with `umount -l` will.
-mike

[-- Attachment #2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 836 bytes --]

Re: losetup -d --force for zombie loop devices?

[Phillip Susi]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On 01/11/2013 06:52 PM, Mike Frysinger wrote:
> On Thursday 03 May 2012 10:29:07 Phillip Susi wrote:
>> If you want to hide mounts from certain processes, that is what
>> unshare is for.  Hiding a mount from all processes does not make
>> sense.  If you know a mount is gone and beyond recovery ( like in
>> this loop over nfs case, or removed media ), then it should be
>> forcibly unmounted, not simply made invisible and doomed to
>> remain a zombie mount until the system is rebooted.
> 
> in an ideal world, maybe unshare might work.  in the real world, it
> doesn't. you can use it only on *new* processes, not ones that are
> already running. nor can you do `unshare shutdown` and have it work
> since that simply signals a long running init process to initiate a
> shutdown.
> 
> an nfs server goes afk and attempts to `umount` it timeout, as well
> as many desktop programs (like kde io daemons that like to walk
> available mount points) or shutdown processes.  no call to
> `unshare` will fix this, but certainly forcibly removing it with
> `umount -l` will. -mike

A bit of a delayed response there, but my point was that what you are
looking for is umount -f, not umount -l.  It also used to be that once
you detached a mount with umount -l, you could not reattach it.
Attempts to remount would fail with EBUSY and so this was a horribly
broken state to be in.  At some point it seems this was changed and
now you *can* reattach, so lazy unmount is no longer pure evil, but
still it is no forced unmount.


-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.11 (GNU/Linux)
Comment: Using GnuPG with undefined - http://www.enigmail.net/

iQEcBAEBAgAGBQJQ8LQ4AAoJEJrBOlT6nu75BO0H/A1mZ3qYAfSe/H8Z4x3BVsOZ
/sKYxc6JWUVrK5xfycZlZzpkRsIHL0Jj+asYe/+OAUHHmaUKooR7HuGF90U4kitN
h+UEdyNJJkgldju2rwePyIGucit/HOxz/SfWtSALUiu7w9OIpmkqcCXIINLJvQ0R
nQHLm79d5YFWXQRgKRuloDIW6+kBSq0cpZ+63CFhz2G7CuqzZaa1rE+I1TZbcOzF
p7G8dM/3//BeMZw/yFFDu1Ia2snO3o3vdrZWIZlbVu7fnDXC+a/qfcZtGRNZVZP9
iD4fpPNsKrjLGuaCormk62lm1OBT5YyolKaZPSJWDJrpkwKotndcwVrXWYsKGqY=
=i+ji
-----END PGP SIGNATURE-----

Re: losetup -d --force for zombie loop devices?

[Mike Frysinger]

[-- Attachment #1: Type: Text/Plain, Size: 2153 bytes --]

On Friday 11 January 2013 19:54:16 Phillip Susi wrote:
> On 01/11/2013 06:52 PM, Mike Frysinger wrote:
> > On Thursday 03 May 2012 10:29:07 Phillip Susi wrote:
> >> If you want to hide mounts from certain processes, that is what
> >> unshare is for.  Hiding a mount from all processes does not make
> >> sense.  If you know a mount is gone and beyond recovery ( like in
> >> this loop over nfs case, or removed media ), then it should be
> >> forcibly unmounted, not simply made invisible and doomed to
> >> remain a zombie mount until the system is rebooted.
> > 
> > in an ideal world, maybe unshare might work.  in the real world, it
> > doesn't. you can use it only on *new* processes, not ones that are
> > already running. nor can you do `unshare shutdown` and have it work
> > since that simply signals a long running init process to initiate a
> > shutdown.
> > 
> > an nfs server goes afk and attempts to `umount` it timeout, as well
> > as many desktop programs (like kde io daemons that like to walk
> > available mount points) or shutdown processes.  no call to
> > `unshare` will fix this, but certainly forcibly removing it with
> > `umount -l` will.
> 
> A bit of a delayed response there

the recent unshare patches reminded me of this.  and i had actually used 
unshare in the interim so i know how it works now.

> but my point was that what you are
> looking for is umount -f, not umount -l.

and my point is that `umount -f` doesn't always work which means `umount -l` 
is sometimes the only way to remove a mount point.  an unresponsive remote or 
something is holding open a reference (which doesn't show up in `lsof -n`).

> It also used to be that once
> you detached a mount with umount -l, you could not reattach it.
> Attempts to remount would fail with EBUSY and so this was a horribly
> broken state to be in.  At some point it seems this was changed and
> now you *can* reattach, so lazy unmount is no longer pure evil, but
> still it is no forced unmount.

it hasn't been that way for quite some time, and for network based mounts, 
it's pretty much never been that way ?
-mike

[-- Attachment #2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 836 bytes --]

Re: losetup -d --force for zombie loop devices?

[Phillip Susi]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On 01/11/2013 11:52 PM, Mike Frysinger wrote:
>> but my point was that what you are looking for is umount -f, not
>> umount -l.
> 
> and my point is that `umount -f` doesn't always work which means
> `umount -l` is sometimes the only way to remove a mount point.  an
> unresponsive remote or something is holding open a reference (which
> doesn't show up in `lsof -n`).

Right.  Forced unmounts aren't really implemented.  They need to be.
It isn't losetup that needs to be forcibly detached, but the filesystem.


-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.11 (GNU/Linux)
Comment: Using GnuPG with undefined - http://www.enigmail.net/

iQEcBAEBAgAGBQJQ8PDoAAoJEJrBOlT6nu75dGsIAMTb/fK1nw3QZGyWKmHQWknA
AdOXe8aYqIzKTwhGCrJobamAB5ZOqEXWCHZnMfACI3/XwTfy6vNxKa69fIEevpXz
uNU4QO1dw8uLRBi3UQpoTSNZpx4vB8DF9ka1GxgEUs7Y0Iv1I3n2OoHnU1o/GUE9
HHeA70QSSIJaO7hUB5Q9mb5brx5ADP+GS7Ka7ZPDVFjdImBkS9ofOj3GX8aLWf1Z
kgkxcChgEtZPc1xrp15l8ctAvI/sQnev+DQ4SmzFdmDGqEwEBNP5ROm/W+B2bNkC
L1RdlOEhOwQvdWcjer1W3Mkl9MuhSzcmW4GdaepndXzuJYQ0VQqURSPSdBxueLY=
=qhyJ
-----END PGP SIGNATURE-----

Re: losetup -d --force for zombie loop devices?

[Mike Frysinger]

[-- Attachment #1: Type: Text/Plain, Size: 926 bytes --]

On Saturday 12 January 2013 00:13:12 Phillip Susi wrote:
> On 01/11/2013 11:52 PM, Mike Frysinger wrote:
> >> but my point was that what you are looking for is umount -f, not
> >> umount -l.
> > 
> > and my point is that `umount -f` doesn't always work which means
> > `umount -l` is sometimes the only way to remove a mount point.  an
> > unresponsive remote or something is holding open a reference (which
> > doesn't show up in `lsof -n`).
> 
> Right.  Forced unmounts aren't really implemented.  They need to be.
> It isn't losetup that needs to be forcibly detached, but the filesystem.

would be nice if userland had visibility into all these handles that the 
kernel has opened.  for example, with losetup, i think the only way is to 
query the loop devices directly or sysfs ?  might be handy to at least teach 
lsof to peek in there, but still sucks we have to do it subsystem by 
subsystem.
-mike

[-- Attachment #2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 836 bytes --]

Re: losetup -d --force for zombie loop devices?

[Karel Zak]

On Sat, Jan 12, 2013 at 12:29:28AM -0500, Mike Frysinger wrote:
> On Saturday 12 January 2013 00:13:12 Phillip Susi wrote:
> > On 01/11/2013 11:52 PM, Mike Frysinger wrote:
> > >> but my point was that what you are looking for is umount -f, not
> > >> umount -l.
> > > 
> > > and my point is that `umount -f` doesn't always work which means
> > > `umount -l` is sometimes the only way to remove a mount point.  an
> > > unresponsive remote or something is holding open a reference (which
> > > doesn't show up in `lsof -n`).
> > 
> > Right.  Forced unmounts aren't really implemented.  They need to be.
> > It isn't losetup that needs to be forcibly detached, but the filesystem.
> 
> would be nice if userland had visibility into all these handles that the 
> kernel has opened.  for example, with losetup, i think the only way is to 
> query the loop devices directly or sysfs ?  might be handy to at least teach 
> lsof to peek in there, but still sucks we have to do it subsystem by 
> subsystem.

 That's my wish to have in lsblk output a column with handlers counter
 that kernel has open for the device. Unfortunately this info is not
 exported by sysfs.

    Karel


-- 
 Karel Zak  <kzak@redhat.com>
 http://karelzak.blogspot.com