Intel SSD710 で Over-Provisioning 設定してみた

ちょうど180Gくらいの SSD を用立てたいと思っていたところ、この日、Intel SSD 710 の特価情報を目にして、一目散に秋葉原へ・・・。危うく売り切れのところ、なんと最後の１個をゲットできました。
手持ちの180GのSSD（Intel 520）と組み合わせてソフトウェアRAID（md or ZFS or Btrfs）で利用しようと考えたのですが、今回ゲットしたのは200Gなので、少々余ります。そこで思い出したのがオーバープロビジョニング。興味本位もあり、180GのSSDと同じサイズに揃えてみようと思いました。
おぼろげに、HPA（Host Protected Area）を設定すればいいはずだとは知ってましたが、根拠になる情報をネット検索してみたところ、Intel から次のドキュメントが公開されているのを見つけました。

Intel®: Solid-State Drives in Server Storage Applications White Paper February 2014

このPDFの「3.1 Adjusting User Capacity - Over-Provisioning」に記述があり、HPA を設定すれば良いという理解で合っているようです（注： HPA を設定しなくても、パーティションを切るときに、末尾領域を余らせるという方法でも良いようで、最もお手軽な、その手法が Intel のお勧めである と記述されています）。

てなわけで、CentOS 7 の hdparm コマンドで、次のような手順で HPA を設定しました。

[root@hoge ~]# cat /sys/block/sdb/device/model    ※まず、対象を間違えないように、確認。これ超重要です。
INTEL SSDSA2BZ20
[root@hoge ~]# hdparm -Np351651888 --yes-i-know-what-i-am-doing /dev/sdb

/dev/sdb:
 setting max visible sectors to 351651888 (permanent)
 max sectors   = 351651888/390721968, HPA is enabled
※このあと、いったんシャットダウン＆電源OFF して再起動する。

ここで、351651888 は、予め確認しておいた Intel SSD 520 180G の総セクタ数です。

次は、HPA 設定後の dmesg から抜粋です。どうやら、成功した様子が読み取れます。

[root@hoge ~]# dmesg | egrep "ata2|sdb"
[    1.384635] ata2: SATA max UDMA/133 abar m2048@0xf2427000 port 0xf2427180 irq 27
[    1.999869] ata2: SATA link up 3.0 Gbps (SStatus 123 SControl 300)
[    2.000849] ata2.00: ACPI cmd ef/02:00:00:00:00:a0 (SET FEATURES) succeeded
[    2.000856] ata2.00: ACPI cmd f5/00:00:00:00:00:a0 (SECURITY FREEZE LOCK) filtered out
[    2.001170] ata2.00: HPA detected: current 351651888, native 390721968
[    2.001181] ata2.00: ATA-8: INTEL SSDSA2BZ200G3, 6PB10362, max UDMA/133
[    2.001187] ata2.00: 351651888 sectors, multi 16: LBA48 NCQ (depth 31/32)
[    2.002169] ata2.00: ACPI cmd ef/02:00:00:00:00:a0 (SET FEATURES) succeeded
[    2.002177] ata2.00: ACPI cmd f5/00:00:00:00:00:a0 (SECURITY FREEZE LOCK) filtered out
[    2.002510] ata2.00: configured for UDMA/133
[    2.662193] ata2.00: Enabling discard_zeroes_data
[    2.662205] sd 1:0:0:0: [sdb] 351651888 512-byte logical blocks: (180 GB/167 GiB)
[    2.662419] sd 1:0:0:0: [sdb] Write Protect is off
[    2.662423] sd 1:0:0:0: [sdb] Mode Sense: 00 3a 00 00
[    2.662446] sd 1:0:0:0: [sdb] Write cache: enabled, read cache: enabled, doesn't support DPO or FUA
[    2.662556] ata2.00: Enabling discard_zeroes_data
[    2.663234]  sdb: unknown partition table
[    2.663378] ata2.00: Enabling discard_zeroes_data
[    2.663486] sd 1:0:0:0: [sdb] Attached SCSI disk

TSC を読み出すことができるコマンド

今さら、古い話題ですが、Xeon E5 で reboot 時に TSC (Time Stamp Counter) がリセットされない（ゼロに初期化されない）という動作が影響して発生する 新208.5日問題 というのがあります。キーワード「208.5日問題」で検索すると、いろいろ情報が出てくるので、問題の詳細はそちらを参照。
TSC の値を読み出すには RDTSC 命令を使えばよいので、Ｃ言語でインラインアセンブラを使って、少々記述すれば出来そうですが、既成のコマンドがありますので、備忘録として書いておきます。

[root@hoge ~]# date
2015年 11月  7日 土曜日 16:19:50 JST
[root@hoge ~]# uptime
 16:19:53 up  6:52,  3 users,  load average: 0.06, 0.10, 0.13
[root@hoge ~]# lsmsr -r TSC
TSC = 0x00003836cd3926f0

このマシン（ThinkPad W520）の CPU は、Core i7 ですが、reboot するとリセットされる様子が読み取れます。

[root@hoge ~]# date
2015年 11月  7日 土曜日 16:22:18 JST
[root@hoge ~]# uptime
 16:22:20 up 1 min,  3 users,  load average: 0.12, 0.07, 0.03
[root@hoge ~]# lsmsr -r TSC
TSC = 0x0000003e244cb997    ※もしリセットされないなら、reboot 前より大きな値が見えるはず

このコマンドは、x86info というパッケージに収録されています。

[root@hoge ~]# which lsmsr
/usr/sbin/lsmsr
[root@hoge ~]# rpm -qf /usr/sbin/lsmsr
x86info-1.30-6.el7.x86_64

実際に Xeon E5 のマシンで、実験してみたいところですが、もちろん手元にはありませんので、以上です。

2018-04-20追記
すっかり忘れてましたが、最近 ThinkPad 25 (Core i7 7500U) を使っており、このマシンの場合はどうかなとやってみましたが、リセットされる動きでした。つまらんですが。

[root@hoge ~]# cat TSC-2018-04-20-0523 ※リブートする前に保存しておいた値
TSC = 0x000031fdec83f39e
[root@hoge ~]# date
2018年  4月 20日 金曜日 05:29:00 JST
[root@hoge ~]# lsmsr -r TSC
TSC = 0x000000d8b709a561
[root@hoge ~]# grep i7 /proc/cpuinfo 
model name : Intel(R) Core(TM) i7-7500U CPU @ 2.70GHz
...

実際にリセットされないマシンを見てみたいものですが。。。
なお、lsmsr 以外に turbostat でも TSC を出せるようです。

[root@hoge ~]# date
2018年  4月 20日 金曜日 05:37:48 JST
[root@hoge ~]# turbostat --Dump | grep TSC
TSC: 0000023D87874404
TSC: 0000023D87881627
TSC: 0000023D878A4FB2
TSC: 0000023D878AF768  ※4つの論理CPU分出力されてます。当然ですが、読み出しタイミングがちょっとずつ後ろになってます。

中古 HDD の初期確認、２個目（2015年10月）

中古 HDD の初期確認。前回に続き、某ショップより２個目を入手しましたので、今回も備忘録です。

今回入手した中古 HDD は、１個目と同じく Seagate Barracuda ES.2 1TB です。S.M.A.R.T. でエラーがある状態とのことで、１個目よりも千円ほど安い値段でした。１個目は、入手直後こそエラーがない状態でしたが、使い始めた途端にエラーが多発し、不良セクタ処置後は３ヵ月ほど安定して利用できています。その経験値から、最初からエラー（不良セクタ）があるとしても、同じように処置すれば、そこそこ使えるのでは？という判断のもと、安さ優先で調達しました。

そんな訳で、一種の賭けでしたが、認識はされました（さすがに認識もされない個体は売ってないですかね）ので、最初に S.M.A.R.T. 確認です。

[root@hoge ~]# smartctl -A /dev/sdf
smartctl 6.2 2013-07-26 r3841 [x86_64-linux-3.10.0-229.14.1.el7.x86_64] (local build)
Copyright (C) 2002-13, Bruce Allen, Christian Franke, www.smartmontools.org

=== START OF READ SMART DATA SECTION ===
SMART Attributes Data Structure revision number: 10
Vendor Specific SMART Attributes with Thresholds:
ID# ATTRIBUTE_NAME          FLAG     VALUE WORST THRESH TYPE      UPDATED  WHEN_FAILED RAW_VALUE
  1 Raw_Read_Error_Rate     0x000f   065   039   044    Pre-fail  Always   In_the_past 3585868
  3 Spin_Up_Time            0x0003   099   099   000    Pre-fail  Always       -       0
  4 Start_Stop_Count        0x0032   100   100   020    Old_age   Always       -       35
  5 Reallocated_Sector_Ct   0x0033   082   082   036    Pre-fail  Always       -       379
  7 Seek_Error_Rate         0x000f   070   057   030    Pre-fail  Always       -       434963003265
  9 Power_On_Hours          0x0032   070   070   000    Old_age   Always       -       26851
 10 Spin_Retry_Count        0x0013   100   100   097    Pre-fail  Always       -       0
 12 Power_Cycle_Count       0x0032   100   037   020    Old_age   Always       -       35
184 End-to-End_Error        0x0032   100   100   099    Old_age   Always       -       0
187 Reported_Uncorrect      0x0032   001   001   000    Old_age   Always       -       574
188 Command_Timeout         0x0032   100   099   000    Old_age   Always       -       8590065669
189 High_Fly_Writes         0x003a   100   100   000    Old_age   Always       -       0
190 Airflow_Temperature_Cel 0x0022   074   054   045    Old_age   Always       -       26 (Min/Max 26/26)
194 Temperature_Celsius     0x0022   026   046   000    Old_age   Always       -       26 (0 15 0 0 0)
195 Hardware_ECC_Recovered  0x001a   024   024   000    Old_age   Always       -       3585868
197 Current_Pending_Sector  0x0012   100   100   000    Old_age   Always       -       0
198 Offline_Uncorrectable   0x0010   100   100   000    Old_age   Offline      -       0
199 UDMA_CRC_Error_Count    0x003e   200   200   000    Old_age   Always       -       0

某ショップの説明通り、そこそこのキズモノのようですが、１個目と見比べると 188 Command_Timeout が多発しているのが特に気になります。
運用時間（9 Power_On_Hours）は、

[root@hoge ~]# echo "26851 / 24 / 365" | bc -l
3.06518264840182648401

ほぼ３年です。

次は hdparm -i の出力です。

[root@hoge ~]# hdparm -i /dev/sdf

/dev/sdf:

 Model=ST31000340NS, FwRev=FSC9, SerialNo=9xxxxxx6
 Config={ HardSect NotMFM HdSw>15uSec Fixed DTR>10Mbs RotSpdTol>.5% }
 RawCHS=16383/16/63, TrkSize=0, SectSize=0, ECCbytes=4
 BuffType=unknown, BuffSize=unknown, MaxMultSect=16, MultSect=off
 CurCHS=16383/16/63, CurSects=16514064, LBA=yes, LBAsects=1953525168
 IORDY=on/off, tPIO={min:120,w/IORDY:120}, tDMA={min:120,rec:120}
 PIO modes:  pio0 pio1 pio2 pio3 pio4 
 DMA modes:  mdma0 mdma1 mdma2 
 UDMA modes: udma0 udma1 udma2 udma3 udma4 udma5 *udma6 
 AdvancedPM=no WriteCache=enabled
 Drive conforms to: unknown:  ATA/ATAPI-4,5,6,7

 * signifies the current active mode

１個目は、Write cache が disabled でしたが、２個目は、特に操作しなくても WriteCache=enabled でした。
それと、ファームウェアのバージョンが異りました。１個目は NA02 ですが、こちらは FSC9 。

次は、smartctl -a の出力です。

[root@hoge ~]# smartctl -a /dev/sdf
smartctl 6.2 2013-07-26 r3841 [x86_64-linux-3.10.0-229.14.1.el7.x86_64] (local build)
Copyright (C) 2002-13, Bruce Allen, Christian Franke, www.smartmontools.org

=== START OF INFORMATION SECTION ===
Model Family:     Seagate Barracuda ES.2
Device Model:     ST31000340NS
Serial Number:    9xxxxxx6
LU WWN Device Id: 5 000c50 0yyyyyyy5
Firmware Version: FSC9
User Capacity:    1,000,204,886,016 bytes [1.00 TB]
Sector Size:      512 bytes logical/physical
Rotation Rate:    7200 rpm
Device is:        In smartctl database [for details use: -P show]
ATA Version is:   ATA8-ACS T13/1699-D revision 4
SATA Version is:  SATA 2.6, 3.0 Gb/s
Local Time is:    Fri Oct  9 12:47:55 2015 JST

==> WARNING: There are known problems with these drives,
see the following Seagate web pages:
http://knowledge.seagate.com/articles/en_US/FAQ/207931en
http://knowledge.seagate.com/articles/en_US/FAQ/207963en

SMART support is: Available - device has SMART capability.
SMART support is: Enabled

=== START OF READ SMART DATA SECTION ===
SMART overall-health self-assessment test result: PASSED
See vendor-specific Attribute list for marginal Attributes.

General SMART Values:
Offline data collection status:  (0x82) Offline data collection activity
     was completed without error.
     Auto Offline Data Collection: Enabled.
Self-test execution status:      (   0) The previous self-test routine completed
     without error or no self-test has ever 
     been run.
Total time to complete Offline 
data collection:   (  642) seconds.
Offline data collection
capabilities:     (0x7b) SMART execute Offline immediate.
     Auto Offline data collection on/off support.
     Suspend Offline collection upon new
     command.
     Offline surface scan supported.
     Self-test supported.
     Conveyance Self-test supported.
     Selective Self-test supported.
SMART capabilities:            (0x0003) Saves SMART data before entering
     power-saving mode.
     Supports SMART auto save timer.
Error logging capability:        (0x01) Error logging supported.
     General Purpose Logging supported.
Short self-test routine 
recommended polling time:   (   1) minutes.
Extended self-test routine
recommended polling time:   ( 225) minutes.
Conveyance self-test routine
recommended polling time:   (   2) minutes.
SCT capabilities:         (0x103d) SCT Status supported.
     SCT Error Recovery Control supported.
     SCT Feature Control supported.
     SCT Data Table supported.

SMART Attributes Data Structure revision number: 10
Vendor Specific SMART Attributes with Thresholds:
ID# ATTRIBUTE_NAME          FLAG     VALUE WORST THRESH TYPE      UPDATED  WHEN_FAILED RAW_VALUE
  1 Raw_Read_Error_Rate     0x000f   065   039   044    Pre-fail  Always   In_the_past 3585868
  3 Spin_Up_Time            0x0003   099   099   000    Pre-fail  Always       -       0
  4 Start_Stop_Count        0x0032   100   100   020    Old_age   Always       -       35
  5 Reallocated_Sector_Ct   0x0033   082   082   036    Pre-fail  Always       -       379
  7 Seek_Error_Rate         0x000f   070   057   030    Pre-fail  Always       -       434963004045
  9 Power_On_Hours          0x0032   070   070   000    Old_age   Always       -       26852
 10 Spin_Retry_Count        0x0013   100   100   097    Pre-fail  Always       -       0
 12 Power_Cycle_Count       0x0032   100   037   020    Old_age   Always       -       35
184 End-to-End_Error        0x0032   100   100   099    Old_age   Always       -       0
187 Reported_Uncorrect      0x0032   001   001   000    Old_age   Always       -       574
188 Command_Timeout         0x0032   100   099   000    Old_age   Always       -       8590065669
189 High_Fly_Writes         0x003a   100   100   000    Old_age   Always       -       0
190 Airflow_Temperature_Cel 0x0022   068   054   045    Old_age   Always       -       32 (Min/Max 26/32)
194 Temperature_Celsius     0x0022   032   046   000    Old_age   Always       -       32 (0 15 0 0 0)
195 Hardware_ECC_Recovered  0x001a   024   024   000    Old_age   Always       -       3585868
197 Current_Pending_Sector  0x0012   100   100   000    Old_age   Always       -       0
198 Offline_Uncorrectable   0x0010   100   100   000    Old_age   Offline      -       0
199 UDMA_CRC_Error_Count    0x003e   200   200   000    Old_age   Always       -       0

SMART Error Log Version: 1
ATA Error Count: 15 (device log contains only the most recent five errors)
 CR = Command Register [HEX]
 FR = Features Register [HEX]
 SC = Sector Count Register [HEX]
 SN = Sector Number Register [HEX]
 CL = Cylinder Low Register [HEX]
 CH = Cylinder High Register [HEX]
 DH = Device/Head Register [HEX]
 DC = Device Command Register [HEX]
 ER = Error register [HEX]
 ST = Status register [HEX]
Powered_Up_Time is measured from power on, and printed as
DDd+hh:mm:SS.sss where DD=days, hh=hours, mm=minutes,
SS=sec, and sss=millisec. It "wraps" after 49.710 days.

Error 15 occurred at disk power-on lifetime: 26830 hours (1117 days + 22 hours)
  When the command that caused the error occurred, the device was active or idle.

  After command completion occurred, registers were:
  ER ST SC SN CL CH DH
  -- -- -- -- -- -- --
  40 51 00 0b 8d 78 00  Error: UNC at LBA = 0x00788d0b = 7900427

  Commands leading to the command that caused the error were:
  CR FR SC SN CL CH DH DC   Powered_Up_Time  Command/Feature_Name
  -- -- -- -- -- -- -- --  ----------------  --------------------
  42 00 01 0b 8d 78 e0 00      00:08:23.338  READ VERIFY SECTOR(S) EXT
  25 00 01 00 00 00 e0 00      00:08:23.338  READ DMA EXT
  42 00 02 0d 8d 78 e0 00      00:08:23.241  READ VERIFY SECTOR(S) EXT
  42 00 02 0b 8d 78 e0 00      00:08:20.264  READ VERIFY SECTOR(S) EXT
  25 00 01 00 00 00 e0 00      00:08:20.192  READ DMA EXT

Error 14 occurred at disk power-on lifetime: 26830 hours (1117 days + 22 hours)
  When the command that caused the error occurred, the device was active or idle.

  After command completion occurred, registers were:
  ER ST SC SN CL CH DH
  -- -- -- -- -- -- --
  40 51 00 0b 8d 78 00  Error: UNC at LBA = 0x00788d0b = 7900427

  Commands leading to the command that caused the error were:
  CR FR SC SN CL CH DH DC   Powered_Up_Time  Command/Feature_Name
  -- -- -- -- -- -- -- --  ----------------  --------------------
  42 00 02 0b 8d 78 e0 00      00:08:20.264  READ VERIFY SECTOR(S) EXT
  25 00 01 00 00 00 e0 00      00:08:20.192  READ DMA EXT
  42 00 04 0b 8d 78 e0 00      00:08:17.248  READ VERIFY SECTOR(S) EXT
  25 00 01 00 00 00 e0 00      00:08:17.192  READ DMA EXT
  42 00 04 07 8d 78 e0 00      00:08:17.102  READ VERIFY SECTOR(S) EXT

Error 13 occurred at disk power-on lifetime: 26830 hours (1117 days + 22 hours)
  When the command that caused the error occurred, the device was active or idle.

  After command completion occurred, registers were:
  ER ST SC SN CL CH DH
  -- -- -- -- -- -- --
  40 51 00 0b 8d 78 00  Error: UNC at LBA = 0x00788d0b = 7900427

  Commands leading to the command that caused the error were:
  CR FR SC SN CL CH DH DC   Powered_Up_Time  Command/Feature_Name
  -- -- -- -- -- -- -- --  ----------------  --------------------
  42 00 04 0b 8d 78 e0 00      00:08:17.248  READ VERIFY SECTOR(S) EXT
  25 00 01 00 00 00 e0 00      00:08:17.192  READ DMA EXT
  42 00 04 07 8d 78 e0 00      00:08:17.102  READ VERIFY SECTOR(S) EXT
  42 00 08 07 8d 78 e0 00      00:08:14.161  READ VERIFY SECTOR(S) EXT
  42 00 08 ff 8c 78 e0 00      00:08:14.102  READ VERIFY SECTOR(S) EXT

Error 12 occurred at disk power-on lifetime: 26830 hours (1117 days + 22 hours)
  When the command that caused the error occurred, the device was active or idle.

  After command completion occurred, registers were:
  ER ST SC SN CL CH DH
  -- -- -- -- -- -- --
  40 51 00 0b 8d 78 00  Error: UNC at LBA = 0x00788d0b = 7900427

  Commands leading to the command that caused the error were:
  CR FR SC SN CL CH DH DC   Powered_Up_Time  Command/Feature_Name
  -- -- -- -- -- -- -- --  ----------------  --------------------
  42 00 08 07 8d 78 e0 00      00:08:14.161  READ VERIFY SECTOR(S) EXT
  42 00 08 ff 8c 78 e0 00      00:08:14.102  READ VERIFY SECTOR(S) EXT
  25 00 01 00 00 00 e0 00      00:08:14.102  READ DMA EXT
  42 00 10 0f 8d 78 e0 00      00:08:14.020  READ VERIFY SECTOR(S) EXT
  42 00 10 ff 8c 78 e0 00      00:08:11.071  READ VERIFY SECTOR(S) EXT

Error 11 occurred at disk power-on lifetime: 26830 hours (1117 days + 22 hours)
  When the command that caused the error occurred, the device was active or idle.

  After command completion occurred, registers were:
  ER ST SC SN CL CH DH
  -- -- -- -- -- -- --
  40 51 00 0b 8d 78 00  Error: UNC at LBA = 0x00788d0b = 7900427

  Commands leading to the command that caused the error were:
  CR FR SC SN CL CH DH DC   Powered_Up_Time  Command/Feature_Name
  -- -- -- -- -- -- -- --  ----------------  --------------------
  42 00 10 ff 8c 78 e0 00      00:08:11.071  READ VERIFY SECTOR(S) EXT
  25 00 01 00 00 00 e0 00      00:08:11.070  READ DMA EXT
  42 00 20 1f 8d 78 e0 00      00:08:10.985  READ VERIFY SECTOR(S) EXT
  25 00 01 00 00 00 e0 00      00:08:10.947  READ DMA EXT
  42 00 20 ff 8c 78 e0 00      00:08:07.923  READ VERIFY SECTOR(S) EXT

SMART Self-test log structure revision number 1
No self-tests have been logged.  [To run self-tests, use: smartctl -t]


SMART Selective self-test log data structure revision number 1
 SPAN  MIN_LBA  MAX_LBA  CURRENT_TEST_STATUS
    1        0        0  Not_testing
    2        0        0  Not_testing
    3        0        0  Not_testing
    4        0        0  Not_testing
    5        0        0  Not_testing
Selective self-test flags (0x0):
  After scanning selected spans, do NOT read-scan remainder of disk.
If Selective self-test is pending on power-up, resume after 0 minute delay.

いくつかのエラーログも出ていました。

次は、hdparm -I の出力です。

[root@hoge ~]# hdparm -I /dev/sdf

/dev/sdf:

ATA device, with non-removable media
 Model Number:       ST31000340NS                            
 Serial Number:      9xxxxxx6
 Firmware Revision:  FSC9    
 Transport:          Serial
Standards:
 Used: unknown (minor revision code 0x0029) 
 Supported: 8 7 6 5 
 Likely used: 8
Configuration:
 Logical  max current
 cylinders 16383 16383
 heads  16 16
 sectors/track 63 63
 --
 CHS current addressable sectors:   16514064
 LBA    user addressable sectors:  268435455
 LBA48  user addressable sectors: 1953525168
 Logical/Physical Sector size:           512 bytes
 device size with M = 1024*1024:      953869 MBytes
 device size with M = 1000*1000:     1000204 MBytes (1000 GB)
 cache/buffer size  = unknown
 Nominal Media Rotation Rate: 7200
Capabilities:
 LBA, IORDY(can be disabled)
 Queue depth: 32
 Standby timer values: spec'd by Standard, no device specific minimum
 R/W multiple sector transfer: Max = 16 Current = ?
 Recommended acoustic management value: 128, current value: 0
 DMA: mdma0 mdma1 mdma2 udma0 udma1 udma2 udma3 udma4 udma5 *udma6 
      Cycle time: min=120ns recommended=120ns
 PIO: pio0 pio1 pio2 pio3 pio4 
      Cycle time: no flow control=120ns  IORDY flow control=120ns
Commands/features:
 Enabled Supported:
    * SMART feature set
      Security Mode feature set
    * Power Management feature set
    * Write cache
    * Look-ahead
    * Host Protected Area feature set
    * WRITE_BUFFER command
    * READ_BUFFER command
    * DOWNLOAD_MICROCODE
      SET_MAX security extension
    * 48-bit Address feature set
    * Device Configuration Overlay feature set
    * Mandatory FLUSH_CACHE
    * FLUSH_CACHE_EXT
    * SMART error logging
    * SMART self-test
    * General Purpose Logging feature set
    * 64-bit World wide name
    * Write-Read-Verify feature set
    * WRITE_UNCORRECTABLE_EXT command
    * {READ,WRITE}_DMA_EXT_GPL commands
    * Segmented DOWNLOAD_MICROCODE
    * Gen1 signaling speed (1.5Gb/s)
    * Gen2 signaling speed (3.0Gb/s)
    * Native Command Queueing (NCQ)
    * Phy event counters
    * Software settings preservation
    * SMART Command Transport (SCT) feature set
    * SCT Write Same (AC2)
    * SCT Error Recovery Control (AC3)
    * SCT Features Control (AC4)
    * SCT Data Tables (AC5)
      unknown 206[12] (vendor specific)
Security: 
 Master password revision code = 65534
  supported
 not enabled
 not locked
 not frozen
 not expired: security count
  supported: enhanced erase
 192min for SECURITY ERASE UNIT. 192min for ENHANCED SECURITY ERASE UNIT. 
Logical Unit WWN Device Identifier: 5000c50015b19765
 NAA  : 5
 IEEE OUI : 000c50
 Unique ID : 0yyyyyyy5
Checksum: correct

今回も ZFS で冗長化（４台でRAIDZ）して使うので、全セクタ検査などせずに、そのまま投入です。ただ今、書き込みテスト中。

2015-10-13追記
ZFS プールの 70% 程度までテストデータを書き込み、そのあと、scrub を行いましたが、一切エラーは出ませんでした。S.M.A.R.T. カウンタも特段の変化はありませんでした。もし、このまま２年くらい使えたなら、お買い得だったと振り返ることができそうに思います。

2017-04-21追記
2017-04-11 に、見事に壊れました。擦れてような異音がして、冷却ファンのどれかが壊れかかっているのかと、耳を近づけてもどこから音がしているか、なかなかわからないもんですね。zpool status をみて、この HDD が壊れたことがわかりました。いわゆるヘッドクラッシュなのか？もの凄い音でした。
週に１回、smartctl の出力を採取していましたので、壊れるまえに最後に採取されたデータ (2017-04-05のもの) を、参考に貼り付けておきます。

SMART Attributes Data Structure revision number: 10
Vendor Specific SMART Attributes with Thresholds:
ID# ATTRIBUTE_NAME          FLAG     VALUE WORST THRESH TYPE      UPDATED  WHEN_FAILED RAW_VALUE
  1 Raw_Read_Error_Rate     0x000f   070   039   044    Pre-fail  Always   In_the_past 12104840
  3 Spin_Up_Time            0x0003   099   099   000    Pre-fail  Always       -       0
  4 Start_Stop_Count        0x0032   100   100   020    Old_age   Always       -       83
  5 Reallocated_Sector_Ct   0x0033   082   082   036    Pre-fail  Always       -       389
  7 Seek_Error_Rate         0x000f   070   057   030    Pre-fail  Always       -       435030066631
  9 Power_On_Hours          0x0032   055   055   000    Old_age   Always       -       39600
 10 Spin_Retry_Count        0x0013   100   100   097    Pre-fail  Always       -       0
 12 Power_Cycle_Count       0x0032   100   037   020    Old_age   Always       -       83
184 End-to-End_Error        0x0032   100   100   099    Old_age   Always       -       0
187 Reported_Uncorrect      0x0032   001   001   000    Old_age   Always       -       574
188 Command_Timeout         0x0032   100   099   000    Old_age   Always       -       8590065669
189 High_Fly_Writes         0x003a   100   100   000    Old_age   Always       -       0
190 Airflow_Temperature_Cel 0x0022   066   054   045    Old_age   Always       -       34 (Min/Max 32/43)
194 Temperature_Celsius     0x0022   034   046   000    Old_age   Always       -       34 (0 15 0 0 0)
195 Hardware_ECC_Recovered  0x001a   034   024   000    Old_age   Always       -       12104840
197 Current_Pending_Sector  0x0012   100   100   000    Old_age   Always       -       0
198 Offline_Uncorrectable   0x0010   100   100   000    Old_age   Offline      -       0
199 UDMA_CRC_Error_Count    0x003e   200   200   000    Old_age   Always       -       0

さて、交換ですが・・・、またも同じ型番の中古 HDD を注文しました。某ショップで★５つでしたが、さてどんなもんでしょうね。

CentOS7 の GNOME デスクトップの自動マウントを無効化する

USBディスク等を接続したり、DVDドライブにメディアを挿入すると、自動でマウントしてくれるのですが、これがかなり余計なお世話に感じます。
特に、細かくパーティションを分割していたりすると、各パーティションを全部マウントしてくれちゃいます。コマンドラインでの操作が中心なので、これは、まったく余計に感じる。

そこで、この内容なら先人の方がおられるだろうと、ネット検索してみると、やっぱり先人の方がおられました。というわけで、感謝しつつ、写経までです。CentOS 7 でも同じ（先人さんは Ubuntu）でした。

[root@hoge ~]# gsettings get org.gnome.desktop.media-handling automount
true
[root@hoge ~]# gsettings set org.gnome.desktop.media-handling automount false
[root@hoge ~]# gsettings get org.gnome.desktop.media-handling automount
false

これで自動マウントされなくなりました。あーよかった。煩わしさ（いままでは、余計なマウントを手動でumountしてました・・・）が減りました。

2015-10-08追記
CentOS 6 も同様だろうと思っていましたが、gsettings というコマンドは存在せず、別コマンドを使う必要がありました。これも、写経です。

[root@hoge ~]# gconftool-2 --get /apps/nautilus/preferences/media_automount
true
[root@hoge ~]# gconftool-2 --type bool --set /apps/nautilus/preferences/media_automount false
[root@hoge ~]# gconftool-2 --get /apps/nautilus/preferences/media_automount
false

こちらを参照しました。感謝。
マルチブートで CentOS 6 も使えるようにしているものの、最近は、ほとんど CentOS 7 を使ってます。過去の経験上、サーバとして使い始めるなら、7.2 からかなと思うのですが、デスクトップは CentOS 7 のほうが使い易く感じます（慣れてしまっただけかもわかりませんが）。

2015-11-28追記
書くまでもないと思いますが、RHEL7/RHEL6 も同様ですよ～。もちろんです。

2018-04-06追記
ひさびさに Fedora を使ってます。また微妙に違うものに変わってるかも？勘弁して欲しいが、、、と思ったのですが、gsettings はまだ使えました。今現在、Fedora 27 です。

2019-09-28追記
CentOS8/RHEL8 は、CentOS7 と同様でした。

2019-12-26追記
自動マウントを司っているのは udisks2 なので、これを止めてしまう方法もあるようです。
https://azaharblanca.blogspot.com/2019/01/
なるほどです。fedora29 で検証してみました。

[root@hoge ~]# uname -a
Linux hoge 5.3.11-100.fc29.x86_64 #1 SMP Tue Nov 12 20:41:25 UTC 2019 x86_64 x86_64 x86_64 GNU/Linux
[root@hoge ~]# gsettings get org.gnome.desktop.media-handling automount
true
[root@hoge ~]# systemctl disable udisks2.service 
[root@hoge ~]# systemctl mask    udisks2.service 
[root@hoge ~]# systemctl is-enabled udisks2.service 
masked
※このあとリブートして USB-HDD をホットプラグしてみましたが、確かに自動マウントされなくなりました

注意点としては、リブート（または一旦ログアウト）しないと、施した設定が有効になりませんでした。

■関連情報
CentOS7 の GNOME デスクトップで Ctrl+Alt+Delete を無効化する

eggcups の暴走

マルチブートの CentOS 5 を、久しぶりに起動し、アップデート（yum update）してから作業（ZFS 0.6.5 がリリースされたので UEKr2 で動くか調査）していたら、何やら ThinkPad の冷却ファンが高回転に・・・
アップデート後だし prelink でも動いているのか？と思って、top を見てみると、見たことのないプロセス eggcups --sm-client-id default4 が１コア食いつぶしていました。調べてみるとプリンター関係のようで、プリンターには用が無いので、削除しました。備忘録まで。

[root@hoge ~]# which eggcups
/usr/bin/eggcups
[root@hoge ~]# rpm -qf /usr/bin/eggcups
desktop-printing-0.19-20.2.el5
[root@hoge ~]# yum remove desktop-printing
Loaded plugins: fastestmirror, security
Setting up Remove Process
Resolving Dependencies
--> Running transaction check
---> Package desktop-printing.x86_64 0:0.19-20.2.el5 set to be erased
--> Finished Dependency Resolution

Dependencies Resolved

================================================================================
 Package                Arch         Version              Repository       Size
================================================================================
Removing:
 desktop-printing       x86_64       0.19-20.2.el5        installed       271 k

Transaction Summary
================================================================================
Remove        1 Package(s)
Reinstall     0 Package(s)
Downgrade     0 Package(s)

Is this ok [y/N]: y
Downloading Packages:
Running rpm_check_debug
Running Transaction Test
Finished Transaction Test
Transaction Test Succeeded
Running Transaction
  Erasing        : desktop-printing                                         1/1 

Removed:
  desktop-printing.x86_64 0:0.19-20.2.el5                                       

Complete!

ThinkPad W520 で SSD ２台で IRST（インテルラピッドストレージテクノロジー）RAID1

ThinkPad W520 の IRST にて、RAID1 構成を組みました。

ぴったり１年前に書いたのですが、IRST の RAID ボリュームは、CentOS からは md RAID に見えます。

[root@hoge ~]# uname -a
Linux hoge 3.10.0-229.7.2.el7.x86_64 #1 SMP Tue Jun 23 22:06:11 UTC 2015 x86_64 x86_64 x86_64 GNU/Linux
[root@hoge ~]# cat /proc/cmdline 
BOOT_IMAGE=/boot/vmlinuz-3.10.0-229.7.2.el7.x86_64 root=UUID=75c154b8-fc8c-49b1-8f83-4b34792f17f8 ro elevator=deadline vconsole.keymap=jp106 crashkernel=auto vconsole.font=latarcyrheb-sun16 rhgb quiet net.ifnames=0 biosdevname=1 rd.auto LANG=ja_JP.UTF-8
[root@hoge ~]# mdadm --detail-platform
       Platform : Intel(R) Matrix Storage Manager
        Version : 10.1.0.1008
    RAID Levels : raid0 raid1 raid10 raid5
    Chunk Sizes : 4k 8k 16k 32k 64k 128k
    2TB volumes : supported
      2TB disks : not supported
      Max Disks : 7
    Max Volumes : 2 per array, 4 per controller
 I/O Controller : /sys/devices/pci0000:00/0000:00:1f.2 (SATA)
[root@hoge ~]# cat /proc/mdstat 
Personalities : [raid1] 
md126 : active raid1 sda[1] sdb[0]
      234428416 blocks super external:/md127/0 [2/2] [UU]
      
md127 : inactive sdb[1](S) sda[0](S)
      5032 blocks super external:imsm
       
unused devices: 
[root@hoge ~]# mdadm -D /dev/md126
/dev/md126:
      Container : /dev/md/imsm0, member 0
     Raid Level : raid1
     Array Size : 234428416 (223.57 GiB 240.05 GB)
  Used Dev Size : 234428548 (223.57 GiB 240.05 GB)
   Raid Devices : 2
  Total Devices : 2

          State : active 
 Active Devices : 2
Working Devices : 2
 Failed Devices : 0
  Spare Devices : 0


           UUID : 6e7baff8:151abd71:f81f8d33:ff110ddb
    Number   Major   Minor   RaidDevice State
       1       8        0        0      active sync   /dev/sda
       0       8       16        1      active sync   /dev/sdb
[root@hoge ~]# mdadm -D /dev/md127
/dev/md127:
        Version : imsm
     Raid Level : container
  Total Devices : 2

Working Devices : 2


           UUID : d20e7f17:aa8e195e:97bd9260:f822e1bb
  Member Arrays : /dev/md/Volume0

    Number   Major   Minor   RaidDevice

       0       8        0        -        /dev/sda
       1       8       16        -        /dev/sdb
[root@hoge ~]# df
ファイルシス   1K-ブロック    使用   使用可 使用% マウント位置
/dev/md126p6      20480000 6733536 12328768   36% /    ※デバイス名には注意必要です
devtmpfs           8101144       0  8101144    0% /dev
tmpfs              8110564      84  8110480    1% /dev/shm
tmpfs              8110564    9280  8101284    1% /run
tmpfs              8110564       0  8110564    0% /sys/fs/cgroup
tankK             70524288     128 70524160    1% /tankK
tankK/spool       71024896  500736 70524160    1% /tankK/spool

「Intel® Rapid Storage Technology enterprise (Intel® RSTe) for Linux OS Document Number: 327602-001US Software User’s Manual」という資料に、IRST における mdadm 操作方法が一通り解説されています。

これが出来なきゃ躊躇するところですが、Windows 7 と CentOS のマルチブートも問題ありません。MBM も使えてます。

Windows 7 上のユーティリティ（バージョンは 2014/11/06 13.6.0.1002）からは、次のように見えます。

ここで、ThinkPad の利点（バッテリ搭載している）を生かして、キャッシュモードをライトバックに設定しました！ (^0^)g

CrystalDiskMark の値は次の通りです。

RAID1 としては抜群の値です。ハードウェア RAID1 の場合、たいてい NCQ が有効にならないのですが、IRST はソフトウェア RAID（Fake RAID）であり、個々のドライブは NCQ 有効なので、ランダムアクセスの性能が落ちません。それから、OS からは各ドライブが直に見えるので S.M.A.R.T. の確認が簡単に出来るのも、ソフトウェア RAID の利点かと思います。Linux なら smartctl で、Windows なら CrystalDiskInfo が使えます。対して、ハードウェア RAID の場合は、RAID ベンダ提供のユーティリティでないと参照できません。ユーティリティが S.M.A.R.T. 取得に対応してない場合もあります。
それにしても、もしも RAID0 にしたら、1000M オーバーもいけそうな感じですね。。。

なお、SSD は SanDisk Extreme PRO 240G x２台を使用しています。この SSD は、充分に速いのに加えて、温度があまり上がらない（今みたら 1st が 38℃、2nd が 34℃）のが魅力かなと思います。現在、カカクコムにて満足度ランキング１位だったりもします。眉唾（話し半分）ととらえるべきと思いますが、それでも自分の使ってる SSD が１位なのは気分よいものですね。
個人的には、性能なら Crucial MX200 のほうが上かと思います（別のマシンで使ってるもので）。しかし、MX200 の順位は１０位なようです。

最後に、ThinkPad W520 であっても IRST オプション ROM を搭載しているのは、一部の型番だけなので、もしもこのブログを読んで中古購入する場合は、くれぐれもご注意ください。

2015-09-12追記
この手の RAID システムで気になるのが、コントローラ（この場合は ThinkPad の MB）が壊れたら、データを救済できないのではないか？ということだと思います。が、試したところ、この形態の場合、他のマシンにドライブを接続すれば、IRST オプション ROM が搭載されていなくても、CentOS で起動すれば md として扱うことができるようです。RAID 非対応の旧メインマシン（ThinkPad T510）に接続して、中身のデータにアクセスできることを確認しました。これで安心。あ、いえ、だとしても rm -rf のようなことを考えれば、RAID1 であってもバックアップが要らないということではないとは、理解しています。

2016-02-04追記
Win7上で計測したCDMの計測値のうち、READ値が高いのは、IRSTドライバの振る舞いによるものであり、Linuxのmd RAID1の場合は１ストリームでは１ドライブ分しか出ませんので、付記しておきます。ZFS on LinuxのmirrorでもREADを複数ドライブに分散させてくれるし、md RAID1もオプションでそういう機能があってもいいのかも（難しいのかもですが）。それと、最新のバージョンを確かめていませんが、Btrfs RAID1の場合も１ストリームだと同時には１ドライブにしかREADを出さないようでした（２年程度前の記憶）。


2016-08-24追記
それから１年経過ですが、Win7 / CentOS 6 / CentOS 7 のマルチブート環境として問題なく利用できています。ただ、最新の Fedora を試そうとして、空き領域に Fedora24 を入れてみたことがあるのですが、再起動のたびに md が resync してしまう（シャットダウンの際の md 周りの処理が不完全になる？）ようで、IRST RAID 環境で Fedora を使うことはあきらめました。何か設定が足りなかったのだろうか。。。

2015年7月1日の うるう秒 調整時の ntpd の挙動観測データ

本日（2015年7月1日 9:00 JST）、うるう秒挿入が実施されるので、手持ちのマシンで観測データを記録してみたいと思います。
マシン環境は次のとおりです。

[root@hoge ~]# cat /etc/centos-release
CentOS release 6.6 (Final)
[root@hoge ~]# uname -a
Linux hoge 2.6.32-504.23.4.el6.x86_64 #1 SMP Tue Jun 9 20:57:37 UTC 2015 x86_64 x86_64 x86_64 GNU/Linux
[root@hoge ~]# dmidecode -s system-manufacturer ; dmidecode -s system-version
LENOVO
ThinkPad W520
[root@hoge ~]# ps -fC ntpd
UID        PID  PPID  C STIME TTY          TIME CMD
ntp      12778     1  0 Jun30 ?        00:00:10 ntpd -u ntp:ntp -p /var/run/ntpd.pid -g -x
[root@hoge ~]# rpm -q ntp
ntp-4.2.6p5-3.el6.centos.x86_64

ThinkPad W520 + CentOS 6.6 + ntp 4.2.6系（slewモード設定）という環境です。

まず、Leap Indicator が到着しているか確認です。予め、昨日の朝から ntpq -c readvar を定期採取するように仕込んでおきました。

[root@hoge ~]# less ntpq-c_readvar.log
...
2015-06-30 09:31:12 associd=0 status=0615 leap_none, sync_ntp, 1 event, clock_sync,
2015-06-30 09:31:12 version="ntpd 4.2.6p5@1.2349-o Mon Mar 16 14:53:03 UTC 2015 (1)",
2015-06-30 09:31:12 processor="x86_64", system="Linux/2.6.32-504.23.4.el6.x86_64", leap=00,
2015-06-30 09:31:12 stratum=3, precision=-24, rootdelay=23.151, rootdisp=315.573,
2015-06-30 09:31:12 refid=106.187.50.84,
2015-06-30 09:31:12 reftime=d93c60c7.306f0aee  Tue, Jun 30 2015  9:26:47.189,
2015-06-30 09:31:12 clock=d93c61d0.45e5528d  Tue, Jun 30 2015  9:31:12.273, peer=18506, tc=6,
2015-06-30 09:31:12 mintc=3, offset=-270.419, frequency=198.276, sys_jitter=4.409,
2015-06-30 09:31:12 clk_jitter=10.496, clk_wander=6.132

2015-06-30 09:32:12 associd=0 status=4615 leap_add_sec, sync_ntp, 1 event, clock_sync,
2015-06-30 09:32:12 version="ntpd 4.2.6p5@1.2349-o Mon Mar 16 14:53:03 UTC 2015 (1)",
2015-06-30 09:32:12 processor="x86_64", system="Linux/2.6.32-504.23.4.el6.x86_64", leap=01,
2015-06-30 09:32:12 stratum=3, precision=-24, rootdelay=52.667, rootdisp=321.239,
2015-06-30 09:32:12 refid=202.234.64.222,
2015-06-30 09:32:12 reftime=d93c61bd.33a3a956  Tue, Jun 30 2015  9:30:53.201,
2015-06-30 09:32:12 clock=d93c620c.4797c6d6  Tue, Jun 30 2015  9:32:12.279, peer=18505, tc=6,
2015-06-30 09:32:12 mintc=3, offset=-270.889, frequency=194.208, sys_jitter=3.803,
2015-06-30 09:32:12 clk_jitter=9.819, clk_wander=5.913

2015-06-30 09:33:12 associd=0 status=461a leap_add_sec, sync_ntp, 1 event, leap_disarmed,
2015-06-30 09:33:12 version="ntpd 4.2.6p5@1.2349-o Mon Mar 16 14:53:03 UTC 2015 (1)",
2015-06-30 09:33:12 processor="x86_64", system="Linux/2.6.32-504.23.4.el6.x86_64", leap=01,
2015-06-30 09:33:12 stratum=3, precision=-24, rootdelay=19.556, rootdisp=307.926,
2015-06-30 09:33:12 refid=122.215.240.52,
2015-06-30 09:33:12 reftime=d93c61f5.2f46436e  Tue, Jun 30 2015  9:31:49.184,
2015-06-30 09:33:12 clock=d93c6248.46b5ce84  Tue, Jun 30 2015  9:33:12.276, peer=18503, tc=6,
2015-06-30 09:33:12 mintc=3, offset=-262.259, frequency=193.207, sys_jitter=5.568,
2015-06-30 09:33:12 clk_jitter=9.679, clk_wander=5.543
...

Leap Indicator は、うるう秒の 24時間前 から通知されることになってますが、わたしのマシンで認識されたのは、9時半頃だったようです。

次は、現在（6:16）の状態です。

[root@hoge ~]# date
Wed Jul  1 06:16:29 JST 2015
[root@hoge ~]# ntpq -c readvar
associd=0 status=461a leap_add_sec, sync_ntp, 1 event, leap_disarmed,
version="ntpd 4.2.6p5@1.2349-o Mon Mar 16 14:53:03 UTC 2015 (1)",
processor="x86_64", system="Linux/2.6.32-504.23.4.el6.x86_64", leap=01,
stratum=3, precision=-24, rootdelay=54.844, rootdisp=62.648,
refid=202.234.64.222,
reftime=d93d82c0.32fbf279  Wed, Jul  1 2015  6:04:00.199,
clock=d93d85b6.7bb5c81a  Wed, Jul  1 2015  6:16:38.483, peer=18505, tc=7,
mintc=3, offset=-2.242, frequency=-1.742, sys_jitter=1.101,
clk_jitter=0.896, clk_wander=0.023
[root@hoge ~]# ntpq -p
     remote           refid      st t when poll reach   delay   offset  jitter
==============================================================================
-122x215x240x52. 133.243.238.164  2 u  124  128  377   17.892   -0.253   0.572
+chobi.paina.jp  131.112.125.48   2 u   98  128  377   19.177   -2.397  53.470
*ntp.kiba.net    193.221.26.33    2 u  107  128  373   31.772   -3.135   5.208
+gw1.kohaaloha.c 133.243.238.244  2 u  110  128  377   19.573   -1.331   0.842
[root@hoge ~]# grep ^server /etc/ntp.conf  ※いじっているのは次の箇所だけです
server 0.centos.pool.ntp.org iburst maxpoll 8
server 1.centos.pool.ntp.org iburst maxpoll 8
server 2.centos.pool.ntp.org iburst maxpoll 8
server 3.centos.pool.ntp.org iburst maxpoll 8
[root@hoge ~]# ntptime
ntp_gettime() returns code 5 (ERROR)
  time d93d85c3.123a8000  Wed, Jul  1 2015  6:16:51.071, (.071205),
  maximum error 16000000 us, estimated error 16 us, TAI offset 0
ntp_adjtime() returns code 5 (ERROR)
  modes 0x0 (),
  offset 0.000 us, frequency 0.000 ppm, interval 1 s,
  maximum error 16000000 us, estimated error 16 us,
  status 0x41 (PLL,UNSYNC),
  time constant 7, precision 1.000 us, tolerance 500 ppm,

続きは、また今晩書きたいと思います。

2015-07-02追記
次回の参考になるよう、slew モードで１秒が補正されるまでのデータを残しておきます。
まず、munin のグラフです。


次は、ntpq -np の出力を定期採取したデータです。

                         remote           refid      st t when poll reach   delay   offset  jitter
                    ==============================================================================
2015-07-01 04:02:14 *106.xxx.yy.zz   133.243.u.vvv    2 u   11   64  377   19.788   -2.099   0.993
2015-07-01 04:32:14 +106.xxx.yy.zz   133.243.u.vvv    2 u   32  128  377   19.714   -1.349   0.772
2015-07-01 05:02:14 *106.xxx.yy.zz   133.243.u.vvv    2 u  118  128  377   20.725   -2.126   2.264
2015-07-01 05:32:14 *106.xxx.yy.zz   133.243.u.vvv    2 u   76  128  377   20.475   -1.875   1.471
2015-07-01 06:02:14 +106.xxx.yy.zz   133.243.u.vvv    2 u   27  128  377   20.205   -1.154   2.433
2015-07-01 06:32:14 *106.xxx.yy.zz   133.243.u.vvv    2 u  122  128  377   21.338   -0.645   2.110
2015-07-01 07:02:14 *106.xxx.yy.zz   133.243.u.vvv    2 u  202  256  377   20.592   -2.101   1.402
2015-07-01 07:32:14 +106.xxx.yy.zz   133.243.u.vvv    2 u  143  256  377   20.653   -2.038   3.277
2015-07-01 08:02:14 +106.xxx.yy.zz   133.243.u.vvv    2 u  111  256  377   20.023   -2.303   0.631
2015-07-01 08:32:14 *106.xxx.yy.zz   133.243.u.vvv    2 u   60  256  377   19.803   -2.709   0.536
2015-07-01 09:02:14 +106.xxx.yy.zz   133.243.u.vvv    2 u    9  256  377   21.023   -1.460 378.296
2015-07-01 09:32:14 x106.xxx.yy.zz   133.243.u.vvv    2 u  231  256  377   18.791  -1001.8 377.872
2015-07-01 10:02:14 *106.xxx.yy.zz   133.243.u.vvv    2 u  187  256  377   18.732  -850.50 128.921
2015-07-01 10:32:14 x106.xxx.yy.zz   133.243.u.vvv    2 u  140  256  377   19.959  -338.47 202.357
2015-07-01 11:02:14 x106.xxx.yy.zz   133.243.u.vvv    2 u  108  256  377   19.959  -338.47 124.808
2015-07-01 11:32:14 +106.xxx.yy.zz   133.243.u.vvv    2 u   94  256  377   18.902  -92.918  48.587
2015-07-01 12:02:14 *106.xxx.yy.zz   133.243.u.vvv    2 u   46  256  377   19.725  -46.976  24.980
2015-07-01 12:32:14 -106.xxx.yy.zz   133.243.u.vvv    2 u   14  256  377   21.471   24.117  16.097
2015-07-01 13:02:14 *106.xxx.yy.zz   133.243.u.vvv    2 u  247  256  377   21.222   33.890  23.763
2015-07-01 13:32:14 +106.xxx.yy.zz   133.243.u.vvv    2 u  202  256  377   21.370   47.732  20.740
2015-07-01 14:02:14 *106.xxx.yy.zz   133.243.u.vvv    2 u  160  256  377   20.123   66.180  31.655
2015-07-01 14:32:14 +106.xxx.yy.zz   133.243.u.vvv    2 u  128  256  377   19.378   67.970   5.429
2015-07-01 15:02:14 *106.xxx.yy.zz   133.243.u.vvv    2 u   99  256  377   19.839   71.999   0.685
2015-07-01 15:32:14 +106.xxx.yy.zz   133.243.u.vvv    2 u   50  256  377   20.541   71.707   3.409
2015-07-01 16:02:14 *106.xxx.yy.zz   133.243.u.vvv    2 u   10  256  377   20.986   73.016   1.333
2015-07-01 16:32:14 *106.xxx.yy.zz   133.243.u.vvv    2 u  252  256  377   20.864   71.603   3.392
2015-07-01 17:02:14 +106.xxx.yy.zz   133.243.u.vvv    2 u  215  256  377   21.057   72.781   3.576
2015-07-01 17:32:14 +106.xxx.yy.zz   133.243.u.vvv    2 u  153  256  377   20.601   68.391   5.254
2015-07-01 18:02:14 +106.xxx.yy.zz   133.243.u.vvv    2 u  108  256  377   21.467   66.549   2.707
2015-07-01 18:32:14 +106.xxx.yy.zz   133.243.u.vvv    2 u   60  256  377   21.532   63.015  36.577
2015-07-01 19:02:14 *106.xxx.yy.zz   133.243.u.vvv    2 u    7  256  377   21.525   58.468   1.322
2015-07-01 19:32:14 +106.xxx.yy.zz   133.243.u.vvv    2 u  233  256  377   22.197   57.370   3.762
2015-07-01 20:02:14 +106.xxx.yy.zz   133.243.u.vvv    2 u  184  256  377   19.177   58.782  30.390
2015-07-01 20:32:14 +106.xxx.yy.zz   133.243.u.vvv    2 u  122  256  377   20.570   54.714   1.959
2015-07-01 21:02:14 *106.xxx.yy.zz   133.243.u.vvv    2 u   79  256  377   20.570   54.714   5.023
2015-07-01 21:32:14 *106.xxx.yy.zz   133.243.u.vvv    2 u   50  256  377   21.628   50.943   4.072
2015-07-01 22:02:14 *106.xxx.yy.zz   133.243.u.vvv    2 u    3  256  377   36.953   41.933   4.676
2015-07-01 22:32:14 +106.xxx.yy.zz   133.243.u.vvv    2 u  224  256  377   37.968   44.620  46.186
2015-07-01 23:02:14 +106.xxx.yy.zz   133.243.u.vvv    2 u  181  256  377   36.238   41.819  16.091
2015-07-01 23:32:14 +106.xxx.yy.zz   133.243.u.vvv    2 u  152  256  377   36.340   46.415   7.950
2015-07-02 00:02:14 +106.xxx.yy.zz   133.243.u.vvv    2 u   89  256  377   39.487   42.372  11.150
2015-07-02 00:32:14 +106.xxx.yy.zz   133.243.u.vvv    2 u   59  128  377   32.067   32.882   5.267
2015-07-02 01:02:14 *106.xxx.yy.zz   133.243.u.vvv    2 u   21   64  377   21.239   13.838   6.248
2015-07-02 01:32:14 +106.xxx.yy.zz   133.243.u.vvv    2 u   50  128  377   22.461   12.798   3.011
2015-07-02 02:02:14 +106.xxx.yy.zz   133.243.u.vvv    2 u   11  256  377   21.303   11.877  16.779
2015-07-02 02:32:14 +106.xxx.yy.zz   133.243.u.vvv    2 u  249  256  377   21.504   16.263   6.163
2015-07-02 03:02:14 *106.xxx.yy.zz   133.243.u.vvv    2 u   61  128  377   20.093   16.886   1.101
2015-07-02 03:32:16 *106.xxx.yy.zz   133.243.u.vvv    2 u   24   64  377   20.018    5.750   2.548
2015-07-02 04:02:16 +106.xxx.yy.zz   133.243.u.vvv    2 u   48   64  377   21.012    2.840   0.944
2015-07-02 04:32:16 *106.xxx.yy.zz   133.243.u.vvv    2 u   63  128  377   19.750    3.482   0.846
2015-07-02 05:02:16 *106.xxx.yy.zz   133.243.u.vvv    2 u   12   64  377   19.643    4.361  26.509
2015-07-02 05:32:16 +106.xxx.yy.zz   133.243.u.vvv    2 u   41   64  377   21.850    1.910   2.910
2015-07-02 06:02:16 +106.xxx.yy.zz   133.243.u.vvv    2 u   12   64  377   20.327    1.325   7.538
2015-07-02 06:32:16 *106.xxx.yy.zz   133.243.u.vvv    2 u   49   64  377   19.247    1.809   3.580
2015-07-02 07:02:16 *106.xxx.yy.zz   133.243.u.vvv    2 u   77  128  377   20.714   -0.037   1.250
2015-07-02 07:32:16 *106.xxx.yy.zz   133.243.u.vvv    2 u   28  128  377   20.356    1.243   0.894
2015-07-02 08:02:16 +106.xxx.yy.zz   133.243.u.vvv    2 u  260  256  377   21.686    2.613   2.557
2015-07-02 08:32:16 +106.xxx.yy.zz   133.243.u.vvv    2 u  227  256  377   20.114    2.458  16.880
2015-07-02 09:02:16 +106.xxx.yy.zz   133.243.u.vvv    2 u  187  256  377   21.051    3.840   0.556
2015-07-02 09:32:16 *106.xxx.yy.zz   133.243.u.vvv    2 u  150  256  377   21.165    3.337   6.229
2015-07-02 10:02:16 *106.xxx.yy.zz   133.243.u.vvv    2 u  105  128  377   20.724    2.008   1.382

実際は、上位サーバは４つ指定してあり、そのうちの１つについて 30 分毎のデータです。前回（2012-07-01）観測したマシンでは、offset が 10 ミリ秒より小さくなるまでに 27 時間かかりましたが、今回は maxpoll 8 を設定した効果が出たようで、18 時間半でした。

最後に、/var/log/messages 抜粋です。

[root@hoge ~]# who -b
         system boot  2015-06-30 06:00
[root@hoge ~]# grep ntp /var/log/messages
※データ採取準備をして１度マシンを再起動した
Jun 30 06:01:04 hoge ntpd[12771]: ntpd 4.2.6p5@1.2349-o Mon Mar 16 14:53:03 UTC 2015 (1)
Jun 30 06:01:04 hoge ntpd[12778]: proto: precision = 0.048 usec
Jun 30 06:01:04 hoge ntpd[12778]: 0.0.0.0 c01d 0d kern kernel time sync enabled
Jun 30 06:01:04 hoge ntpd[12778]: Listen and drop on 0 v4wildcard 0.0.0.0 UDP 123
Jun 30 06:01:04 hoge ntpd[12778]: Listen and drop on 1 v6wildcard :: UDP 123
Jun 30 06:01:04 hoge ntpd[12778]: Listen normally on 2 lo 127.0.0.1 UDP 123
Jun 30 06:01:04 hoge ntpd[12778]: Listen normally on 3 lo ::1 UDP 123
Jun 30 06:01:04 hoge ntpd[12778]: peers refreshed
Jun 30 06:01:04 hoge ntpd[12778]: Listening on routing socket on fd #20 for interface updates
Jun 30 06:01:04 hoge ntpd[12778]: Deferring DNS for 0.centos.pool.ntp.org 1
Jun 30 06:01:04 hoge ntpd[12778]: Deferring DNS for 1.centos.pool.ntp.org 1
Jun 30 06:01:04 hoge ntpd[12778]: Deferring DNS for 2.centos.pool.ntp.org 1
Jun 30 06:01:04 hoge ntpd[12778]: Deferring DNS for 3.centos.pool.ntp.org 1
Jun 30 06:01:04 hoge ntpd[12778]: 0.0.0.0 c016 06 restart
Jun 30 06:01:04 hoge ntpd[12778]: 0.0.0.0 c012 02 freq_set ntpd 500.000 PPM
Jun 30 06:01:07 hoge ntpd[12778]: Listen normally on 4 virbr0 192.168.122.1 UDP 123
Jun 30 06:01:07 hoge ntpd[12778]: peers refreshed
Jun 30 06:01:09 hoge ntpd[12778]: Listen normally on 5 eth0 fe80::f2de:f1ff:fef9:52c5 UDP 123
Jun 30 06:01:09 hoge ntpd[12778]: peers refreshed
Jun 30 06:01:22 hoge ntpd[12778]: Listen normally on 6 wlan0 fe80::2677:3ff:fe8f:224 UDP 123
Jun 30 06:01:22 hoge ntpd[12778]: peers refreshed
Jun 30 06:01:24 hoge ntpd[12778]: Listen normally on 7 wlan0 192.168.1.4 UDP 123
Jun 30 06:01:24 hoge ntpd[12778]: peers refreshed
Jun 30 06:01:24 hoge ntpd_intres[12786]: DNS 0.centos.pool.ntp.org -> 122.215.240.52
Jun 30 06:01:24 hoge ntpd_intres[12786]: DNS 1.centos.pool.ntp.org -> 157.7.154.23
Jun 30 06:01:24 hoge ntpd_intres[12786]: DNS 2.centos.pool.ntp.org -> 202.234.64.222
Jun 30 06:01:25 hoge ntpd_intres[12786]: DNS 3.centos.pool.ntp.org -> 106.187.50.84
Jun 30 06:01:31 hoge ntpd[12778]: 0.0.0.0 c615 05 clock_sync
Jun 30 09:32:53 hoge ntpd[12778]: 0.0.0.0 461a 0a leap_disarmed
Jul  1 09:00:00 hoge ntpd[12778]: 0.0.0.0 061b 0b leap_event
Jul  1 09:17:18 hoge ntpd[12778]: 0.0.0.0 0618 08 no_sys_peer
※以後はntpdからメッセージは出なかった

というわけで、めでたし、めでたし。

うるう秒（閏秒）の際にcronが二重に実行されるかも？という都市伝説（？）について

今年のうるう秒調整（2015年7月1日午前9:00日本時間）実施まで、あと二週間に迫りましたが、 うるう秒の際に cron ジョブが二重に実行されるかも？という都市伝説（？）を耳にしたことがあるので、CentOS 6 に関して調べてみました。
そもそも /var/log/cron を見渡すと、どれもこれも毎分 :01 秒を狙っている感じです。

[root@hoge ~]# tail /var/log/cron
Jun 16 00:10:01 hoge CROND[9508]: (root) CMD (/usr/lib64/sa/sa1 1 1)
Jun 16 00:11:01 hoge CROND[9546]: (root) CMD (/usr/lib64/sa/sa1 1 1)
Jun 17 01:33:31 hoge crond[2699]: (CRON) INFO (RANDOM_DELAY will be scaled with factor 72% if used.)
Jun 17 01:33:31 hoge crond[2699]: (CRON) INFO (running with inotify support)
Jun 17 01:34:01 hoge CROND[5736]: (root) CMD (/usr/lib64/sa/sa1 1 1)
Jun 17 01:35:01 hoge CROND[6163]: (root) CMD (/usr/lib64/sa/sa1 1 1)
Jun 17 01:36:01 hoge CROND[6197]: (root) CMD (/usr/lib64/sa/sa1 1 1)
Jun 17 01:37:01 hoge CROND[6223]: (root) CMD (/usr/lib64/sa/sa1 1 1)
Jun 17 01:38:01 hoge CROND[6254]: (root) CMD (/usr/lib64/sa/sa1 1 1)
Jun 17 01:39:01 hoge CROND[6736]: (root) CMD (/usr/lib64/sa/sa1 1 1)

それで検索してみますと、cronie について調べている先人の方がおられ、やはり毎分 :01 秒を狙ってスリープしているようです。
http://moro-archive.hatenablog.com/entry/2015/03/17/011823
なぜ、:01 秒狙いなのか？ソース上にはコメントないみたいですが、もしかしたら、うるう秒のことが視野に入っているということなのかも。

というわけで、あっけなく調査終了です。こういった実装なら、うるう秒の際に cron ジョブが二重に実行されるということは、なさそうです。

Linux カーネルのうるう秒調整は、:59 秒を 2 回続ける（ミリ秒単位だと ... :59.998 , :59.999 , :59.000 ... と進める）という実装になってますが、それって cron も意識しているのかもしれませんね。

■関連記事
2017年1月1日の うるう秒 調整時の ntpd の挙動観測データ (次回投稿するつもり)
2015年7月1日の うるう秒 調整時の ntpd の挙動観測データ
2012年7月1日の うるう秒 調整時の ntpd の挙動観測データ
ntpd を１日止めた場合のズレはどの程度か？

中古 HDD の初期確認

記憶する限り初めて、中古 HDD を購入した（中古 SSD は買ったことありましたが）のですが、Linux 上での初期確認ポイントについて、備忘録です。
CentOS 7.1 で操作しています。
■関連記事 中古 HDD の初期確認、２個目（2015年10月）

まず、とりあえず、認識されなれば、そこで終わりですが、

[    3.239373] scsi 3:0:0:0: Direct-Access     ATA      SEAGATE ST310003 NA02 PQ: 0 ANSI: 5
[    3.239662] sd 3:0:0:0: [sdd] 1953525168 512-byte logical blocks: (1.00 TB/931 GiB)
[    3.240247] sd 3:0:0:0: [sdd] Write Protect is off
[    3.240338] sd 3:0:0:0: [sdd] Mode Sense: 00 3a 00 00
[    3.240477] sd 3:0:0:0: [sdd] Write cache: disabled, read cache: enabled, doesn't support DPO or FUA
[    3.260270] sd 3:0:0:0: [sdd] Attached SCSI disk

これは OK でした。ただし、しばらく試運転していて、どうも遅いと思ったら、Write cache が disabled になっていることに気がつきました。どうやら、このディスクは、RAID コントローラ配下で利用されていたのかもしれません。LSI とかの RAID コントローラ配下の場合、デフォルトでは HDD のキャッシュが off にされていることが多いですから。
キャッシュを enable にするには、hdparm -W1 コマンドを使えばいいです。

[root@hoge ~]# hdparm -W1 /dev/sdd

/dev/sdd:
 setting drive write-caching to 1 (on)
 write-caching =  1 (on)
[root@hoge ~]# hdparm -i /dev/sdd
dev/sdd:

 Model=SEAGATE ST31000340NS, FwRev=NA02, SerialNo=xxxxxxxx
 Config={ HardSect NotMFM HdSw>15uSec Fixed DTR>10Mbs RotSpdTol>.5% }
 RawCHS=16383/16/63, TrkSize=0, SectSize=0, ECCbytes=4
 BuffType=unknown, BuffSize=unknown, MaxMultSect=16, MultSect=off
 CurCHS=16383/16/63, CurSects=16514064, LBA=yes, LBAsects=1953525168
 IORDY=on/off, tPIO={min:120,w/IORDY:120}, tDMA={min:120,rec:120}
 PIO modes:  pio0 pio1 pio2 pio3 pio4 
 DMA modes:  mdma0 mdma1 mdma2 
 UDMA modes: udma0 udma1 udma2 udma3 udma4 udma5 *udma6 
 AdvancedPM=no WriteCache=enabled
 Drive conforms to: unknown:  ATA/ATAPI-4,5,6,7

 * signifies the current active mode

次に S.M.A.R.T. の確認です。

[root@hoge ~]# smartctl -a /dev/sdd
smartctl 6.2 2013-07-26 r3841 [x86_64-linux-3.10.0-229.4.2.el7.x86_64] (local build)
Copyright (C) 2002-13, Bruce Allen, Christian Franke, www.smartmontools.org

=== START OF INFORMATION SECTION ===
Device Model:     SEAGATE ST31000340NS
Serial Number:    xxxxxxxx
LU WWN Device Id: 5 000c50 yyyyyyyy
Firmware Version: NA02
User Capacity:    1,000,204,886,016 bytes [1.00 TB]
Sector Size:      512 bytes logical/physical
Rotation Rate:    7200 rpm
Device is:        Not in smartctl database [for details use: -P showall]
ATA Version is:   ATA8-ACS T13/1699-D revision 4
SATA Version is:  SATA 2.6, 3.0 Gb/s
Local Time is:    Mon Jun 15 18:09:51 2015 JST
SMART support is: Available - device has SMART capability.
SMART support is: Enabled

=== START OF READ SMART DATA SECTION ===
SMART overall-health self-assessment test result: PASSED

General SMART Values:
Offline data collection status:  (0x82) Offline data collection activity
     was completed without error.
     Auto Offline Data Collection: Enabled.
Self-test execution status:      (   0) The previous self-test routine completed
     without error or no self-test has ever 
     been run.
Total time to complete Offline 
data collection:   (  634) seconds.
Offline data collection
capabilities:     (0x7b) SMART execute Offline immediate.
     Auto Offline data collection on/off support.
     Suspend Offline collection upon new
     command.
     Offline surface scan supported.
     Self-test supported.
     Conveyance Self-test supported.
     Selective Self-test supported.
SMART capabilities:            (0x0003) Saves SMART data before entering
     power-saving mode.
     Supports SMART auto save timer.
Error logging capability:        (0x01) Error logging supported.
     General Purpose Logging supported.
Short self-test routine 
recommended polling time:   (   1) minutes.
Extended self-test routine
recommended polling time:   ( 227) minutes.
Conveyance self-test routine
recommended polling time:   (   2) minutes.
SCT capabilities:         (0x103f) SCT Status supported.
     SCT Error Recovery Control supported.
     SCT Feature Control supported.
     SCT Data Table supported.

SMART Attributes Data Structure revision number: 10
Vendor Specific SMART Attributes with Thresholds:
ID# ATTRIBUTE_NAME          FLAG     VALUE WORST THRESH TYPE      UPDATED  WHEN_FAILED RAW_VALUE
  1 Raw_Read_Error_Rate     0x000f   084   063   044    Pre-fail  Always       -       237886154
  3 Spin_Up_Time            0x0003   099   091   000    Pre-fail  Always       -       0
  4 Start_Stop_Count        0x0032   100   100   020    Old_age   Always       -       179
  5 Reallocated_Sector_Ct   0x0033   100   100   036    Pre-fail  Always       -       0
  7 Seek_Error_Rate         0x000f   076   060   030    Pre-fail  Always       -       13038515776
  9 Power_On_Hours          0x0032   048   048   000    Old_age   Always       -       45906
 10 Spin_Retry_Count        0x0013   100   100   097    Pre-fail  Always       -       0
 12 Power_Cycle_Count       0x0032   100   037   020    Old_age   Always       -       132
184 End-to-End_Error        0x0032   100   100   099    Old_age   Always       -       0
187 Reported_Uncorrect      0x0032   100   100   000    Old_age   Always       -       0
188 Command_Timeout         0x0032   100   100   000    Old_age   Always       -       0
189 High_Fly_Writes         0x003a   100   100   000    Old_age   Always       -       0
190 Airflow_Temperature_Cel 0x0022   062   055   045    Old_age   Always       -       38 (Min/Max 27/38)
194 Temperature_Celsius     0x0022   038   045   000    Old_age   Always       -       38 (0 13 0 0 0)
195 Hardware_ECC_Recovered  0x001a   051   047   000    Old_age   Always       -       237886154
197 Current_Pending_Sector  0x0012   100   100   000    Old_age   Always       -       0
198 Offline_Uncorrectable   0x0010   100   100   000    Old_age   Offline      -       0
199 UDMA_CRC_Error_Count    0x003e   200   200   000    Old_age   Always       -       0

SMART Error Log Version: 1
No Errors Logged

SMART Self-test log structure revision number 1
No self-tests have been logged.  [To run self-tests, use: smartctl -t]


SMART Selective self-test log data structure revision number 1
 SPAN  MIN_LBA  MAX_LBA  CURRENT_TEST_STATUS
    1        0        0  Not_testing
    2        0        0  Not_testing
    3        0        0  Not_testing
    4        0        0  Not_testing
    5        0        0  Not_testing
Selective self-test flags (0x0):
  After scanning selected spans, do NOT read-scan remainder of disk.
If Selective self-test is pending on power-up, resume after 0 minute delay.

不良セクタの有無なども勿論気になるところですが、まずは運用年数を確認です。9 Power_On_Hours の値が 45906 なので、

[root@hoge ~]# echo "45906 / 24 / 365" | bc -l
5.24041095890410958904

だいたい、きっちり 5年 ですね。うーん、プロの仕業でしょうか。ガタが来る前にリフレッシュですかね。
ちなみに HGST だと、ラベルに製造年月が書いていますが、今回入手した Seagate 製品（Barracuda ES.2）のラベルには記載ありませんでした。2015-06-20追記、後日よく見てみたら、Date Code: 09364 と記載ありました。http://www.j-pro.info/remake/sgcalc.php　こちらのツールによると 03/2009 を意味するそうです。というわけで６歳でした。

そして、不良セクタ関係の項目（5 Reallocated_Sector_Ct、197 Current_Pending_Sector など）は、どれもゼロでした。
エラーログも無し（No Errors Logged）です。

なかなか、良さげな個体を安価に入手できたように思います。

なお、新品であれば、全セクタ検査などしてから使い始めるのが私の慣例ですが、中古であるし、ZFS で冗長化して使うので、そのまま投入して使い倒すのみです。返品できないし、ベンダの保証も無いですから。


2015-06-20追記
初期確認では、S.M.A.R.T. は全く問題なさそうな状態でしたが、実際に RAIDZ に組み込んでみた（故障した HDD と zpool replace した）ところ、resilver（ZFS の用語でリビルドのこと）は問題なく成功したものの、そのあと更に、zpool scrub（整合性チェック）を行なったら、ATA bus error が多発しました。
smartctl -A の値を確認したところ、197 Current_Pending_Sector および 198 Offline_Uncorrectable の値が 6 になってました。つまり不良セクタが生じたことを示唆していました。過去の経験から、この程度ならまだ諦めることはなく、不良セクタの LBA 番号を確認して、そのセクタにゼロ書き込みすることで、代替セクタへの切り替えを促すことができると思われました。実際、手間はかかりましたが、うまく行きました。
次が、不良セクタの処置を終えたあとの smartctl -a の出力です。

[root@hoge ~]# smartctl -a /dev/sdd
smartctl 6.2 2013-07-26 r3841 [x86_64-linux-3.10.0-229.4.2.el7.x86_64] (local build)
Copyright (C) 2002-13, Bruce Allen, Christian Franke, www.smartmontools.org

=== START OF INFORMATION SECTION ===
Device Model:     SEAGATE ST31000340NS
Serial Number:    xxxxxxxx
LU WWN Device Id: 5 000c50 yyyyyyyyy
Firmware Version: NA02
User Capacity:    1,000,204,886,016 bytes [1.00 TB]
Sector Size:      512 bytes logical/physical
Rotation Rate:    7200 rpm
Device is:        Not in smartctl database [for details use: -P showall]
ATA Version is:   ATA8-ACS T13/1699-D revision 4
SATA Version is:  SATA 2.6, 3.0 Gb/s
Local Time is:    Fri Jun 19 17:36:23 2015 JST
SMART support is: Available - device has SMART capability.
SMART support is: Enabled

=== START OF READ SMART DATA SECTION ===
SMART overall-health self-assessment test result: PASSED

General SMART Values:
Offline data collection status:  (0x82) Offline data collection activity
     was completed without error.
     Auto Offline Data Collection: Enabled.
Self-test execution status:      (   0) The previous self-test routine completed
     without error or no self-test has ever 
     been run.
Total time to complete Offline 
data collection:   (  634) seconds.
Offline data collection
capabilities:     (0x7b) SMART execute Offline immediate.
     Auto Offline data collection on/off support.
     Suspend Offline collection upon new
     command.
     Offline surface scan supported.
     Self-test supported.
     Conveyance Self-test supported.
     Selective Self-test supported.
SMART capabilities:            (0x0003) Saves SMART data before entering
     power-saving mode.
     Supports SMART auto save timer.
Error logging capability:        (0x01) Error logging supported.
     General Purpose Logging supported.
Short self-test routine 
recommended polling time:   (   1) minutes.
Extended self-test routine
recommended polling time:   ( 227) minutes.
Conveyance self-test routine
recommended polling time:   (   2) minutes.
SCT capabilities:         (0x103f) SCT Status supported.
     SCT Error Recovery Control supported.
     SCT Feature Control supported.
     SCT Data Table supported.

SMART Attributes Data Structure revision number: 10
Vendor Specific SMART Attributes with Thresholds:
ID# ATTRIBUTE_NAME          FLAG     VALUE WORST THRESH TYPE      UPDATED  WHEN_FAILED RAW_VALUE
  1 Raw_Read_Error_Rate     0x000f   079   047   044    Pre-fail  Always       -       87683421
  3 Spin_Up_Time            0x0003   099   091   000    Pre-fail  Always       -       0
  4 Start_Stop_Count        0x0032   100   100   020    Old_age   Always       -       183
  5 Reallocated_Sector_Ct   0x0033   082   082   036    Pre-fail  Always       -       388
  7 Seek_Error_Rate         0x000f   076   060   030    Pre-fail  Always       -       13040071396
  9 Power_On_Hours          0x0032   048   048   000    Old_age   Always       -       46000
 10 Spin_Retry_Count        0x0013   100   100   097    Pre-fail  Always       -       0
 12 Power_Cycle_Count       0x0032   100   037   020    Old_age   Always       -       136
184 End-to-End_Error        0x0032   100   100   099    Old_age   Always       -       0
187 Reported_Uncorrect      0x0032   001   001   000    Old_age   Always       -       507
188 Command_Timeout         0x0032   100   100   000    Old_age   Always       -       0
189 High_Fly_Writes         0x003a   100   100   000    Old_age   Always       -       0
190 Airflow_Temperature_Cel 0x0022   065   055   045    Old_age   Always       -       35 (Min/Max 33/38)
194 Temperature_Celsius     0x0022   035   045   000    Old_age   Always       -       35 (0 13 0 0 0)
195 Hardware_ECC_Recovered  0x001a   052   041   000    Old_age   Always       -       87683421
197 Current_Pending_Sector  0x0012   100   100   000    Old_age   Always       -       0
198 Offline_Uncorrectable   0x0010   100   100   000    Old_age   Offline      -       0
199 UDMA_CRC_Error_Count    0x003e   200   200   000    Old_age   Always       -       0

SMART Error Log Version: 1
ATA Error Count: 244 (device log contains only the most recent five errors)
 CR = Command Register [HEX]
 FR = Features Register [HEX]
 SC = Sector Count Register [HEX]
 SN = Sector Number Register [HEX]
 CL = Cylinder Low Register [HEX]
 CH = Cylinder High Register [HEX]
 DH = Device/Head Register [HEX]
 DC = Device Command Register [HEX]
 ER = Error register [HEX]
 ST = Status register [HEX]
Powered_Up_Time is measured from power on, and printed as
DDd+hh:mm:SS.sss where DD=days, hh=hours, mm=minutes,
SS=sec, and sss=millisec. It "wraps" after 49.710 days.

Error 244 occurred at disk power-on lifetime: 45952 hours (1914 days + 16 hours)
  When the command that caused the error occurred, the device was active or idle.

  After command completion occurred, registers were:
  ER ST SC SN CL CH DH
  -- -- -- -- -- -- --
  40 51 00 ff ff ff 0f  Error: UNC at LBA = 0x0fffffff = 268435455

  Commands leading to the command that caused the error were:
  CR FR SC SN CL CH DH DC   Powered_Up_Time  Command/Feature_Name
  -- -- -- -- -- -- -- --  ----------------  --------------------
  60 00 08 ff ff ff 4f 00      03:07:15.069  READ FPDMA QUEUED
  ec 00 01 00 00 00 00 00      03:07:15.067  IDENTIFY DEVICE
  27 00 00 00 00 00 e0 00      03:07:15.065  READ NATIVE MAX ADDRESS EXT [OBS-ACS-3]
  ec 00 00 00 00 00 a0 00      03:07:15.064  IDENTIFY DEVICE
  ef 03 46 00 00 00 a0 00      03:07:15.064  SET FEATURES [Set transfer mode]

Error 243 occurred at disk power-on lifetime: 45952 hours (1914 days + 16 hours)
  When the command that caused the error occurred, the device was active or idle.

  After command completion occurred, registers were:
  ER ST SC SN CL CH DH
  -- -- -- -- -- -- --
  40 51 00 ff ff ff 0f  Error: UNC at LBA = 0x0fffffff = 268435455

  Commands leading to the command that caused the error were:
  CR FR SC SN CL CH DH DC   Powered_Up_Time  Command/Feature_Name
  -- -- -- -- -- -- -- --  ----------------  --------------------
  60 00 08 ff ff ff 4f 00      03:07:11.956  READ FPDMA QUEUED
  b0 d5 01 09 4f c2 00 00      03:06:53.011  SMART READ LOG
  b0 d5 01 06 4f c2 00 00      03:06:52.963  SMART READ LOG
  b0 d5 01 01 4f c2 00 00      03:06:52.954  SMART READ LOG
  b0 d5 01 00 4f c2 00 00      03:06:52.954  SMART READ LOG

Error 242 occurred at disk power-on lifetime: 45952 hours (1914 days + 16 hours)
  When the command that caused the error occurred, the device was active or idle.

  After command completion occurred, registers were:
  ER ST SC SN CL CH DH
  -- -- -- -- -- -- --
  40 51 00 ff ff ff 0f  Error: UNC at LBA = 0x0fffffff = 268435455

  Commands leading to the command that caused the error were:
  CR FR SC SN CL CH DH DC   Powered_Up_Time  Command/Feature_Name
  -- -- -- -- -- -- -- --  ----------------  --------------------
  60 00 08 ff ff ff 4f 00      03:04:27.167  READ FPDMA QUEUED
  27 00 00 00 00 00 e0 00      03:04:27.166  READ NATIVE MAX ADDRESS EXT [OBS-ACS-3]
  ec 00 00 00 00 00 a0 00      03:04:27.164  IDENTIFY DEVICE
  ef 03 46 00 00 00 a0 00      03:04:27.164  SET FEATURES [Set transfer mode]
  27 00 00 00 00 00 e0 00      03:04:27.163  READ NATIVE MAX ADDRESS EXT [OBS-ACS-3]

Error 241 occurred at disk power-on lifetime: 45952 hours (1914 days + 16 hours)
  When the command that caused the error occurred, the device was active or idle.

  After command completion occurred, registers were:
  ER ST SC SN CL CH DH
  -- -- -- -- -- -- --
  40 51 00 ff ff ff 0f  Error: UNC at LBA = 0x0fffffff = 268435455

  Commands leading to the command that caused the error were:
  CR FR SC SN CL CH DH DC   Powered_Up_Time  Command/Feature_Name
  -- -- -- -- -- -- -- --  ----------------  --------------------
  60 00 08 ff ff ff 4f 00      03:04:24.106  READ FPDMA QUEUED
  b0 d5 01 09 4f c2 00 00      03:04:03.645  SMART READ LOG
  b0 d5 01 06 4f c2 00 00      03:04:03.597  SMART READ LOG
  b0 d5 01 01 4f c2 00 00      03:04:03.588  SMART READ LOG
  b0 d5 01 00 4f c2 00 00      03:04:03.588  SMART READ LOG

Error 240 occurred at disk power-on lifetime: 45952 hours (1914 days + 16 hours)
  When the command that caused the error occurred, the device was active or idle.

  After command completion occurred, registers were:
  ER ST SC SN CL CH DH
  -- -- -- -- -- -- --
  40 51 00 ff ff ff 0f  Error: UNC at LBA = 0x0fffffff = 268435455

  Commands leading to the command that caused the error were:
  CR FR SC SN CL CH DH DC   Powered_Up_Time  Command/Feature_Name
  -- -- -- -- -- -- -- --  ----------------  --------------------
  60 00 08 ff ff ff 4f 00      02:59:16.039  READ FPDMA QUEUED
  27 00 00 00 00 00 e0 00      02:59:16.037  READ NATIVE MAX ADDRESS EXT [OBS-ACS-3]
  ec 00 00 00 00 00 a0 00      02:59:16.035  IDENTIFY DEVICE
  ef 03 46 00 00 00 a0 00      02:59:16.035  SET FEATURES [Set transfer mode]
  27 00 00 00 00 00 e0 00      02:59:16.034  READ NATIVE MAX ADDRESS EXT [OBS-ACS-3]

SMART Self-test log structure revision number 1
Num  Test_Description    Status                  Remaining  LifeTime(hours)  LBA_of_first_error
# 1  Selective offline   Completed without error       00%     45955         -
# 2  Short offline       Completed without error       00%     45953         -
# 3  Selective offline   Completed: read failure       90%     45953         914942610
# 4  Short offline       Completed without error       00%     45953         -
# 5  Selective offline   Completed: read failure       90%     45953         914941117
# 6  Short offline       Completed without error       00%     45953         -
# 7  Selective offline   Completed: read failure       90%     45953         914938130
# 8  Short offline       Completed without error       00%     45953         -
# 9  Selective offline   Completed: read failure       90%     45953         914936637
#10  Short offline       Completed without error       00%     45953         -
#11  Selective offline   Completed: read failure       90%     45953         914925917
#12  Short offline       Completed without error       00%     45953         -
#13  Selective offline   Completed: read failure       90%     45953         914924423
#14  Short offline       Completed without error       00%     45953         -
#15  Selective offline   Completed: read failure       90%     45953         914916690
#16  Selective offline   Completed: read failure       90%     45953         914916690
#17  Short offline       Completed without error       00%     45953         -
#18  Selective offline   Completed: read failure       90%     45953         914896743
#19  Short offline       Completed without error       00%     45953         -
#20  Selective offline   Completed: read failure       90%     45953         914895250
#21  Short offline       Completed without error       00%     45953         -

SMART Selective self-test log data structure revision number 1
 SPAN    MIN_LBA     MAX_LBA  CURRENT_TEST_STATUS
    1  914940000  1953525167  Not_testing
    2          0           0  Not_testing
    3          0           0  Not_testing
    4          0           0  Not_testing
    5          0           0  Not_testing
Selective self-test flags (0x0):
  After scanning selected spans, do NOT read-scan remainder of disk.
If Selective self-test is pending on power-up, resume after 0 minute delay.

5 Reallocated_Sector_Ct の VALUE が 100 から 082 に低下しており、代替セクタが使われたことを示唆しています。

不良セクタの除去は、次のような手順で行いました。

[root@hoge ~]# smartctl -t long /dev/sdd
               ※(1) long テスト実行
...
[root@hoge ~]# smartctl -a /dev/sdd
               ※(2) long テストの終了確認（終るまで繰り返し確認）
...
[root@hoge ~]# dd if=/dev/zero of=/dev/sdd bs=4096 seek=$((LBA_of_first_errorの値/8)) count=1
               ※(3) 不良セクタへのゼロ書き込み
...
[root@hoge ~]# smartctl -t short /dev/sdd
               ※(4) short テスト実行
...
[root@hoge ~]# smartctl -a /dev/sdd
               ※(5) short テストの終了確認（終るまで繰り返し確認）
...
[root@hoge ~]# smartctl -t select,LBA_of_first_errorの値-max /dev/sdd
               ※(6) 不良セクタが発見された位置から続きのテスト（selectモード）を実行
...
[root@hoge ~]# smartctl -a /dev/sdd
               ※(7) select テストの終了確認（終るまで繰り返し確認）
...
※以降は、LBA_of_first_error が無くなるまで、手順 (3) から (7) まで繰り返し

コツがいくつかありますので以下補足です。

手順 (3) で、4096 バイト境界で書き込む必要がありました。表面上は 512n な HDD ですが、もしかしたら本当の物理セクタサイズは 4096 なのかも？（憶測です）。
■関連記事 物理セクタサイズが 4K bytes のディスクで不良セクタが発生した事例と処置

手順 (4) を行わないと、手順 (3) でゼロ書き込みした箇所が正常化されたとみなされないようでした。short テストを行わずに select テストへ進むと、再度同じ LBA が LBA_of_first_error に出てきてしまいます。上の smartctl 出力の紫色の箇所のことです。

手順 (6) の select モードの代わりに、再び long テストでも可ですが、当然セクタゼロ（LBA番号 0）から再検査することになり、所要時間が倍増してしまいます。


2015-07-05追記
その後、２週間経ちましたが、ひとまずは安定した様子で、エラーが出なくなりました。

2015-07-25追記
使用開始してから1ヵ月経ちましたが、その後は ATA bus error が出ることはなく、安定して使えています。細かく見ると、5 Reallocated_Sector_Ct が +1 増えています。

[root@hoge ~]# smartctl -A /dev/sdd
smartctl 6.2 2013-07-26 r3841 [x86_64-linux-3.10.0-229.7.2.el7.x86_64] (local build)
Copyright (C) 2002-13, Bruce Allen, Christian Franke, www.smartmontools.org

=== START OF READ SMART DATA SECTION ===
SMART Attributes Data Structure revision number: 10
Vendor Specific SMART Attributes with Thresholds:
ID# ATTRIBUTE_NAME          FLAG     VALUE WORST THRESH TYPE      UPDATED  WHEN_FAILED RAW_VALUE
  1 Raw_Read_Error_Rate     0x000f   078   047   044    Pre-fail  Always       -       72754870
  3 Spin_Up_Time            0x0003   099   091   000    Pre-fail  Always       -       0
  4 Start_Stop_Count        0x0032   100   100   020    Old_age   Always       -       183
  5 Reallocated_Sector_Ct   0x0033   082   082   036    Pre-fail  Always       -       389
  7 Seek_Error_Rate         0x000f   076   060   030    Pre-fail  Always       -       13042155971
  9 Power_On_Hours          0x0032   047   047   000    Old_age   Always       -       46843
 10 Spin_Retry_Count        0x0013   100   100   097    Pre-fail  Always       -       0
 12 Power_Cycle_Count       0x0032   100   037   020    Old_age   Always       -       136
184 End-to-End_Error        0x0032   100   100   099    Old_age   Always       -       0
187 Reported_Uncorrect      0x0032   001   001   000    Old_age   Always       -       507
188 Command_Timeout         0x0032   100   100   000    Old_age   Always       -       0
189 High_Fly_Writes         0x003a   100   100   000    Old_age   Always       -       0
190 Airflow_Temperature_Cel 0x0022   065   055   045    Old_age   Always       -       35 (Min/Max 33/39)
194 Temperature_Celsius     0x0022   035   045   000    Old_age   Always       -       35 (0 13 0 0 0)
195 Hardware_ECC_Recovered  0x001a   050   041   000    Old_age   Always       -       72754870
197 Current_Pending_Sector  0x0012   100   100   000    Old_age   Always       -       0
198 Offline_Uncorrectable   0x0010   100   100   000    Old_age   Offline      -       0
199 UDMA_CRC_Error_Count    0x003e   200   200   000    Old_age   Always       -       0

2015-08-27追記
使用開始してから2ヵ月経過ですが、その後も ATA bus error が出ることはなく、S.M.A.R.T. の不良セクタ関係のカウンタは、前回（1ヶ月前）から変化なしです。

ntpd を１日止めた場合のズレはどの程度か？

巷で話題の2015年7月1日の閏秒(うるう秒)挿入まで、あと１ヶ月。少し前に、うるう秒対策手法の一つとして、ntpd を止めればいいのではと書いたのですが、実際 ntpd を１日止めた場合に、どのぐらい時刻がズレるのか実験してみました。
外部の NTP サーバから時刻を参照している内部 NTP サーバを止めてみて、下位の NTP クライアントの時刻がどの程度ズレるかを観測しました。




設備の都合上、２サンプルだけですが、だいたい 13 ミリ秒程度という結果になりました。ちなみに、両マシンともに、かなり古く（約10年もの）、上が Pentium4 3.06G (Northwood,FSB533Mhz)、下が PentiumD 950 3.40G (SL95V,C1) 搭載です。
OS は、どちらも CentOS 6 で、ntpd は slew モードで動作させました。

グラフは、munin によるものです。

■関連記事
2012年7月1日の うるう秒 調整時の ntpd の挙動観測データ
うるう秒（閏秒）の際にcronが二重に実行されるかも？という都市伝説（？）について
2015年7月1日の うるう秒 調整時の ntpd の挙動観測データ

CentOS7 の CPU 省電力機能について

先日、古い core2 世代のマシンで、CentOS 7 を動かしたのですが、CPU 温度がやけに高い現象に遭遇しました。

[root@hoge ~]# cat /etc/centos-release
CentOS Linux release 7.1.1503 (Core) 
[root@hoge ~]# uname -a
Linux hoge 3.10.0-229.4.2.el7.x86_64 #1 SMP Wed May 13 10:06:09 UTC 2015 x86_64 x86_64 x86_64 GNU/Linux
[root@hoge ~]# dmidecode -s processor-version
Intel(R) Core(TM)2 CPU         X6800  @ 2.93GHz
[root@hoge ~]# sensors
coretemp-isa-0000
Adapter: ISA adapter
Core 0:       +69.0°C  (high = +86.0°C, crit = +100.0°C)
Core 1:       +69.0°C  (high = +86.0°C, crit = +100.0°C)

これは、もしや省電力機能が働いていないのではと思って見てみると。

[root@hoge ~]# cpupower frequency-info
analyzing CPU 0:
  driver: acpi-cpufreq
  CPUs which run at the same hardware frequency: 0
  CPUs which need to have their frequency coordinated by software: 0
  maximum transition latency: 10.0 us.
  hardware limits: 1.60 GHz - 2.93 GHz
  available frequency steps: 2.93 GHz, 2.13 GHz, 1.60 GHz
  available cpufreq governors: conservative, userspace, powersave, ondemand, performance
  current policy: frequency should be within 1.60 GHz and 2.93 GHz.
                  The governor "performance" may decide which speed to use
                  within this range.
  current CPU frequency is 2.93 GHz (asserted by call to hardware).
  cpufreq stats: 2.93 GHz:100.00%, 2.13 GHz:0.00%, 1.60 GHz:0.00%  (24)
  boost state support:
    Supported: no
    Active: no

確かに常時最高周波数になっているようでした。調べてみると、cpupower.service というものがあり、これが CentOS 7 では、デフォルトでは disable になっているようです。

[root@hoge ~]# systemctl list-unit-files | grep cpupower
cpupower.service                            disabled

というわけで、このサービスを起動したら解決しました。温度下がりました（周波数下がりました）。

[root@hoge ~]# systemctl start cpupower.service
[root@hoge ~]# systemctl status cpupower.service 
cpupower.service - Configure CPU power related settings
   Loaded: loaded (/usr/lib/systemd/system/cpupower.service; enabled)
   Active: active (exited) since Tue 2015-05-26 08:49:07 JST; 21min ago
 Main PID: 22330 (code=exited, status=0/SUCCESS)

May 26 08:49:07 hoge cpupower[22330]: Setting cpu: 0
May 26 08:49:07 hoge cpupower[22330]: Setting cpu: 1
May 26 08:49:07 hoge systemd[1]: Started Configure CPU power related settings.

※しばらく時間を置いて温度を確認

[root@hoge ~]# sensors
coretemp-isa-0000
Adapter: ISA adapter
Core 0:       +59.0°C  (high = +86.0°C, crit = +100.0°C)
Core 1:       +59.0°C  (high = +86.0°C, crit = +100.0°C)

[root@hoge ~]# cpupower frequency-info
analyzing CPU 0:
  driver: acpi-cpufreq
  CPUs which run at the same hardware frequency: 0
  CPUs which need to have their frequency coordinated by software: 0
  maximum transition latency: 10.0 us.
  hardware limits: 1.60 GHz - 2.93 GHz
  available frequency steps: 2.93 GHz, 2.13 GHz, 1.60 GHz
  available cpufreq governors: conservative, userspace, powersave, ondemand, performance
  current policy: frequency should be within 1.60 GHz and 2.93 GHz.
                  The governor "ondemand" may decide which speed to use
                  within this range.
  current CPU frequency is 1.60 GHz (asserted by call to hardware).
  cpufreq stats: 2.93 GHz:63.15%, 2.13 GHz:0.98%, 1.60 GHz:35.87%  (631)
  boost state support:
    Supported: no
    Active: no

なお、最近のマシン（Core i 世代）だと、cpupower.service が起動していなくても、省電力になるようです（つまり、RHEL7/CentOS7 のデフォルトで最適な状態になっている）。
気になる方は、cpupower コマンドや turbostat コマンドで確認してみては。


2016-10-01追記
手持ちの Core i7 (ThinkPad W520) だと、こんな感じ。何もしなくても、デフォルトで良い感じです。

[root@w520 ~]# cat /etc/redhat-release 
CentOS Linux release 7.2.1511 (Core) 
[root@w520 ~]# uname -a
Linux w520 3.10.0-327.36.1.el7.x86_64 #1 SMP Sun Sep 18 13:04:29 UTC 2016 x86_64 x86_64 x86_64 GNU/Linux
[root@w520 ~]# dmidecode -s processor-version
Intel(R) Core(TM) i7-2960XM CPU @ 2.70GHz
[root@w520 ~]# systemctl status cpupower.service
* cpupower.service - Configure CPU power related settings
   Loaded: loaded (/usr/lib/systemd/system/cpupower.service; disabled; vendor preset: disabled)
   Active: inactive (dead)
[root@w520 ~]# sensors coretemp-isa-0000
coretemp-isa-0000
Adapter: ISA adapter
Physical id 0:  +61.0°C  (high = +86.0°C, crit = +100.0°C)
Core 0:         +58.0°C  (high = +86.0°C, crit = +100.0°C)
Core 1:         +58.0°C  (high = +86.0°C, crit = +100.0°C)
Core 2:         +55.0°C  (high = +86.0°C, crit = +100.0°C)
Core 3:         +61.0°C  (high = +86.0°C, crit = +100.0°C)

[root@w520 ~]# cpupower frequency-info
analyzing CPU 0:
  driver: intel_pstate
  CPUs which run at the same hardware frequency: 0
  CPUs which need to have their frequency coordinated by software: 0
  maximum transition latency: 0.97 ms.
  hardware limits: 800 MHz - 3.70 GHz
  available cpufreq governors: performance, powersave
  current policy: frequency should be within 800 MHz and 3.70 GHz.
                  The governor "performance" may decide which speed to use
                  within this range.
  current CPU frequency is 862 MHz (asserted by call to hardware).
  boost state support:
    Supported: yes
    Active: yes
    3400 MHz max turbo 4 active cores
    3400 MHz max turbo 3 active cores
    3600 MHz max turbo 2 active cores
    3700 MHz max turbo 1 active cores

お手軽なベンチマークあれこれ

Linux で、マシン（CPU）の相対性能を比較したい場合に、自分で使っているベンチマークについて、備忘録として書いてみたいと思います。

(1) bashで100万回ループ

[root@hoge ~]# cat /etc/centos-release
CentOS Linux release 7.1.1503 (Core) 
[root@hoge ~]# dmidecode -s processor-version
Intel(R) Core(TM) i7-2960XM CPU @ 2.70GHz
[root@hoge ~]# echo $LANG
ja_JP.UTF-8
[root@hoge ~]# time for ((i=0;++i<1000000;))
> do
> :
> done

real 0m4.035s
user 0m3.857s
sys 0m0.184s

何もインストールする必要がなく、簡単に測定できますが、一つ注意点があります。
なんと！ロケールが影響します。なので、条件を揃えるため、常に LANG=C に設定してから計測したほうが良いかと思います。
次が、同じマシンで LANG=C にした場合の結果です。

[root@hoge ~]# LANG=C
[root@hoge ~]# echo $LANG
C
[root@hoge ~]# time for ((i=0;++i<1000000;))
> do
> :
> done

real 0m3.212s
user 0m3.045s
sys 0m0.171s

ってことは、場合によっては、スクリプトの冒頭で。。。ですね。せこい最適化の前にやることはあるでしょうけど。

(2) sysbench

[root@hoge ~]# sysbench --test=cpu run
sysbench 0.4.12:  multi-threaded system evaluation benchmark

Running the test with following options:
Number of threads: 1

Doing CPU performance benchmark

Threads started!
Done.

Maximum prime number checked in CPU test: 10000


Test execution summary:
    total time:                          9.1036s
    total number of events:              10000
    total time taken by event execution: 9.1029
    per-request statistics:
         min:                                  0.88ms
         avg:                                  0.91ms
         max:                                  1.07ms
         approx.  95 percentile:               0.93ms

Threads fairness:
    events (avg/stddev):           10000.0000/0.00
    execution time (avg/stddev):   9.1029/0.00

このベンチは、EPEL に収録されているので、RHEL/CentOS なら、簡単にインストールできます。操作も簡単です。
テストの種類はいろいろと用意されていますが、--test=cpu と --test=memory をよく使います。簡単なので。

(3) 姫野ベンチ

[root@hoge ~]# ./bmt
mimax = 129 mjmax = 129 mkmax = 257
imax = 128 jmax = 128 kmax =256
 Start rehearsal measurement process.
 Measure the performance in 3 times.

 MFLOPS: 1898.971870 time(s): 0.216599 1.733593e-03

 Now, start the actual measurement process.
 The loop will be excuted in 831 times
 This will take about one minute.
 Wait for a while

 Loop executed for 831 times
 Gosa : 8.213920e-04 
 MFLOPS measured : 1959.001846 cpu : 58.159398
 Score based on Pentium III 600MHz : 23.890266

理研が公開しているベンチマークです。こちらはコンパイルが必要ですが、make 一発なので、容易だと思います。
上の結果は、C, static allocate version M のものです。
C, dynamic allocate version というのも用意されています。下が実行例です。

[root@hoge ~]# ./hime
For example: 
 Grid-size= XS (32x32x64)
     S  (64x64x128)
     M  (128x128x256)
     L  (256x256x512)
     XL (512x512x1024)

Grid-size = M

mimax = 128 mjmax = 128 mkmax = 256
imax = 127 jmax = 127 kmax =255
 Start rehearsal measurement process.
 Measure the performance in 3 times.

 MFLOPS: 322.654502 time(s): 1.249692 1.733593e-03

 Now, start the actual measurement process.
 The loop will be excuted in 144 times
 This will take about one minute.
 Wait for a while

 Loop executed for 144 times
 Gosa : 1.308934e-03 
 MFLOPS measured : 331.831996 cpu : 58.326202
 Score based on Pentium III 600MHz using Fortran 77: 4.046732

(4) memtest86+
これは、ベンチマークが主目的ではないですが、メモリ性能の確認にも使います。

2016-01-17追記
手持ちマシン等のデータを集めてみようと思います。随時追加していくつもり。

CPU	(1) 100万回 ループ	(2) sysbench CPU	(3) 姫野ベンチ bmt	備考
x	y	z	u	v
Pentium 4 3.06GHz	10.2	31.1	415	2002年発表 CentOS6(i686)で計測
Core 2 Duo L7100 1.20GHz	9.5 (107%)	34.0 (91%)	519 (125%)	2007年発表 CentOS7(x86_64)で計測
Pentium D 950 3.40GHz	8.9 (115%)	20.6 (151%)	890 (214%)	2006年Q1
Core 2 X6800 2.93GHz	4.3 (237%)	16.0 (194%)	1025 (247%)	2006年Q3
Core 2 QX6800 2.93GHz	4.3 (237%)	16.0 (194%)	1037 (250%)	2007年Q2
Core i7 620M 2.67GHz	3.7 (276%)	8.7 (359%)	1368 (330%)	2010年Q1
Core i7 2960XM 2.70GHz	3.2 (319%)	9.1 (342%)	2516 (606%)	2011年Q4
Core i5 4670 3.40GHz	2.6 (392%)	8.1 (384%)	2945 (710%)	2013年Q2
Core i7 7500U 2.70GHz	3.4 (300%)	8.3 (374%)	4090 (985%)	2016年Q3 2019.11追記
Core i7 8565U 1.80GHz	1.6 (637%)	6.9 (450%)	7110 (1713%)	2018年Q3 2019.12追記 CentOS8(x86_64)で計測

括弧内％は、Pentium 4 3.06GHz を基準にした性能比です。
また、マルチコアは考慮されていません。
sysbench であれば、コマンドラインオプションとして --num-threads=コア数 を付与すれば、マルチコアを使ったベンチができます。そのうち計測してみたいと思ってます。

2016-02-03追記
sysbench --num-threads=T --test=cpu run を計測した値。

CPU	コア数	スレッド数	sysbench CPU	備考
x	c	T	S	v
Pentium 4 3.06GHz	1	2	25.3	2002年発表
Core 2 Duo L7100 1.20GHz	2	2	20.0 (126%)	2007年
Pentium D 950 3.40GHz	2	2	10.6 (239%)	2006年Q1
Core 2 X6800 2.93GHz	2	2	8.1 (312%)	2006年Q3
Core 2 QX6800 2.93GHz	4	4	4.1 (617%)	2007年Q2
Core i7 620M 2.67GHz	2	4	3.5 (723%)	2010年Q1
Xeon E3-1270 3.40GHz	4	8	1.4 (1807%)	2011年Q2
Core i7 2960XM 2.70GHz	4	8	1.5 (1687%)	2011年Q4
Core i5 4670 3.40GHz	4	4	2.2 (1150%)	2013年Q2
Core i7 7500U 2.70GHz	2	4	2.33 (1086%)	2016年Q3 2019.11追記
Core i7 8565U 1.80GHz	4	8	1.33 (1902%)	2018年Q3 2019.12追記

括弧内％は、Pentium 4 3.06GHz を基準にした性能比です。技術の進歩を感じますね。


■関連記事
Linux 上でメモリ帯域幅をベンチマーク

ファイルシステムの痕跡（メタデータ）をクリアする方法あれこれ（wipefsほか）

Linux で、いろいろとファイルシステムを試す際に、mkfs しようとすると、次のように残存データがあるぞと警告される場合があります。

[root@hoge ~]# cat /etc/centos-release
CentOS Linux release 7.1.1503 (Core)
[root@hoge ~]# uname -a
Linux hoge 3.10.0-229.el7.x86_64 #1 SMP Fri Mar 6 11:36:42 UTC 2015 x86_64 x86_64 x86_64 GNU/Linux
[root@hoge ~]# mkfs.btrfs /dev/sda10
/dev/sda10 appears to contain an existing filesystem (ext4).
Error: Use the -f option to force overwrite.

この例であれば、-f オプションを使えば良いのですが、残存するファイルシステムのシグネーチャを削除するのに wipefs コマンドを利用できます。

[root@hoge ~]# wipefs /dev/sda10    ※オプションを指定しなければ何が入ってるか確認できます
offset               type
----------------------------------------------------------------
0x438                ext4   [filesystem]
                     UUID:  xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx

[root@hoge ~]# grep 0x438 /usr/share/file/magic 
0x438   leshort         0xEF53          Linux
[root@hoge ~]# hexdump -C -s 0x420 -n 48 /dev/sda10
00000420  00 20 00 00 00 20 00 00  00 08 00 00 00 00 00 00  |. ... ..........|
00000430  af 15 38 55 00 00 ff ff  53 ef 01 00 01 00 00 00  |..8U....S.......|
00000440  af 15 38 55 00 00 00 00  00 00 00 00 01 00 00 00  |..8U............|
00000450
[root@hoge ~]# wipefs -a /dev/sda10    ※-a オプションでクリアが実行されます
/dev/sda10: 2 bytes were erased at offset 0x00000438 (ext4): 53 ef

[root@hoge ~]# hexdump -C -s 0x420 -n 48 /dev/sda10
00000420  00 20 00 00 00 20 00 00  00 08 00 00 00 00 00 00  |. ... ..........|
00000430  af 15 38 55 00 00 ff ff  00 00 01 00 01 00 00 00  |..8U............|
00000440  af 15 38 55 00 00 00 00  00 00 00 00 01 00 00 00  |..8U............|
00000450

以下、その他の方法です。

昔から、中身をクリアするなら、次のように dd を使うのが常套ですが、サイズが大きいと時間かかります。

[root@hoge ~]# dd if=/dev/zero of=/dev/sda10 bs=1M

ファイルシステムのシグネーチャは、冒頭にあることが多いので、先頭だけクリアするという方法もあります。

[root@hoge ~]# dd if=/dev/zero of=/dev/sda10 bs=1M count=1

ランダムデータで埋める場合に、/dev/urandom を使うことがありますが、これは遅いので注意したほうがいいです。

[root@hoge ~]# dd if=/dev/urandom of=/dev/sda10 bs=1M

shred コマンドも利用できます。ゼロクリアする場合は、こうです。

[root@hoge ~]# shred -n 0 -z /dev/sda10

shred でランダムデータで埋めるには、こうです。dd で /dev/urandom 使うよりも、全然高速です。

[root@hoge ~]# shred -n 1 /dev/sda10

scrub という shred に似たものもあります。この手のツールは、いろいろありそうに思う。

もしも、TRIM 対応の SSD なら、blkdiscard を使えます。

[root@hoge ~]# blkdiscard /dev/sda10

これは大変便利です。HDD でも使えたらいいのになと思いますが、費用対効果上、HDD に TRIM が実装されるなどということは無いのでしょうね。
2015-09-10追記、少々古い Intel 520 で blkdiscard を使ってみたら消えないようでした（less -f で見たらゴミが見えた）。ところが、もう1回 blkdiscard したらオールゼロになったっぽい（less の出力冒頭しか確認してないので「ぽい」）。後日、検証してみます。520 は「Deterministic read ZEROs after TRIM」機能（hdparm -I の後半で確認できる）が搭載されていないからだろうとは思いましたが。。。

最後になりますが、くれぐれも対象デバイスを取り違えないように、注意しましょう。

1年ぶりに ３つのOSでZFSの性能を比較

前回から、1年経過し ZFS on Linux v0.6.4 がリリースされたので、ふたたび比較を行ってみました。

比較は、
・CentOS 7.1 + ZFS on Linux v0.6.4 (前回は 6.5 + v0.6.2)
・OpenIndiana 151a9 (最近アップデートされないので前回と同じバージョン。Hipster はオンボロらしいし)
・FreeBSD 10.1 (前回は 10.0)
の３つの OS で行いました。マシン環境は次の通り(前回とほぼ同じ)です。３つの OS をマルチブートできるようにしてあります。

・lenovo ThinkPad T510
・CPU Intel Core i7 M620 2.67GHz
・MEM 8GB
・OS ディスク R2021D (Plextor M5M 256GB SSD ２枚によるRAID1)
・ZFS pool (HGST HTS721010A9E630 7200rpm SATA 1TB ＋
　HITACHI HTS725050A9A634 7200rpm SATA 500GB による mirror構成)
　※補足：HGST 1T を 2nd HDD ベイに搭載、HITACHI 500G は eSATA 接続

前回の比較実験で tar の展開と削除を行いましたが、その時に使ったデータ(sda6.tar)が残っていましたので、同じことをやってみました。

root@hoge:~# uname -a
SunOS hoge 5.11 oi_151a9 i86pc i386 i86pc Solaris
root@hoge:~# zpool import tankS
root@hoge:~# zfs get compression tankS/backup
NAME          PROPERTY     VALUE     SOURCE
tankS/backup  compression  off       local
root@hoge:~# cd /tankS/backup
root@hoge:/tankS/backup# ls -l sda6.tar 
-rw-r--r-- 1 root root 10927441920 2013-10-20 22:44 sda6.tar
root@hoge:/tankS/backup# time tar xf sda6.tar 

real    3m12.587s
user    0m4.049s
sys     1m1.394s
root@hoge:/tankS/backup# sync
root@hoge:/tankS/backup# time rm -rf test.restore/

real    0m38.627s
user    0m0.590s
sys     0m8.514s
root@hoge:/tankS/backup# cd
root@hoge:~# zpool export tankS
root@hoge:~# 

root@hoge:~ # uname -a
FreeBSD hoge 10.1-RELEASE-p9 FreeBSD 10.1-RELEASE-p9 #0: Tue Apr  7 01:09:46 UTC 2015     root@amd64-builder.daemonology.net:/usr/obj/usr/src/sys/GENERIC  amd64
root@hoge:~ # bash
[root@hoge ~]# zpool import tankS
[root@hoge ~]# zfs get compression tankS/backup
NAME          PROPERTY     VALUE     SOURCE
tankS/backup  compression  off       local
[root@hoge ~]# cd /tankS/backup/
[root@hoge /tankS/backup]# ls -l sda6.tar 
-rw-r--r--  1 root  wheel  10927441920 Oct 20  2013 sda6.tar
[root@hoge /tankS/backup]# time tar xf sda6.tar 

real    4m54.357s
user    0m5.335s
sys     0m38.711s
[root@hoge /tankS/backup]# sync
[root@hoge /tankS/backup]# time rm -rf test.restore/

real    1m13.057s
user    0m0.326s
sys     0m11.764s
[root@hoge /tankS/backup]# cd
[root@hoge ~]# zpool export tankS
[root@hoge ~]#

[root@hoge ~]# uname -a
Linux hoge 3.10.0-229.1.2.el7.x86_64 #1 SMP Fri Mar 27 03:04:26 UTC 2015 x86_64 x86_64 x86_64 GNU/Linux
[root@hoge ~]# zpool import tankS
[root@hoge ~]# zfs get compression tankS/backup
NAME          PROPERTY     VALUE     SOURCE
tankS/backup  compression  off       local
新しいメールが /var/mail/root にあります
[root@hoge ~]# cd /tankS/backup/
[root@hoge backup]# ls -l sda6.tar 
-rw-r--r-- 1 root root 10927441920 10月 20  2013 sda6.tar
[root@hoge backup]# time tar xf sda6.tar 

real    2m53.018s
user    0m4.177s
sys     1m5.055s
[root@hoge backup]# sync
[root@hoge backup]# time rm -rf test.restore/

real    0m9.799s
user    0m0.200s
sys     0m9.601s
[root@hoge backup]# cd
[root@hoge ~]# zpool export tankS
[root@hoge ~]# 

というわけで、１ユーザのパーソナル利用環境での数値ですし、参考までですが、実験したワークロードにおいては、CentOS (Linux実装) が圧勝な数値になりました。v0.6.2 の時は、削除 (rm) に時間かかってましたが、克服された様子です。開発者の方々に感謝です！

ZFS on Linux 0.6.4 がリリースされたので早速アップデート

ZFS on Linux 0.6.4 がリリースされたので、早速 CentOS 7.1 + v0.6.3 を利用していた環境をアップデートしました。
モジュール作成は、問題なく完了して、zpool へのアクセスにも問題無いようなのですが、1点だけ、dkms の出力がおかしくなりました。

[root@hoge ~]# uname -a
Linux hoge 3.10.0-229.1.2.el7.x86_64 #1 SMP Fri Mar 27 03:04:26 UTC 2015 x86_64 x86_64 x86_64 GNU/Linux
[root@hoge ~]# dkms status
Error! Could not locate dkms.conf file.
File:  does not exist.  ※少々焦りますが。。。

なんだろうかと調べてみますと、、、

[root@hoge ~]# ls -l /var/lib/dkms/spl/
合計 8
drwxr-xr-x 3 root root 4096  4月 11 06:44 0.6.3  ※余計なものが残っている感じ
drwxr-xr-x 3 root root 4096  4月 11 06:55 0.6.4
lrwxrwxrwx 1 root root   38  4月 11 06:55 kernel-3.10.0-229.1.2.el7.x86_64-x86_64 -> 0.6.4/3.10.0-229.1.2.el7.x86_64/x86_64

なので、ゴミと思われるものを削除しました。

[root@hoge ~]# \rm -rf /var/lib/dkms/spl/0.6.3
[root@hoge ~]# \rm -rf /var/lib/dkms/zfs/0.6.3
[root@hoge ~]# dkms status
spl, 0.6.4, 3.10.0-229.1.2.el7.x86_64, x86_64: installed
zfs, 0.6.4, 3.10.0-229.1.2.el7.x86_64, x86_64: installed

はい。これで解決です。スッキリ。

ThinkPad の WiFi の LED を点滅しないようにする

ThinkPad W520 の WiFi の LED ランプについてですが、デュアルブートの Windows 7 では、WiFi ルータに接続後は、LED は点灯したままになるのですが、CentOS 7 の場合は、ディスクのアクセス LED みたいに、アクセス状況に応じて点滅します。気にしなければいいようなものですが、目障りに感じて調べてみたら、ドライバのパラメータで Win7 と同様に点灯したままに変更できました。

[root@hoge ~]# lspci | grep Centrino
03:00.0 Network controller: Intel Corporation Centrino Ultimate-N 6300 (rev 3e)
[root@hoge ~]# ethtool -i wlan0
driver: iwlwifi
version: 3.10.0-229.el7.x86_64
firmware-version: 9.221.4.1 build 25532
bus-info: 0000:03:00.0
supports-statistics: yes
supports-test: no
supports-eeprom-access: no
supports-register-dump: no
supports-priv-flags: no
[root@hoge ~]# iw dev wlan0 link
Connected to a4:2b:8c:xx:xx:xx (on wlan0)
        SSID: NETGEAR32-5G
        freq: 5220
        RX: 6358479 bytes (35447 packets)
        TX: 545450 bytes (2161 packets)
        signal: -33 dBm
        tx bitrate: 450.0 MBit/s MCS 23 40MHz short GI    ※ちなみに、ここで アクセス速度 を確認できる

        bss flags:      short-preamble short-slot-time
        dtim period:    0
        beacon int:     100
[root@hoge ~]# cat /etc/modprobe.d/iwlwifi.conf 
options  iwlwifi  led_mode=1
[root@hoge ~]# cat /sys/module/iwlwifi/parameters/led_mode    ※確認はこちら
1

このように、ドライバのオプション led_mode=1 を設定して、OS 再起動で OK です。

CentOS7 の bash の補完機能は便利なのだが、たまに無効化したい

CentOS 7 の bash は、CentOS 6 までと違って、デフォルトの補完機能が拡充されていて、例えば、systemctl のオプション候補を出したりするときに、大変便利です。

[root@hoge ~]# systemctl list-  ※ここまで打って、TAB を押下すればオプション候補一覧が表示される
list-dependencies  list-jobs          list-sockets       list-unit-files    list-units         
[root@hoge ~]# systemctl list-

ところが、例えば、initramfs を再作成するような場面で、、、

[root@hoge ~]# dracut -f /boot/initr  ※CentOS 6 以下だと、ここで TAB を押下すれば候補が出たんだけど

ファイル一覧を出して欲しいのですが、CentOS 7 の場合は、デフォルト設定では候補が出なくなってしまっています。
このケースに限ると、alias の回避と同様に、先頭にバックスラッシュをつければ良いようです。本日、気が付いた。

[root@hoge ~]# \dracut -f /boot/initr
initramfs-0-rescue-17561ed66271e2f6923ff3c901624b3a.img
initramfs-3.10.0-123.20.1.el7.x86_64.img
initramfs-3.10.0-123.20.1.el7.x86_64kdump.img
initrd-plymouth.img
[root@hoge ~]# \dracut -f /boot/initr

しかしながら、次のような場合は、NG のようです。

[root@hoge ~]# \dd if=/dev/uran  ※/dev/urandom を出したいが、ここで TAB を押下しても補完してくれない

どうにか出来無いもんでしょうかね。

[root@hoge ~]# \dd if= /dev/uran  ※このように = の後ろに1スペース入れると TAB 補完が動くのだが、戻るのが面倒