linux-fsdevel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Christoph Hellwig <hch@lst.de>
To: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Cc: Christoph Hellwig <hch@lst.de>,
	Linus Torvalds <torvalds@linux-foundation.org>,
	Tejun Heo <tj@kernel.org>,
	linux-fsdevel@vger.kernel.org
Subject: Re: odd sysfs find behavior, was: Re: [PATCH v6 00/10] Implement NVMe Namespace Descriptor Identification
Date: Sun, 18 Jun 2017 09:32:49 +0200	[thread overview]
Message-ID: <20170618073249.GA25797@lst.de> (raw)
In-Reply-To: <20170618011250.GA1987@kroah.com>

On Sun, Jun 18, 2017 at 09:12:50AM +0800, Greg Kroah-Hartman wrote:
> > 
> > root@testvm:~/nvmetcli# find /sys -name uuid
> > root@testvm:~/nvmetcli# find /sys -name uuid
> > /sys/devices/virtual/nvme-fabrics/ctl/nvme2/nvme2n1/uuid
> > 
> > so just repeating the find a second time makes it work!  Looks like
> > there is some sort of lazy population scheme in sysfs..
> 
> There is a lazy population scheme in sysfs, but that means that things
> are only populated in memory when we actually look for them, not the
> second time around only :)
> 
> I just tried this on my laptop which does have a nvme block device in
> it, and it worked just fine both times.

Note that the search is for an attribute in the sysfs dir, but trying
to search for the device it doesn't make any difference.

> As Linus said, a strace would be great.

Both straces attached (gzipped due to size).  Note that this on a system
with four NVMe devices, two of which are nvme-loop devices that have the
uuid attribute.

  reply	other threads:[~2017-06-18  7:32 UTC|newest]

Thread overview: 10+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
     [not found] <20170607094536.32419-1-jthumshirn@suse.de>
     [not found] ` <20170615163141.GA27307@lst.de>
     [not found]   ` <bab953e9-7026-5833-9f65-1ef8b90433d7@suse.de>
     [not found]     ` <20170616094056.GA12465@lst.de>
     [not found]       ` <905ed2e6-1c1c-f3a3-5391-66e42fb61861@suse.de>
     [not found]         ` <20170616095837.GA14217@lst.de>
     [not found]           ` <CA+55aFxJ0bpRFsnZFe6sh2i4jxNdYmDi_6RZx2CQQdmQ_HU3wQ@mail.gmail.com>
2017-06-17 12:08             ` odd sysfs find behavior, was: Re: [PATCH v6 00/10] Implement NVMe Namespace Descriptor Identification Christoph Hellwig
2017-06-18  1:12               ` Greg Kroah-Hartman
2017-06-18  7:32                 ` Christoph Hellwig [this message]
     [not found]                   ` <20170618073305.GB25797@lst.de>
2017-06-18 10:20                     ` Tejun Heo
2017-06-18 10:32                       ` Tejun Heo
2017-06-18 13:43                       ` Christoph Hellwig
2017-06-19 17:59                         ` Tejun Heo
2017-06-21 14:48                           ` Greg Kroah-Hartman
2017-06-21 15:36                             ` Tejun Heo
2017-06-22  0:21                           ` Linus Torvalds

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20170618073249.GA25797@lst.de \
    --to=hch@lst.de \
    --cc=gregkh@linuxfoundation.org \
    --cc=linux-fsdevel@vger.kernel.org \
    --cc=tj@kernel.org \
    --cc=torvalds@linux-foundation.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).