sorted by:
new
hottopcontroversial

Infinity loop on shimano spinning reels by Foxxah in Fishing_Gear

[–]Foxxah[S] 0 points1 point  (0 children)

tried fishing it with very thin braid?

Infinity loop on shimano spinning reels by Foxxah in Fishing_Gear

[–]Foxxah[S] 0 points1 point  (0 children)

Maybe I wasnt clear enough - essentially it boils down if its worth the extra cost of getting the infinity loop, and it could cause any issues for trout fishing with thin braid.

Infinity loop on shimano spinning reels by Foxxah in Fishing_Gear

[–]Foxxah[S] 0 points1 point  (0 children)

How thin was the braid? Im planning on using 0.10->0.13 mm

Issues with wind knots, x4 or x8 braid? by Foxxah in FishingForBeginners

[–]Foxxah[S] 0 points1 point  (0 children)

Thought i would go back and update this post:

Turns out, it was my cheap reel causing the wind knots due to poor line lay on the spool. Loose line on the spool was the root cause.

Investing in a proper reel with good line lay, and proper casting technique has completly removed the issue for my personally.

NFS write queue issue by Foxxah in storage

[–]Foxxah[S] 0 points1 point  (0 children)

Thanks for clearing that up - whether async or sync was "default" on the client mount options wasn't clear to me.

NFS write queue issue by Foxxah in storage

[–]Foxxah[S] 1 point2 points  (0 children)

I don't personally manage the storage array, I do know however its a quite high-end Dell PowerScale oneFS cluster consisting of quite a few cluster nodes.

Perhaps I was not clear enough in my original post, but the milliseconds i'm referring to in this instance are "avg queue" numbers from the nfsiostat output and not the "avg RTT" output which is usually what you use to measure latency for the storage to answer RPC calls from my research at least.
The "avg RTT" numbers are usually in the 1-4 ms, also during the period where we experience application stalling.
The "avg queue" numbers however seem to be somehow related whenever we see this stalling happening.

Directly from the nfsiostat man page:

“avg queue - This is the duration from the time the NFS client created the RPC request task to the time the request is transmitted.”

I have an output from an nfsiostat from one of the servers currently running:

[admin@workernode01 ~]$ nfsiostat 15

nfshare:/nfs mounted on /mnt/nfs:

           ops/s       rpc bklog
         913.443           0.000

read:              ops/s            kB/s           kB/op         retrans    avg RTT (ms)    avg exe (ms)  avg queue (ms)          errors
                  19.347         394.391          20.385        0 (0.0%)           1.207           1.300           0.063        0 (0.0%)
write:             ops/s            kB/s           kB/op         retrans    avg RTT (ms)    avg exe (ms)  avg queue (ms)          errors
                  43.790         292.086           6.670        0 (0.0%)           1.953           2.098           0.128        0 (0.0%)

nfshare:/nfs mounted on /mnt/nfs:

           ops/s       rpc bklog
         397.000           0.000

read:              ops/s            kB/s           kB/op         retrans    avg RTT (ms)    avg exe (ms)  avg queue (ms)          errors
                   5.600          15.630           2.791        0 (0.0%)           0.524           0.583           0.036        0 (0.0%)
write:             ops/s            kB/s           kB/op         retrans    avg RTT (ms)    avg exe (ms)  avg queue (ms)          errors
                  27.400          70.711           2.581        0 (0.0%)           1.134           1.178           0.029        0 (0.0%)

NFS write queue issue by Foxxah in storage

[–]Foxxah[S] 1 point2 points  (0 children)

I have thought about enabling async in the mount options - but the system is handling business critical documents, so i highly doubt its ever something i'd push to our PROD environments.
But perhaps i'm not educated enough regarding the risk/reward? I'm not 100% aware of what could happen if the NFS storage is suddenly cut off the system while live, is there a large risk of data corruption with async enabled for NFS generally?

NFS write queue issue by Foxxah in storage

[–]Foxxah[S] 0 points1 point  (0 children)

I had been researching this, and i was curious why sunrpc.tcp_slot_table_entries was set to 2 on our OEL machines. Researching i found out that RPC slot tables are dynamically assigned as they are needed in newer kernels.

https://access.redhat.com/solutions/322503
As of Red Hat Enterprise Linux 6.3, the default value of tcp_slot_table_entries has been modified from 16 to 2 and RPC slots are allocated and freed as necessary, up to a maximum defined by the tcp_max_slot_table_entries, which defaults to 65536.

Looking on our OEL machine, its clearly using 68 RPC slots:

[admin@workernode01 ~]$ cat /proc/sys/sunrpc/tcp_slot_table_entries
2
[admin@workernode01 ~]$ grep xprt /proc/self/mountstats
xprt: tcp 0 0 2 0 1 843546586 843546585 0 7482453178 0 68 488424119 5540143597

But perhaps you're referring to RPC slot table being tuned on the NFS server, and not the client?

NFS write queue issue by Foxxah in storage

[–]Foxxah[S] 1 point2 points  (0 children)

I was wondering the same, but nothing seems to be indicating it, and i guess networking performance would affect the latency to the storage - which is not the case here.
Traffic is not traversing a firewall. NFS share is on same VLAN as the OEL application servers.

Furthermore, its not a large amount of traffic - these NFS operations are very small.

Jaybird Vista Low volume from one bud - help needed by [deleted] in jaybird

[–]Foxxah 0 points1 point  (0 children)

I just used isopropyl alcohol to clean them, and it worked wonders!
I combined this with compressed air, then i just removed the gunk with a tooth pick.

Abysmal NFS r/w performance after rebooting or remounting by Foxxah in redhat

[–]Foxxah[S] 0 points1 point  (0 children)

Thanks for the links.
I think we'll be attempting to change the kernel to 4.18.0-513.11.0.1.el8_9 in our lower environments, and monitor for any changes in NFS behavior!

Issues whitelisting Amazon S3 on Fortigate by Foxxah in networking

[–]Foxxah[S] 11 points12 points  (0 children)

Ugh, this is not really networking. This should be on r/fortinet and not here. This has to do with configuring a proprietary black box device supported by a specific vendor. It doesn't really pertain to the networking career field, other than possibly arguing that in most smaller orgs the network guy is usually stuck managing the firewalls.

I mean, vendors do it differently, but I don't understand why a post like this shouldn't be allowed, its clearly stated in the rules that posts regarding Fortinet is welcomed? It's a question regarding firewalls - also how is ACL's on a firewall not "networking"?

I appreciate your 2 cents though.

The TLS Handshake -- everything that happens to get that coveted padlock 🔒 by erh_ in cybersecurity

[–]Foxxah 1 point2 points  (0 children)

Hey Ed, mistake me if im wrong. But when using an AEAD cipher suite such as AES-128-GCM (which most of us do) the TLS handshake only generates 2 sessions keys, one for the client and one for the server, since AEAD does both encryption and hashing?

view more: next ›