In Solaris (and thus OmniOS) tape drives are mapped to /dev/rmt (raw media tape) using the following device naming scheme:

1

/dev/rmt/XAbn

• X is the drive number (0-n)
• A is the optional density (c for compressed, u for ultra)
• b for BSD compatible behaviour (needed for bacula)
• n is an optional no-rewind (n) [omit for rewind]

So, using compression and BSD compatible behaviour with no-rewind, the two LTO3 tape drives in my PowerVault ML6010 are at:

1
2

/dev/rmt/0cbn
/dev/rmt/1cbn

The autochanger is mapped to:

1

/dev/scsi/changer/cXX

Where cXX is the SCSI controller number.

Having installed OmniOS on my SuperMicro X9DR7-LN4F I configured a link aggregation to my Cisco SG300-28 switch, but found the network connection to be very erratic. It turns out that OmniOS by default uses a L4 LACP hash policy (piping by mac-address, IP-address and TCP/UDP port) whereas Cisco SG300 to my knowledge (i.e. the SG300 administration interface) only supports L3 LACP hash policy (mac-address, and IP-address). In other words, what traffic goes down what pipe was not in sync between OmniOS and the switch.

The fix is simple, specify the hash policy when creating the link aggregation (aggr0):

1

dladm create-aggr -P L3 -d igb0 -d igb1 -d igb2 -d igb3 aggr0

or update an existing link aggregation (aggr0) using:

1

dladm modify-aggr -P L3 aggr0

That stabilized network connections.

Back in September my Nexus 7 LTE (2013 model) tablet lost the ability to connect to cellular networks out of the blue while running Android 4.4.3. My network is 3 (in Denmark) and the SIM card works in an iPad. So this is specific for the Nexus 7 LTE. When I browse to: Settings->More...->Mobile Networks->Network Operators->Search Networks all I get is “Error while searching for networks”.

Selecting Choose automatically results in “Can’t connect to this network right now. Try again later.”

A lot of people have the same issues with lost cellular connectivity of Nexus 7 LTE tablets.

I have tried the following remedies (none of them worked):

• Factory reset
• Downgrade to Android 4.4.2 (KOT49H) using the official google factory image (razorg)
• Downgrade to Android 4.3 (JLS36C), using official image
• Re-install Android 4.4.3 (KTU84L) and perform official OTA update (via wifi) to Android 4.4.4
• Airplane mode enable/disable

The airplane switch is somewhat interesting. When airplane mode mode is off, the cellular status reads “No Service”, but when airplane mode is on it reads 3 (my network provider). So the Nexus 7 LTE can at least read my SIM card, how else would it know I am using 3?

According to this thread Google was aware of the issue well in advance of the release of Android 4.4.4 for the LTE model, but did not fix it. That is really lousy customer service by Google and Asus. According to Google tech (in the same thread), we are told to wait for Android L which might be released for the Nexus 7 (2013) model and might fix the issue.

I filed an RMA (return merchandise authorization) with Media Markt today and they will do a repair or replacement of my Nexus 7 LTE under warranty (less than a year old). Now that is good customer service.

One of the reasons I bought a SuperMicro X9DR7-LN4F for my All-in-One server was the ability to use a total of 18 drives with the on-board controllers:

• 8 disks on the LSI SAS2308 (SAS2)
• 6 drives on the Intel C602 (Port 0-5, two SATA3 and four SATA2)
• 4 drives on the SCU (SATA2).

Unfortunately this turned out not to work (running BIOS v3.0a from 10-Sep-2013, latest available at the time of writing). Thomas Krenn mentions issues with simultaneous use of the 4 SCU SATA2 ports and the SAS2308 controller. In my experience only the 2 SATA3 ports can be used when the SAS-2308 is operational rendering this this motherboard capable of supporting only 10 disks rather than 18. I would have liked to have that information before the purchase!

I ended up buying an LSI SAS 9201-16i HBA ahead of time.

I had six Samsung HD204UI drives from a previous NAS that I wanted to use in a zpool (two vdevs each consisting of a three-way mirror). The HD204UI drives are advanced format drives with 4k sectors, but they report a 512 byte sector size to the OS. This can be overcome in zfs by forcing 4k size in sd.conf and using ashift=12 when creating the zpool.

Before creating a zpool the drives must be prepared so that zfs and disk sectors are aligned. The following approach is gleaned from the illumos wiki entry on the subject by George Wilson.

To find the device names of all disks use the format command (use Ctrl-C to exit):

1
2
3
4
5
6
7
8
9

root@srv01:~# format
Searching for disks...done
...
AVAILABLE DISK SELECTIONS:
...
       2. c3t50024E900496C9E7d0 <ATA-SAMSUNG HD204UI-0001-1.82TB>
          /scsi_vhci/disk@g50024e900496c9e7
...
Specify disk (enter its number):

To use 4K sectors the partition table must be changed to a GUID partition table (GPT). Use the mklabel gpt command to change partition table (this will destroy all data on the disk):

1

parted /dev/rdsk/c3t50024E900496C9E7d0 mklabel gpt

To align sectors create a partition which starts at sector 256 (256 sectors of 512 bytes is 131072 bytes or 32 4K sectors, i.e. aligned). The size of the partition should be total number of disk sectors minus 16640 sectors (256 sectors for start + 16384 sectors for down-sizing to allow new disks of identical size to have slightly different geometry and still be used as replacement for the drive we are partitioning). 3907029168 sectors minus 16640 sectors equals 3907012528 sectors:

1

parted /dev/rdsk/c3t5000CCA23DC00778d0p0 uni s mkpart zfs solaris 256 3907012528

The disk is now ready to use in a zpool.