Sunday, April 24, 2016

How to Verify & Repair Permissions in OS X El Capitan

The Disk Utility app has long contained the ability to verify and repair disk permissions on a Mac, but in the latest versions of OS X this ability has been removed. That doesn’t mean you can’t verify permissions and repair permissions in OS X El Capitan 10.11 and later however, you just need to turn to the command line to do so.

To be clear, verifying and repairing disk permissions has long been over assigned as a remedy to all sorts of issues on the Mac, most of which are rarely accurate or legitimate. In this sense, repairing permissions is sort of considered a form of hocuspocus with little benefit to most OS X situations, but nonetheless there are some unique circumstances where you may want to verify and repair disk permissions in OS X anyway, particularly if a files permissions are actually off, meaning the ability for certain users and processes to read and write particular files and folders.
Note this is not the same as verifying and repairing a disk.

How to Repair Verify Disk Permissions in OS X El Capitan

Open the Terminal application (found in /Applications/Utilities/) and use the following syntax to verify a volumes permissions, this will verify the default root volume of a Mac:
sudo /usr/libexec/repair_packages --verify --standard-pkgs /
If you want to verify permissions on a different drive, specify the volume rather than “/”
The command will run and either show permissions that differ, or nothing, depending on what’s found. Not surprisingly, you’ll likely find some variation of permissions that differs, looking something like:
Permissions differ on "usr/libexec/cups/cgi-bin", should be drwxr-xr-x , they are dr-xr-xr-x .
Permissions differ on "usr/libexec/cups/daemon", should be drwxr-xr-x , they are dr-xr-xr-x .
Permissions differ on "usr/libexec/cups/driver", should be drwxr-xr-x , they are dr-xr-xr-x .
Permissions differ on "usr/libexec/cups/monitor", should be drwxr-xr-x , they are dr-xr-xr-x .

How to Repair Disk Permissions in OS X El Capitan from Command Line

Assuming permissions have been found which differ and you’d like to repair them, replace the –verify flag with –repair, and again point the command at the same volume:
sudo /usr/libexec/repair_packages --repair --standard-pkgs --volume /
Repairing permissions may take a while, just like it did from Disk Utility.
Verify and repair disk permissions in OS X from command line
If you execute the repair_packages command without sudo and with no specifications or flags, you’ll get a simple help guide instead:
$ /usr/libexec/repair_packages
Usage: repair_packages [ARGUMENTS]...

Commands:
--help Print this usage guide.
--list-standard-pkgs Display the package ids in the standard set.
--verify Verify permissions on files in the specified package(s).
--repair Repair permissions on files in the specified package(s).
Options:
--pkg PKGID Verify or repair the package PKGID.
--standard-pkgs Verify or repair the standard set of packages.
--volume PATH Perform all operations on the specified volume.
--output-format # Print progress info using a special output format.
--debug Print debuging information while running.

As suggested, this is not really something that should be run on a regular basis as any part of Mac maintenance routine, and it’s rarely necessary, which is likely why Apple pulled it from the Disk Utility application.
By the way, earlier releases of OS X also have a command line approach to repairing disk permissions, but it’s handled through the Disk Utility command line tool instead.

Tuesday, April 12, 2016

HP StorageWorks B-series SAN Switches - How to Interpret the Brocade porterrshow Output


Title: HP StorageWorks B-series SAN Switches - How to Interpret the Brocade porterrshow Output
Object Name: mmr_kc-0126648
Document Type: Support Information
Original owner: KCS - Storage SAN Infrastructure
Disclosure level: Public
Version state: final
Environment
FACT:HP StoreFabric B Series Switches
FACT:HP B-series SAN Switches
Questions/Symptoms
SYMPTOM:Interpreting Brocade Logs
SYMPTOM:Determining errors on Brocade Switch
SYMPTOM:CRC errors
Cause
CAUSE:Unknown
Answer/Solution
FIX:

The following document interprets and explains the porterrshow output (port errors) 
of Brocade SAN switches and possible causes of the errors.    
Details  When looked into the content of a Brocade supportShow or enter the standalone
portErrShow command via a Telnet session to the switch, the user will get a similar 
table like the following on the screen:             

  frames       enc  crc   too  too  bad  enc  disc link loss loss frjt fbsy   
  tx  rx       in   err  short long eof  out  c3   fail sync sig         
---------------------------------------------------------------------      
0:  3.8g  78m   0    0    0    0    0    1    0    0    1    1    0    0 
1:  3.7g 581m   0    0    0    0    0    1    0    0    1    1    0    0 
2:    0    0    0    0    0    0    0    0    0    0    0    0    0    0 
3:    0    0    0    0    0    0    0    0    0    0    0    0    0    0 
4:    0    0    0    0    0    0    0    0    0    0    0    0    0    0 
5:    0    0    0    0    0    0    0    0    0    0    0    0    0    0 
6:    0    0    0    0    0    0    0    0    0    0    0    0    0    0 
7:    0    0    0    0    0    0    0    0    0    0    0    0    0    0 
8:    0    0    0    0    0    0    0    0    0    0    0    0    0    0 
9:    0    0    0    0    0    0    0    0    0    0    0    0    0    0 
10: 660m 3.3g   0    0    0    0    0    9    0    3    7    2    0    0 
11:   0    0    0    0    0    0    0    0    0    0    0    0    0    0 
12:   0    0    0    0    0    0    0    0    0    0    0    0    0    0 
13:   0    0    0    0    0    0    0    0    0    0    0    0    0    0 
14: 176m 1.4g   0    0    0    0    0    0    0    0    1    1    0    0 
15: 1.4g 176m   1    1    1    0    1    4    0    2    2    0    0     0 
 
 
frames tx = Frames transmitted: The number of frames transmitted by the port. This number
is a statistic that provides a baseline for the error counters.    

frames rx = Frames received: The number of frames transmitted by the port. This number is
a statistic that provides a baseline for the error counters.   

enc in = Encoding errors inside frames: The number of 8b/10b encoding errors that have 
occurred inside frame boundaries. This counter is generally a zero value, although 
occasional errors may occur on a normal link and give a nonzero result. Minimum compliance with the link-bit error rate specification on a link continuously receiving frames would allow approximately one error every 20 minutes for 1 Gb/s. Reinitialization and reboots of associated Nx-port can also cause these errors. These errors are in the sum for the LLI errors.    

crcerr = Frames with Cyclic Redundancy Check errors: The number of frames that have 
failed a Cyclic Redundancy Check. The Cyclic Redundancy Check (CRC) is a four-byte field 
that shall immediately follow the Data Field and shall be used to verify the data integrity
of the frame header and Data Field. 

SOF (= Start-Of-Frame) and EOF (= End-Of-Frame) delimiters shall not be included in the CRC verification. The CRC field shall be calculated on the Frame header and Data Field prior to encoding for transmission and after decoding upon reception. The CRC field shall be aligned on a word boundary. For the purpose of CRC computation, the bit of the word-aligned four-byte field that corresponds to the first bit transmitted is the highest order bit. Frames that fail a CRC are noted but not modified and the destination device is responsible for rejecting and/or re-requesting the frame. Statistically, enc out errors alone imply cable problems, the enc out and crc err in combination implies GBIC/SFP problems. These errors are in the sum for the LLI errors     

too short = Frames shorter than minimum: The number of frames that are shorter than the minimum frame size (36 bytes + data frame size). Data frame size is a variable from 0 to 2112. These errors are in the sum for the LLI errors     

too long = Frames longer than maximum: The number of frames that are longer than the maximum frame size (36 bytes + data frame size). Data frame size is a variable from 0 to 2112. These errors are in the sum for the LLI errors     

bad eof = Frames with bad end-of-frame delimiters: The end-of-frame (EOF) delimiter is an ordered set that immediately follows the CRC. The EOF delimiter shall designate the end of the frame content and shall be followed by idles. There are three categories of EOF delimiters. One category of delimiter shall indicate that the frame is valid from the senders perspective and potentially valid from the receivers perspective. The second category shall indicate that the frame content is valid. This category shall only be used by an F-Port which receives a complete frame and decodes it before forwarding that frame on to another destination. The third category shall indicate the frame content is corrupted and the frame was truncated during transmission. The third category shall be used by both N-Ports and F-Ports to indicate an internal malfunction, such as a transmitter failure, which does not allow the entire frame to be transmitted normally. These errors are in the sum for the LLI errors.     

enc out = Encoding error outside of frames: The number of 8b/10b encoding errors that have occurred outside frames boundaries. This counter may become a nonzero value during link initialization but indicates a problem if it increments faster than the link-bit error rate allows (approximately once every 20 minutes for 1 Gb/s). This is usually caused by corrupted primitive sequences, that is: LIP f7,f7.     



NOTE: loss sig , loss sync and enc out errors are expected every time a user brings the port down and up by rebooting a host, power cycles a storage sub-system, disconnects/reconnects a cable or invoke the portDisable/portEnable command. Also important is the fact, that these errors are also increasing, while a 2GBit switch negotiates the connection speed to its connected device - keep this in mind. 

Cable/SFP Errors:
Statistically, enc out errors alone imply cable problems, the enc out and crc err in combination implies GBIC/SFP problems. These errors are in the sum for the LLI errors.   

disc c3 = Class 3 frames discarded: This affects the receiving link: The number of Class 3 frames discarded. Class 3 frames can be discarded due to timeouts or invalid or unreachable destinations. This counter increment during normal operation. It can also be used to show the effect of port congestion, means good frames from consecutive S-ID's and D-ID's not being directly routed port to port, but instead an exception frame is routed through the internal port (that normally should not happen with a port to port routing on the ASIC, but it does when the D-ID port suffers a buffer full condition and cannot accept any more frames). Also, if the destination is blocked due to high ISL workload (means that is: a long time with BB Credit Buffer = 0), that can cause buffer full conditions, therefore the S-ID port may (in extreme circumstances) meet a timeout condition and therefore the disc c3 counter will increase. These errors are in the sum for the LLI errors.    Some further information: A port can only receive one frame at a time (outside of xWDM connections it is not possible to shine 2 light pulses down an optical cable at the same time). Therefore if two light sources try to share a port they have to use an arbitration algorithm where one light source goes through and the second waits for it is turn. When the first source has completed, the second source is allowed to go. This means that the sources can only run at 50% utilization (or equal busy and ready times). If the source is capable of streaming data at the speed of the D-ID (which a lot of HBA's are these days) any attempt by another similarly fast HBA will result in a 50% performance decrease.     

link fail = Link failures (LF1 or LF2 states): The number of times the port achieved Link fail1 and/or Link fail 2 states.     

loss sync = Loss of synchronization: The number of times synchronization was lost. Note: "loss sig", "loss sync" and "enc out" errors are expected every time a user brings the port down and up (by rebooting a host, power cycles a storage sub-system, disconnects/reconnects a cable or invoke the portDisable/portEnable command (loss sig = Loss of signal: The number of times the signal was lost. When a loss-of-signal condition is recognized by an operational receiver, the Loss-Of-Synchronization state shall be entered (if the receiver is not presently in that state). The receiver shall remain in this state until one of the following conditions occur: The loss-of-signal condition is corrected and synchronization is regained - or - the receiver is reset. Note: "loss sig", "loss sync" and "enc out" errors are expected every time a user brings the port down and up (by rebooting a host, power cycles a storage sub-system, disconnects/reconnects a cable or invoke the portDisable/portEnable command     


frjt = Frames rejected with F_RJT: The number of Fabric Port Reject Frames. These indicate that the delivery of a frame is being denied. Some reasons for issuing an F_RJT include: Class not supported; invalid header field(s); and N-Port unavailable.     

fbsy = Frames busied with F_BSY: Fabric Port Busy Frame. This frame is issued by the Fabric to indicate that a particular cannot be delivered because the Fabric or the destination N-Port is busy.  

How to use DiskSpd to simulate Veeam Backup & Replication disk actions

This HOW-TO contains information on how to use Microsoft© DiskSpd to simulate Veeam Backup & Replication disk actions to measure disk pe...