As mentioned before, I have flashed LibreCMC on TP-LINK WR1043ND v1.6 with WiFi disabled. It is my backup router. Because my ISP support 2 IPs, and the new cable modem does come with 2 ethernet ports, I have one port connecting to my DIR-882 (using Padavan firmware) serving the main floor and my bedroom in 2nd floor with WiFi enabled. The 2nd port is now connected to TP-Link WR1043 in the study room. Now, I want to create a separate VLAN for miner, so, it is separated from my test equipment. So, I update LibreCMC to 1.5.14. It requires the "Keep Settings" to be unchecked for the upgrade. Please check the link below before proceed. Since it was a backup router, it does not matter for me if the settings are wiped.
Releases - Gogs (librecmc.org)
There is not many guides in the internet for LibreCMC. Since it is based on OpenWrt 19.x, I check the youtube guide below.
How to Create a VLAN - A Beginner's Guide // OpenWrt Router (Up to 19.x) - YouTube
First step is to go to Network > Switches. You will see VLAN 1 and 2 populated already. Now, add a new switches with VLAN 5. I pick LAN port 3 for VLAN 5 which will be used by the miner. VLAN 1 will be used for test equipment (LAN port 1, 2 4).
I decide to try Tumbleweed on the same old FX-8320 host. Installation is similar to LEAP 15.4. For GUI option, I choose Generic Desktop instead of XFCE Desktop. XFCE is running quite smoothly in LEAP 15.4. I decide to try Generic Desktop this time since it is only a physical host.
Follow the same link below, I try to install driver version G05 for my old GT630 (does not work with LEAP 15.4).
SDB:NVIDIA drivers - openSUSE Wiki
Reboot the host and it suggests to install the previous version G04. Follow the wiki link above and install G04.
Then install VirtualBox. Reference link is How to install Virtualbox on OpenSUSE Tumbleweed & Leap - Linux Shout (how2shout.com.
After Isilon was implemented 2.5 yrs ago, we decided to stop SmartPool jobs and use combination of IndexUpdate and FilePolicy job to save resources on the Isilon. We have 4 SSD nodes handling front end traffic, 4 hybrid nodes handling replication plus some test traffic and 4 SATA nodes handling the backup. Initially, SATA nodes were deployed with insufficient memory and caused couple of outages during NDMP backup. After max the memory on SATA nodes, there are no more issue after that.
Because we want to keep as much data as possible on SSD, we won't run FilePolicy until SSD used space is over 70%. After firmware update (nodes reboot), we saw data move between Tiers with multiscan kicking in auto. That's about 2 yrs ago. Checked with support and they said it's ok to kill it. So, we just killed the Mutliscan job. Recently, we finally had our first disk failed on the production Isilon and Multiscan was kicked in auto. Same as before, we saw data moving unexpectedly to SATA tier. I suspected if that's related to FilePolicy. However, I was told it should not by support. After case with support for a long time, we finally got the suggestion from higher level of support to run SmartPool job periodically. So, I play with the DR Isilon since it is not busy. Using IndexUpdate and FilePolicy job to move the data and compare the tier usage multiple times, each tier finally reached to the utilization I want 60-70% for SSD and below 60% for SAS pool (the spillover pool). Then, kick off MultiScan job. Now, I don't see any more data move between tiers with MultiScan job.
In the future, I will adjust the FilePolicy each month and then kick off the SmartPool job once a month just in case Multiscan is started due to failed HDD or node replacement.
===========================================================================
Update Sep 25, 2023
For Production Isilon, after IndexUpdate completes, I run FilePolicy then Multiscan job. I still see data moves to SATA pool. So, I run IndexUpdate -> FilePolicy -> SmartPool job. Same things. Looks like there is discrepancy between IndexUpdate + FilePolicy and SmartPool job.
This time, I just run SmartPool job and kill it once SATA pool reaches 85%. Then adjust the FilePolicy and rerun it SmartPool job. After 3 tries, I finally see the results I want. Why there is a discrepancy between FilePolicy and SmartPool job, I have no idea.
From now on, I will adjust the FilePolicy once every 2 months and run the SmartPool job. For DR Isilon, since it has far less data, I will adjust FilePolicy once every 3-4 month and then run SmartPool job.
Switch to TC4400 cable modem for a few months because DOCSIS 3.0 will not be supported by my cable company. This is the only one not using Puma chipset and supported by my cable company. It worked fine until recently. The internet connection drops few times day. When I touch it, the modem is really hot. The quick fix is to put a little 15mm by 15mm fan on the top of modem to draw the heat away from it. Now, it is much better and has not experienced any more connection drop.
I always get that question for the SQL or file cluster RDM disks. Windows admin and DBA thought the format hung but it indeed took long time to quick format a lun. Last week, Windows admin complaint it took approx an hour to quick format a 7TB lun in EMC PMAX for a Windows 2016 / 2019 VM.
I just completed a test this morning. For a physical Windows 2016 server, it took about 10-15 min approx to quick format a Windows 1 TB lun in PMAX. Do some research in the internet. The result provided by partitionwizard.com suggests it indeed takes long time to format a big lun (see below also).
To run mkfs without trim, use the -K option on XFS and -E nodiscard on ext4
XFS
mkfs.xfs -K /dev/sdx
EXT4
mkfs.ext4 -E nodiscard
Warning: Only use -K or -E on new volumes with no existing data.
Using the -K or -E options on drives with existing data, will cause the space to be wasted until the data is overwritten.
Depending on the distro of Linux, I have tough time to install VM Tools on some of them. The only other option is to install open vmtools.
Follow VMware instructions to install the open vmtools.
If GUI is required on the VM and assume it is Debian distro, install open-vm-tools-desktop.
sudo apt-get install open-vm-tools-desktop
Otherwise open-vm-tools will be sufficient.
sudo apt-get install open-vm-tools
We used to have SNMP to monitor all FC port down event. However, it causes a lot of un-necessary calls from NOC after hours. Because we have most of the prod servers setup with 4 HBAs, we decide to use SMTP alert to email to storage team members only. However, it never seems to work with DCNM. We did see Port up alert but not for Port down regardless of what settings we choose.
After opening a ticket with support, we were told the setting was disable by default. If you want to receive email alerts for port down event, go to Server Properties of DCNM. Look for event.linkDown.log and set it to True. By default, it is set to False. Then restart the DCNM services and port down alerts will be sent to your SMTP server depending on your setup.
Check the bug info at Cisco site for CSCvz61883 / EMC article 000197332 and it applies to the MDS 9700 32G FC modules in our environment. The DS-X9648-1536K9 linecard in MDS 9700 can be affected at almost exactly 468 days of uptime.
Our MDS 9710 with 32G linecard are running 8.1(1a) with supervisor 3 and 8.4(1a) with supervisor 4. Runs the command below against the 32G linecard in MDS9710 to see module uptime. In our environment, they reach 426 and 417 days respectively.
slot x show system uptime
8.4(2d) does provide the fix to the issue but it is quite new. Open a ticket with support and the recommendation is to upgrade to 8.4(2c). This will reset the module uptime back to zero and buy another 400+ days. With 8.4(2), there is a workaround to reset the uptime for the device non-disruptively. You can consider another firmware update after 400 days on the FC switch.
Finished the upgrade to 8.4(2c) last week. Upgrade to 8.4(2c) on MDS 9710 with supervisor 3 is much faster than MDS 9710 with supervisor 4.
=================================================================
Updated in late May 2023
Another reason we never considered 8.4(2d) was due to CSCwb29379 (see release notes 8.4(2e) below)
Cisco MDS 9000 Series Release Notes, Release 8.4(2e)
8.4(2e) was available for quite some time now. So, we upgraded to 8.4(2e) couple weeks ago to fix this problem permanently.