find does not have the ability to find device nodes with given
major/minor number. It should.

Greetings
Marc

URL:
  <http://savannah.gnu.org/support/?105661>

                 Summary: wishlist: no option to find devices for major/minor
number
                 Project: findutils
            Submitted by: ametzler
            Submitted on: Dienstag 07.11.2006 um 19:36
                Category: None
                Priority: 5 - Normal
                Severity: 1 - Wish
                  Status: None
                 Privacy: Public
             Assigned to: None
        Originator Email:
             Open/Closed: Open
        Operating System: GNU/Linux

That's an interesting feature request, and should fit in well with the
existing design.

But, if this feature is implemented, someone (myself in fact) will
have to spend a lot of time implementing the feature, writing tests
for it, documenting it, and maintaining the feature for as long as GNU
findutils exists.

To make responsible use of our time, we should be sure that the
benefit justifies the costs.   This feature request hasn't previously
been made, so it looks like it's not that popular a request.   So, in
order to help us make sure we're using our time wisely, please justify
the need for the new feature.   Could you explain why this is useful,
why the maintenance cost is justified, and why alternative ways of
solving the problem are worse?   Right now the only justification we
have stated is

If I'm going to spend time working on this, I'm going to need a more
convincing argument that that's how I should spend my time.

James.

https://savannah.gnu.org/bugs/index.php?46791

----- Forwarded message from James Youngman <jay@gnu.org> -----
Date: Sun, 3 Jan 2016 18:32:52 +0000
From: James Youngman <jay@gnu.org>
To: 397434@bugs.debian.org
Subject: Bug#397434: Please justify the feature request
In-Reply-To: <20061107113809.6871.63737.reportbug@nechayev.zugschlus.de>

That's an interesting feature request, and should fit in well with the
existing design.

But, if this feature is implemented, someone (myself in fact) will
have to spend a lot of time implementing the feature, writing tests
for it, documenting it, and maintaining the feature for as long as GNU
findutils exists.

To make responsible use of our time, we should be sure that the
benefit justifies the costs.   This feature request hasn't previously
been made, so it looks like it's not that popular a request.   So, in
order to help us make sure we're using our time wisely, please justify
the need for the new feature.   Could you explain why this is useful,
why the maintenance cost is justified, and why alternative ways of
solving the problem are worse?   Right now the only justification we
have stated is

If I'm going to spend time working on this, I'm going to need a more
convincing argument that that's how I should spend my time.

James.
----- End forwarded message -----

For what it's worth, my rawhide (rh) program, which is an alternative
to find(1), does support device numbers and major/minor numbers as
search criteria (including the device major/minor numbers of symlink
targets). But it's not a debian package yet.

For example, to find devices with the same device driver as /dev/tty:

  rh /dev 'rmajor == "/dev/tty".rmajor'

To find symlinks whose ultimate targets are on a different filesystem:

  rh / 'l && texists && tdev != dev'

To find mountpoints for other filesystems under the current directory:

  rh -1 'dev != ".".dev'

See https://raf.org/rawhide and https://github.com/raforg/rawhide for
more details.

cheers,
raf

Just to add a voice...

My use case is to search for all the alternate paths to a specific device.

I was quite surprised to discover that find doesn't support searching by
major:minor, to the naive eye it looks like something that fits directly
into the existing options that search on the stat structure.

I can of course use multiple tools (e.g. find + awk) to do what I need
but it would be nice if "find" were able to do this directly.

tl;dr...

Whilst a ATA security erase is in progress on a device (e.g. hdparm
--security-erase), all other open()s of the device go into an unkillable 
sleep (wchan:blkdev) until the security erase completes - this can take
many minutes to >24 hours (e.g. 20T HDD).

This means anything that performs device scans will go into an unkillable
sleep for the duration, e.g. various utilities from LVM2 like "pvs" and
"lvs". I have regular operations that require such scans and blocking for
an hour, let alone 24 hours, is problematic.

LVM2 scans /dev, /sys/dev/block and /sys/block for all block devices and
tries to open them, subject to a configurable "device filter" that can
filter devices by filesystem path name.

So I need to find all the paths to a specific major:minor to reject those
paths using the LVM2 device filter.

An alternate "coding required" solution would be for LVM2 to utilise
major:minor in it's device filter. This in fact would be the best solution
to this specific problem (other than secure erase not blocking) and I'll
see if it's possible to have this added to LVM2.

Cheers,

Chris

Surely -samefile will work for this.