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@xxxxxxxxxx> 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@xxxxxxxxxx > www.netapp.com > -- To unsubscribe from this list: send the line "unsubscribe linux-nfs" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
