[1/5] btrfs-progs: scan /proc/partitions not all of /dev with "-d"

Commit Message

Anand Jain Sept. 13, 2014, 1:21 a.m. UTC

From: Eric Sandeen <[e-mail]>

We can scan for btrfs devices in a few ways.  By default
libblkid is used for "device scan" and "filesystem show";
with the -m option only mounted filesystems are scanned,
and with -d we physically read every system device.

But there's no reason for the complexity of a descent through
/dev; /proc/partitions has every device known to the kernel, so
just use that when -d is specified.

Signed-off-by: Eric Sandeen <[e-mail]>
Reviewed-by: Anand Jain <[e-mail]>
---
 cmds-device.c     | 2 +-
 cmds-filesystem.c | 6 +++---
 2 files changed, 4 insertions(+), 4 deletions(-)

Comments

David Sterba Sept. 23, 2014, 5 p.m. UTC | #1

Hi,

all 5 patches will be in the next integration. I haven't tested them
yet, seems it's a bit more important to make a more stable devel base
for more updates you might want to send.
--
To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in
the body of a message to [e-mail]
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Anand Jain Oct. 6, 2014, 9:31 a.m. UTC | #2

I am running some tests with larger disks pool (48 disks).
  With that the performance of the various scan methods are as below..

----
scanning BTRFS_SCAN_LBLKID
real    0m0.330s
user    0m0.005s
sys     0m0.026s

scanning BTRFS_SCAN_DEV
real    0m0.010s
user    0m0.002s
sys     0m0.005s

scanning BTRFS_SCAN_PROC
real    0m0.010s
user    0m0.002s
sys     0m0.005s
-----

  This is the time taken to scan 48disks one time by various methods
  we have/had - but our progs do this scan 30times for btrfs fi show.
  yep 30times as show below.. I am working to fix it.

-------
                                 Function: time(us)    count  avg(us)
::
                          get_device_info:     1034       27       38
                     pretty_size_snprintf:     1218      124        9
                    btrfs_scan_one_device:     1790      186        9
                     btrfs_read_dev_super:     1956      116       16
                                 cmd_show:    15418      335       46
                        btrfs_scan_lblkid:   148477       30     4949
-------

  IMO we should still stick to LBLKID scan.
  Just a thought - any idea if its better to provide a compile time
  fallback scan switch, just in case if something fails with lblkid. ?


Thanks, Anand


On 09/24/14 01:00, David Sterba wrote:
> Hi,
>
> all 5 patches will be in the next integration. I haven't tested them
> yet, seems it's a bit more important to make a more stable devel base
> for more updates you might want to send.
> --
> To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in
> the body of a message to [e-mail]
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
>
--
To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in
the body of a message to [e-mail]
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Anand Jain Oct. 23, 2014, 1:12 p.m. UTC | #3

my stap func profiling script was wrong, I got the number of
  times scan_lblkid func called per thread wrong, now its
  been corrected as below. yet calling the system-wide device
  scan more than once per thread does not make any sense. There
  are quite a number of threads like that as below. The worst is
  mkfs.btrfs which calls n number of times, where n is number of
  disk being mkfs-ed.


   btrfs-find-root            1
   btrfs rescue super-recover 2
   btrfs-debug-tree           1
   btrfs-image -r             2
   btrfs check                2
   btrfs restore              2
   calc-size                  NC
   btrfs-corrupt-block        NC
   btrfs-image                NC
   btrfs-map-logical          1
   btrfs-select-super         NC
   btrfstune                  2
   btrfs-zero-log             NC
   tester                     NC
   quick-test.c               NC
   btrfs-convert              0
   mkfs                       #number of devices to be mkfs
   btrfs label set unmounted  2
   btrfs get label unmounted  2






On 10/06/14 17:31, Anand Jain wrote:
>
>
>   I am running some tests with larger disks pool (48 disks).
>   With that the performance of the various scan methods are as below..
>
> ----
> scanning BTRFS_SCAN_LBLKID
> real    0m0.330s
> user    0m0.005s
> sys     0m0.026s
>
> scanning BTRFS_SCAN_DEV
> real    0m0.010s
> user    0m0.002s
> sys     0m0.005s
>
> scanning BTRFS_SCAN_PROC
> real    0m0.010s
> user    0m0.002s
> sys     0m0.005s
> -----
>
>   This is the time taken to scan 48disks one time by various methods
>   we have/had - but our progs do this scan 30times for btrfs fi show.
>   yep 30times as show below.. I am working to fix it.
>
> -------
>                                  Function: time(us)    count  avg(us)
> ::
>                           get_device_info:     1034       27       38
>                      pretty_size_snprintf:     1218      124        9
>                     btrfs_scan_one_device:     1790      186        9
>                      btrfs_read_dev_super:     1956      116       16
>                                  cmd_show:    15418      335       46
>                         btrfs_scan_lblkid:   148477       30     4949
> -------
>
>   IMO we should still stick to LBLKID scan.
>   Just a thought - any idea if its better to provide a compile time
>   fallback scan switch, just in case if something fails with lblkid. ?
>
>
> Thanks, Anand
>
>
> On 09/24/14 01:00, David Sterba wrote:
>> Hi,
>>
>> all 5 patches will be in the next integration. I haven't tested them
>> yet, seems it's a bit more important to make a more stable devel base
>> for more updates you might want to send.
>> --
>> To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in
>> the body of a message to [e-mail]
>> More majordomo info at  http://vger.kernel.org/majordomo-info.html
>>
> --
> To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in
> the body of a message to [e-mail]
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
--
To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in
the body of a message to [e-mail]
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Patch

diff --git a/cmds-device.c b/cmds-device.c
index d7af090..ad0bd35 100644
--- a/cmds-device.c
+++ b/cmds-device.c
@@ -223,7 +223,7 @@  static int cmd_scan_dev(int argc, char **argv)
 			break;
 		switch (c) {
 		case 'd':
-			where = BTRFS_SCAN_DEV;
+			where = BTRFS_SCAN_PROC;
 			all = 1;
 			break;
 		default:
diff --git a/cmds-filesystem.c b/cmds-filesystem.c
index d8b6938..818e05f 100644
--- a/cmds-filesystem.c
+++ b/cmds-filesystem.c
@@ -563,7 +563,7 @@  static int cmd_show(int argc, char **argv)
 			break;
 		switch (c) {
 		case 'd':
-			where = BTRFS_SCAN_DEV;
+			where = BTRFS_SCAN_PROC;
 			break;
 		case 'm':
 			where = BTRFS_SCAN_MOUNTED;
@@ -587,7 +587,7 @@  static int cmd_show(int argc, char **argv)
 		 * right away
 		 */
 		if (type == BTRFS_ARG_BLKDEV) {
-			if (where == BTRFS_SCAN_DEV) {
+			if (where == BTRFS_SCAN_PROC) {
 				/* we need to do this because
 				 * legacy BTRFS_SCAN_DEV
 				 * provides /dev/dm-x paths
@@ -618,7 +618,7 @@  static int cmd_show(int argc, char **argv)
 		}
 	}
 
-	if (where == BTRFS_SCAN_DEV)
+	if (where == BTRFS_SCAN_PROC)
 		goto devs_only;
 
 	/* show mounted btrfs */