Re: [OmniOS-discuss] nfsv3rwsnoop.d lists NFS writes to files

[Richard Elling]

> On Mar 22, 2017, at 12:54 AM, Richard Skelton  wrote:
> 
> Hi Richard,
> The nfsv3rwsnoop.d script shows to offset to the write as 0 is this then not 
> a new file?

not necessarily

> TIME(us) CLIENT OP OFFSETBYTES PATHNAME
> 20811423544560   xxx.xx.xxx.21   W 0   116 
> 20811423525741   xxx.xx.xxx.50   W 0  5232 
> 20811423528311   xxx.xx.xxx.50   W 0   304 
> 20811423529251   xxx.xx.xxx.50   W 0   376 
> 20811423555753   xxx.xx.xxx.18   R 0   685 
> If they are files which have been deleted they must be very short lived files 
> ?

not necessarily

If you want auditing, you need auditing tools and dtrace is not the right tool
 -- richard

> 
> Richard Elling wrote:
>> 
>> 
>>> On Mar 21, 2017, at 3:54 PM, Richard Skelton >> > wrote:
>>> 
>>> Hi,
>>> I am using the dtrace script nfsv3rwsnoop.d to find file that are accessed 
>>> from my OmniOS r151020 filer and some file names are listed as unknown :-(
>>> I guess they are files that have been open for a long time and have dropped 
>>> out of some data structure.
>> 
>> almost... they are files that were open prior to the dtrace script running 
>> or they are files
>> which have been deleted (!), such that there is no mapping between the nfs 
>> file handle and
>> the current file system
>> 
>>> Is there any way to increase the persistence of the name stored.
>>> I have lots on memory in this system and would be happy to sacrifice some 
>>> if I could see more file name :-)
>> 
>> depending on what you wish to accomplish, dtrace might be the wrong tool and 
>> you might
>> want auditing or NFS logging instead 
>>  — richard
>> 
>>> 
>>> root@filer:/scratch# /root/dtrace/nfsv3rwsnoop.d |more
>>> 1189849649391xxx.xx.xxx.59   W 10500138879 
>>> 1189849649582xxx.xx.xxx.59   W 10500137788 
>>> 1189849740621xxx.xx.xxx.118  W 0  2404 
>>> 1189849781136xxx.xx.xxx.109  W 19832756675 /scratch/run.log
>>> 1189849849301xxx.xx.xxx.102  W 1096  57513 
>>> /scratch/avm_remote_job_f64ccf56-efa1-4605-8a48-874816779289_2.out
>>> Cheers
>>> Richard
>>> 
>>> 
>>> ___
>>> OmniOS-discuss mailing list
>>> OmniOS-discuss@lists.omniti.com 
>>> http://lists.omniti.com/mailman/listinfo/omnios-discuss 
>>> 
>> 

___
OmniOS-discuss mailing list
OmniOS-discuss@lists.omniti.com
http://lists.omniti.com/mailman/listinfo/omnios-discuss

Re: [OmniOS-discuss] OmniOS r151020: Setup won't see my NVMe disk

[Dan McDonald]

> On Mar 22, 2017, at 12:15 PM, Arne  
> wrote:
> 
> What is the impact of this bug with libnvpair?
> 
> a) Is this only responsible for non-working "prtconf"? (I guess "prtconf" is 
> some kind of system overview tool!?)

Correct.

> b) Is it also responsible for the non-working NVMe SSD?

No.  Not correct.

Please try this ISO:

http://kebe.com/~danmcd/webrevs/r151021-kayak.iso

which now has a working prtconf (because /lib/amd64/libnvpair.so... is now 
there).  Then please share "prtconf -v" and "prtconf -vp" output.  (You should 
be able to bring up a network interface using the installer shell.)

Thanks,
Dan

___
OmniOS-discuss mailing list
OmniOS-discuss@lists.omniti.com
http://lists.omniti.com/mailman/listinfo/omnios-discuss

Re: [OmniOS-discuss] OmniOS r151020: Setup won't see my NVMe disk

[Arne]

What is the impact of this bug with libnvpair?

a) Is this only responsible for non-working "prtconf"? (I guess 
"prtconf" is some kind of system overview tool!?)


b) Is it also responsible for the non-working NVMe SSD?


 Original Message  
Subject: Re: [OmniOS-discuss] OmniOS r151020: Setup won't see my NVMe disk
From: Dan McDonald 
To: Arne , Dan McDonald 


Date: Wed Mar 22 2017 16:00:14 GMT+0100



It means we need to add at least libnvpair to the Kayak-for-ISO wad.  Thank you 
for finding this bug.

Dan


___
OmniOS-discuss mailing list
OmniOS-discuss@lists.omniti.com
http://lists.omniti.com/mailman/listinfo/omnios-discuss

Re: [OmniOS-discuss] OmniOS r151020: Setup won't see my NVMe disk

[Dan McDonald]

> On Mar 22, 2017, at 3:28 AM, Arne  wrote:
> 
> This is the output of "prtconf -vp":
> 
> System Configuration:  Supermicro  i86pc
> Memory size: 65358 Megabytes
> System Peripherals (PROM Nodes):
> 
> ld.so.1: prtconf: fatal: libnvpair.so.1: open failed: No such file or 
> directory
> ld.so.1: prtconf: fatal: relocation error: file /usr/sbin/amd64/prtconf: 
> symbol nvlist_unpack: referenced symbol not found
> Killed
> 
> 
> So something seems wrong here as well...

It means we need to add at least libnvpair to the Kayak-for-ISO wad.  Thank you 
for finding this bug.

Dan

___
OmniOS-discuss mailing list
OmniOS-discuss@lists.omniti.com
http://lists.omniti.com/mailman/listinfo/omnios-discuss

Re: [OmniOS-discuss] nfsv3rwsnoop.d lists NFS writes to files

[Richard Skelton]

Hi Richard,
The nfsv3rwsnoop.d script shows to offset to the write as 0 is this then
not a new file?

TIME(us) CLIENT OP OFFSETBYTES PATHNAME
20811423544560   xxx.xx.xxx.21   W 0   116 
20811423525741   xxx.xx.xxx.50   W 0  5232 
20811423528311   xxx.xx.xxx.50   W 0   304 
20811423529251   xxx.xx.xxx.50   W 0   376 
20811423555753   xxx.xx.xxx.18   R 0   685 

If they are files which have been deleted they must be very short lived
files ?

Richard Elling wrote:
>
>> On Mar 21, 2017, at 3:54 PM, Richard Skelton > > wrote:
>>
>> Hi,
>> I am using the dtrace script nfsv3rwsnoop.d to find file that are
>> accessed from my OmniOS r151020 filer and some file names are listed
>> as unknown :-(
>> I guess they are files that have been open for a long time and have
>> dropped out of some data structure.
>
> almost... they are files that were open prior to the dtrace script
> running or they are files
> which have been deleted (!), such that there is no mapping between the
> nfs file handle and
> the current file system
>
>> Is there any way to increase the persistence of the name stored.
>> I have lots on memory in this system and would be happy to sacrifice
>> some if I could see more file name :-)
>
> depending on what you wish to accomplish, dtrace might be the wrong
> tool and you might
> want auditing or NFS logging instead 
>  — richard
>
>>
>> root@filer:/scratch# /root/dtrace/nfsv3rwsnoop.d |more
>>
>> 1189849649391xxx.xx.xxx.59   W 10500138879 
>> 1189849649582xxx.xx.xxx.59   W 10500137788 
>> 1189849740621xxx.xx.xxx.118  W 0  2404 
>> 1189849781136xxx.xx.xxx.109  W 19832756675 /scratch/run.log
>> 1189849849301xxx.xx.xxx.102  W 1096  57513
>> /scratch/avm_remote_job_f64ccf56-efa1-4605-8a48-874816779289_2.out
>>
>> Cheers
>> Richard
>>
>>
>> ___
>> OmniOS-discuss mailing list
>> OmniOS-discuss@lists.omniti.com 
>> http://lists.omniti.com/mailman/listinfo/omnios-discuss
>
___
OmniOS-discuss mailing list
OmniOS-discuss@lists.omniti.com
http://lists.omniti.com/mailman/listinfo/omnios-discuss

Re: [OmniOS-discuss] OmniOS r151020: Setup won't see my NVMe disk

[Arne]

There is no file "/var/adm/messages" and there is no file "messages" 
anywhere else either ("find /var -name 'mess*'" returns nothing).


Under "/var/adm" there are only 4 directory ("exacct", "log", "pool", 
"streams", all of them are empty) and 2 files: "utmpx" and "wtmpx".

Neither of them matches "nvme".


This is the output of "prtconf -vp":

System Configuration:  Supermicro  i86pc
Memory size: 65358 Megabytes
System Peripherals (PROM Nodes):

ld.so.1: prtconf: fatal: libnvpair.so.1: open failed: No such file or 
directory
ld.so.1: prtconf: fatal: relocation error: file /usr/sbin/amd64/prtconf: 
symbol nvlist_unpack: referenced symbol not found

Killed


So something seems wrong here as well...


 Original Message  
Subject: Re: [OmniOS-discuss] OmniOS r151020: Setup won't see my NVMe disk
From: Dan McDonald 
To: Arne 
Date: Wed Mar 22 2017 01:21:13 GMT+0100



If it's NVMe 1.1, it should work with bloody.

I wonder if "grep nvme /var/adm/messages" would show you anything booting off 
of the bloody one.

Also, that "prtconf -vp" output I asked for earlier may be useful as well.

Dan


___
OmniOS-discuss mailing list
OmniOS-discuss@lists.omniti.com
http://lists.omniti.com/mailman/listinfo/omnios-discuss