Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > linux.kernel > #1666858 > unrolled thread

Re: [PATCH v6 00/10] Implement NVMe Namespace Descriptor Identification

Back to article view | Back to linux.kernel

This discussion starts older than the indexed window; earlier articles aren't shown. The article labeled Started by below is the oldest one visible, not the original post.

Contents

  Re: [PATCH v6 00/10] Implement NVMe Namespace Descriptor         Identification Christoph Hellwig <hch@lst.de> - 2017-06-15 18:40 +0200
    Re: [PATCH v6 00/10] Implement NVMe Namespace Descriptor  Identification Johannes Thumshirn <jthumshirn@suse.de> - 2017-06-16 10:30 +0200
      Re: [PATCH v6 00/10] Implement NVMe Namespace Descriptor         Identification Christoph Hellwig <hch@lst.de> - 2017-06-16 11:50 +0200
        Re: [PATCH v6 00/10] Implement NVMe Namespace Descriptor  Identification Johannes Thumshirn <jthumshirn@suse.de> - 2017-06-16 11:50 +0200
          Re: [PATCH v6 00/10] Implement NVMe Namespace Descriptor  Identification Johannes Thumshirn <jthumshirn@suse.de> - 2017-06-16 12:00 +0200
          Re: [PATCH v6 00/10] Implement NVMe Namespace Descriptor         Identification Christoph Hellwig <hch@lst.de> - 2017-06-16 12:00 +0200
            Re: [PATCH v6 00/10] Implement NVMe Namespace Descriptor Identification Linus Torvalds <torvalds@linux-foundation.org> - 2017-06-16 15:30 +0200

#1666858 — Re: [PATCH v6 00/10] Implement NVMe Namespace Descriptor Identification

On Wed, Jun 07, 2017 at 11:45:27AM +0200, Johannes Thumshirn wrote:
> A patch for nvmetcli and nvme-cli will follow shortly.

Can you send them out?  Especially as I want to debug why I don't seem
to get a uuid attribute with nvme-loop despite the fact that we should
always have one.

[toc] | [next] | [standalone]

#1667520 — Re: [PATCH v6 00/10] Implement NVMe Namespace Descriptor Identification

On 06/15/2017 06:31 PM, Christoph Hellwig wrote:
> On Wed, Jun 07, 2017 at 11:45:27AM +0200, Johannes Thumshirn wrote:
>> A patch for nvmetcli and nvme-cli will follow shortly.
> 
> Can you send them out?  Especially as I want to debug why I don't seem
> to get a uuid attribute with nvme-loop despite the fact that we should
> always have one.

Strange, as I tested with nvme-loop all the time...


-- 
Johannes Thumshirn                                          Storage
jthumshirn@suse.de                                +49 911 74053 689
SUSE LINUX GmbH, Maxfeldstr. 5, 90409 Nürnberg
GF: Felix Imendörffer, Jane Smithard, Graham Norton
HRB 21284 (AG Nürnberg)
Key fingerprint = EC38 9CAB C2C4 F25D 8600 D0D0 0393 969D 2D76 0850

[toc] | [prev] | [next] | [standalone]

#1667590

On Fri, Jun 16, 2017 at 10:20:04AM +0200, Johannes Thumshirn wrote:
> Strange, as I tested with nvme-loop all the time...

Yeah, it's actually there, but for some reason find on sysfs
behaves strange:

root@testvm:~# find /sys -name uuid
root@testvm:~# cat /sys/class/nvme/nvme2/nvme2n1/uuid 
6665a65b-f42f-469b-800e-a047238649eb

[toc] | [prev] | [next] | [standalone]

#1667592 — Re: [PATCH v6 00/10] Implement NVMe Namespace Descriptor Identification

On 06/16/2017 11:40 AM, Christoph Hellwig wrote:
> On Fri, Jun 16, 2017 at 10:20:04AM +0200, Johannes Thumshirn wrote:
>> Strange, as I tested with nvme-loop all the time...
> 
> Yeah, it's actually there, but for some reason find on sysfs
> behaves strange:
> 
> root@testvm:~# find /sys -name uuid
> root@testvm:~# cat /sys/class/nvme/nvme2/nvme2n1/uuid 
> 6665a65b-f42f-469b-800e-a047238649eb

Wasn't there something that find on sysfs isn't reliable?

Anyways, my shock's gone now.

-- 
Johannes Thumshirn                                          Storage
jthumshirn@suse.de                                +49 911 74053 689
SUSE LINUX GmbH, Maxfeldstr. 5, 90409 Nürnberg
GF: Felix Imendörffer, Jane Smithard, Graham Norton
HRB 21284 (AG Nürnberg)
Key fingerprint = EC38 9CAB C2C4 F25D 8600 D0D0 0393 969D 2D76 0850

[toc] | [prev] | [next] | [standalone]

#1667598 — Re: [PATCH v6 00/10] Implement NVMe Namespace Descriptor Identification

On 06/16/2017 11:58 AM, Christoph Hellwig wrote:
> Heh.  Now we just need the nvme-cli patches to verify it independently :)

I'm on it ;-)

-- 
Johannes Thumshirn                                          Storage
jthumshirn@suse.de                                +49 911 74053 689
SUSE LINUX GmbH, Maxfeldstr. 5, 90409 Nürnberg
GF: Felix Imendörffer, Jane Smithard, Graham Norton
HRB 21284 (AG Nürnberg)
Key fingerprint = EC38 9CAB C2C4 F25D 8600 D0D0 0393 969D 2D76 0850

[toc] | [prev] | [next] | [standalone]

#1667601

On Fri, Jun 16, 2017 at 11:48:32AM +0200, Johannes Thumshirn wrote:
> On 06/16/2017 11:40 AM, Christoph Hellwig wrote:
> > On Fri, Jun 16, 2017 at 10:20:04AM +0200, Johannes Thumshirn wrote:
> >> Strange, as I tested with nvme-loop all the time...
> > 
> > Yeah, it's actually there, but for some reason find on sysfs
> > behaves strange:
> > 
> > root@testvm:~# find /sys -name uuid
> > root@testvm:~# cat /sys/class/nvme/nvme2/nvme2n1/uuid 
> > 6665a65b-f42f-469b-800e-a047238649eb
> 
> Wasn't there something that find on sysfs isn't reliable?

Looks like it.  Which is a pitty.

> Anyways, my shock's gone now.

Heh.  Now we just need the nvme-cli patches to verify it independently :)

[toc] | [prev] | [next] | [standalone]

#1667745 — Re: [PATCH v6 00/10] Implement NVMe Namespace Descriptor Identification

On Fri, Jun 16, 2017 at 6:58 PM, Christoph Hellwig <hch@lst.de> wrote:
> On Fri, Jun 16, 2017 at 11:48:32AM +0200, Johannes Thumshirn wrote:
>> >
>> > Yeah, it's actually there, but for some reason find on sysfs
>> > behaves strange:
>> >
>> > root@testvm:~# find /sys -name uuid
>> > root@testvm:~# cat /sys/class/nvme/nvme2/nvme2n1/uuid
>> > 6665a65b-f42f-469b-800e-a047238649eb
>>
>> Wasn't there something that find on sysfs isn't reliable?
>
> Looks like it.  Which is a pitty.

Hmm. The *traditional* reason for this particular 'find' oddity is
that find has an optimization which will look at the nlink count of a
directory to decide how many subdirectories it can have.

So when 'find' then traverses the directory tree, once it has found
all the subdirectories it expects, it will stop traversing any further
subdirectories.

The reason for this is that it can then avoid doing the 'lstat()' on
each directory entry to even figure out what kind of file it is (ie
directory vs regular file etc). I forget the exact rules, but it
basically depends on nlink being "2+umber of subdirectories". I wonder
if the sysfs code gets this wrong for some cases.

All the directories I have on the laptop I'm on right now get it
right, but maybe nvme triggers something.

You can check with some silly shell scripts, and do things like

    stat -c %h /sys/class/nvme

and then compare that to the number of subdirectories (the link count
should be 2 higher - the parent entry and the '.' entry).

The traditional *fix* for this is to just set "nlink" to 1 for a
directory, which tells 'find' to not use this optimization. That's
what filesystems like VFAT do, that don't count subdirectories. But
sysfs should get the directory count right.

I can't imagine any other reason why 'find' would screw up.

                    Linus

[toc] | [prev] | [standalone]

Back to top | Article view | linux.kernel

csiph-web