mirror of https://lore.kernel.org/lkml/
 help / color / mirror / Atom feed
* [PATCH 1/1] NFS: fix sb->s_id in nfs debug prints
@ 2012-03-15 18:28 Vivek Trivedi
  2012-03-16  0:59 ` Myklebust, Trond
  0 siblings, 1 reply; 3+ messages in thread
From: Vivek Trivedi @ 2012-03-15 18:28 UTC (permalink / raw)
  To: Trond Myklebust, linux-nfs, linux-kernel; +Cc: Vivek Trivedi, Namjae Jeon

NFS bdi flush thread in ps output is printed like "flush-<major number
in decimal>:<minor number in decimal>"
For example:
$ ps aux | grep flush
 2079 root         0 SW   [flush-0:18]
                                 ^^^^

nfs_bdi_register()
==> bdi_register_dev()
==> bdi_register(bdi, NULL, "%u:%u", MAJOR(dev), MINOR(dev));
                             ^^^^^

However, NFS sb->s_id store major:minor number in hex:

nfs_initialise_sb()
==>         snprintf(sb->s_id, sizeof(sb->s_id),
                 "%x:%x", MAJOR(sb->s_dev), MINOR(sb->s_dev));
                  ^^^^^

If we enable nfs debug prints using command:
$ rpcdebug -m nfs -s all

write to a file:
$ dd if=/dev/zero of=<NFS Mount>/testfile.txt bs=32768 count=1

Without Patch:
[ 2431.032000] NFS:     0 initiated write call (req 0:12/40, 32768 bytes
@ offset 0)                                         ^^^^

With Patch:
[ 2431.032000] NFS:     0 initiated write call (req 0:18/40, 32768 bytes
@ offset 0)                                         ^^^^

We should store NFS "s->s_id" in decimal to avoid confusion between NFS
flush thread name(in ps output) and NFS debug prints.

Signed-off-by: Vivek Trivedi <vtrivedi018@gmail.com>
Signed-off-by: Namjae Jeon <linkinjeon@gmail.com>
---
 fs/nfs/super.c |    2 +-
 1 files changed, 1 insertions(+), 1 deletions(-)

diff --git a/fs/nfs/super.c b/fs/nfs/super.c
index 3dfa4f1..d64bc3c 100644
--- a/fs/nfs/super.c
+++ b/fs/nfs/super.c
@@ -2047,7 +2047,7 @@ static inline void nfs_initialise_sb(struct super_block *sb)
 
 	/* We probably want something more informative here */
 	snprintf(sb->s_id, sizeof(sb->s_id),
-		 "%x:%x", MAJOR(sb->s_dev), MINOR(sb->s_dev));
+		 "%u:%u", MAJOR(sb->s_dev), MINOR(sb->s_dev));
 
 	if (sb->s_blocksize == 0)
 		sb->s_blocksize = nfs_block_bits(server->wsize,
-- 
1.7.8.4


^ permalink raw reply	[flat|nested] 3+ messages in thread

* Re: [PATCH 1/1] NFS: fix sb->s_id in nfs debug prints
  2012-03-15 18:28 [PATCH 1/1] NFS: fix sb->s_id in nfs debug prints Vivek Trivedi
@ 2012-03-16  0:59 ` Myklebust, Trond
  2012-03-16  7:46   ` Vivek Trivedi
  0 siblings, 1 reply; 3+ messages in thread
From: Myklebust, Trond @ 2012-03-16  0:59 UTC (permalink / raw)
  To: Vivek Trivedi; +Cc: linux-nfs, linux-kernel, Namjae Jeon

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain; charset="utf-8", Size: 1656 bytes --]

On Thu, 2012-03-15 at 23:58 +0530, Vivek Trivedi wrote:
> NFS bdi flush thread in ps output is printed like "flush-<major number
> in decimal>:<minor number in decimal>"
> For example:
> $ ps aux | grep flush
>  2079 root         0 SW   [flush-0:18]
>                                  ^^^^
> 
> nfs_bdi_register()
> ==> bdi_register_dev()
> ==> bdi_register(bdi, NULL, "%u:%u", MAJOR(dev), MINOR(dev));
>                              ^^^^^
> 
> However, NFS sb->s_id store major:minor number in hex:
> 
> nfs_initialise_sb()
> ==>         snprintf(sb->s_id, sizeof(sb->s_id),
>                  "%x:%x", MAJOR(sb->s_dev), MINOR(sb->s_dev));
>                   ^^^^^
> 
> If we enable nfs debug prints using command:
> $ rpcdebug -m nfs -s all
> 
> write to a file:
> $ dd if=/dev/zero of=<NFS Mount>/testfile.txt bs=32768 count=1
> 
> Without Patch:
> [ 2431.032000] NFS:     0 initiated write call (req 0:12/40, 32768 bytes
> @ offset 0)                                         ^^^^
> 
> With Patch:
> [ 2431.032000] NFS:     0 initiated write call (req 0:18/40, 32768 bytes
> @ offset 0)                                         ^^^^
> 
> We should store NFS "s->s_id" in decimal to avoid confusion between NFS
> flush thread name(in ps output) and NFS debug prints.

Why do we care? The s_id is entirely filesystem-specific so it shouldn't
be compared to the properties of VFS objects anyway.

-- 
Trond Myklebust
Linux NFS client maintainer

NetApp
Trond.Myklebust@netapp.com
www.netapp.com

ÿôèº{.nÇ+‰·Ÿ®‰­†+%ŠËÿ±éݶ\x17¥Šwÿº{.nÇ+‰·¥Š{±þG«éÿŠ{ayº\x1dʇڙë,j\a­¢f£¢·hšïêÿ‘êçz_è®\x03(­éšŽŠÝ¢j"ú\x1a¶^[m§ÿÿ¾\a«þG«éÿ¢¸?™¨è­Ú&£ø§~á¶iO•æ¬z·švØ^\x14\x04\x1a¶^[m§ÿÿÃ\fÿ¶ìÿ¢¸?–I¥

^ permalink raw reply	[flat|nested] 3+ messages in thread

* Re: [PATCH 1/1] NFS: fix sb->s_id in nfs debug prints
  2012-03-16  0:59 ` Myklebust, Trond
@ 2012-03-16  7:46   ` Vivek Trivedi
  0 siblings, 0 replies; 3+ messages in thread
From: Vivek Trivedi @ 2012-03-16  7:46 UTC (permalink / raw)
  To: Myklebust, Trond; +Cc: linux-nfs, linux-kernel, Namjae Jeon

Trond,
I agree that s_id is fs specific.

If a NFS client is connected to multiple NFS servers and we want to
analyse NFS IO using rpcdebug prints, ps and top ..
If we store s_id in decimal, it will be a little easier to relate NFS
debug prints with *each* NFS flusher thread activity.

AFIK, In NFS, s_id is mainly used in debug prints, so storing s_id in
decimal may increase readability in NFS debug prints.

Is there any harm if we store NFS s_id in decimal ?
Please let me know your opinion.

Thanks,
Vivek

On Fri, Mar 16, 2012 at 6:29 AM, Myklebust, Trond
<Trond.Myklebust@netapp.com> wrote:
> On Thu, 2012-03-15 at 23:58 +0530, Vivek Trivedi wrote:
>> NFS bdi flush thread in ps output is printed like "flush-<major number
>> in decimal>:<minor number in decimal>"
>> For example:
>> $ ps aux | grep flush
>>  2079 root         0 SW   [flush-0:18]
>>                                  ^^^^
>>
>> nfs_bdi_register()
>> ==> bdi_register_dev()
>> ==> bdi_register(bdi, NULL, "%u:%u", MAJOR(dev), MINOR(dev));
>>                              ^^^^^
>>
>> However, NFS sb->s_id store major:minor number in hex:
>>
>> nfs_initialise_sb()
>> ==>         snprintf(sb->s_id, sizeof(sb->s_id),
>>                  "%x:%x", MAJOR(sb->s_dev), MINOR(sb->s_dev));
>>                   ^^^^^
>>
>> If we enable nfs debug prints using command:
>> $ rpcdebug -m nfs -s all
>>
>> write to a file:
>> $ dd if=/dev/zero of=<NFS Mount>/testfile.txt bs=32768 count=1
>>
>> Without Patch:
>> [ 2431.032000] NFS:     0 initiated write call (req 0:12/40, 32768 bytes
>> @ offset 0)                                         ^^^^
>>
>> With Patch:
>> [ 2431.032000] NFS:     0 initiated write call (req 0:18/40, 32768 bytes
>> @ offset 0)                                         ^^^^
>>
>> We should store NFS "s->s_id" in decimal to avoid confusion between NFS
>> flush thread name(in ps output) and NFS debug prints.
>
> Why do we care? The s_id is entirely filesystem-specific so it shouldn't
> be compared to the properties of VFS objects anyway.
>
> --
> Trond Myklebust
> Linux NFS client maintainer
>
> NetApp
> Trond.Myklebust@netapp.com
> www.netapp.com
>

^ permalink raw reply	[flat|nested] 3+ messages in thread

end of thread, other threads:[~2012-03-16  7:46 UTC | newest]

Thread overview: 3+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2012-03-15 18:28 [PATCH 1/1] NFS: fix sb->s_id in nfs debug prints Vivek Trivedi
2012-03-16  0:59 ` Myklebust, Trond
2012-03-16  7:46   ` Vivek Trivedi

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox

all inboxes | Powered by JetHome®