2015年12月26日土曜日

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

ちょうど180Gくらいの SSD を用立てたいと思っていたところ、この日、Intel SSD 710 の特価情報を目にして、一目散に秋葉原へ・・・。危うく売り切れのところ、なんと最後の1個をゲットできました。
手持ちの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

2015年11月7日土曜日

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

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

2015年10月12日月曜日

中古 HDD の初期確認、2個目(2015年10月)

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

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

そんな訳で、一種の賭けでしたが、認識はされました(さすがに認識もされない個体は売ってないですかね)ので、最初に 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
某ショップの説明通り、そこそこのキズモノのようですが、1個目と見比べると 188 Command_Timeout が多発しているのが特に気になります。
運用時間(9 Power_On_Hours)は、
[root@hoge ~]# echo "26851 / 24 / 365" | bc -l
3.06518264840182648401
ほぼ3年です。

次は 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

1個目は、Write cache が disabled でしたが、2個目は、特に操作しなくても WriteCache=enabled でした。
それと、ファームウェアのバージョンが異りました。1個目は 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 で冗長化(4台でRAIDZ)して使うので、全セクタ検査などせずに、そのまま投入です。ただ今、書き込みテスト中。

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

2017-04-21追記
2017-04-11 に、見事に壊れました。擦れてような異音がして、冷却ファンのどれかが壊れかかっているのかと、耳を近づけてもどこから音がしているか、なかなかわからないもんですね。zpool status をみて、この HDD が壊れたことがわかりました。いわゆるヘッドクラッシュなのか?もの凄い音でした。
週に1回、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 を注文しました。某ショップで★5つでしたが、さてどんなもんでしょうね。

2015年9月25日金曜日

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 も同様ですよ~。もちろんです。

2015年9月13日日曜日

eggcups の暴走

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

2015年8月23日日曜日

ThinkPad W520 で SSD 2台で IRST(インテルラピッドストレージテクノロジー)RAID1

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

ぴったり1年前に書いたのですが、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 x2台を使用しています。この SSD は、充分に速いのに加えて、温度があまり上がらない(今みたら 1st が 38℃、2nd が 34℃)のが魅力かなと思います。現在、カカクコムにて満足度ランキング1位だったりもします。眉唾(話し半分)ととらえるべきと思いますが、それでも自分の使ってる SSD が1位なのは気分よいものですね。
個人的には、性能なら Crucial MX200 のほうが上かと思います(別のマシンで使ってるもので)。しかし、MX200 の順位は10位なようです。

最後に、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の場合は1ストリームでは1ドライブ分しか出ませんので、付記しておきます。ZFS on LinuxのmirrorでもREADを複数ドライブに分散させてくれるし、md RAID1もオプションでそういう機能があってもいいのかも(難しいのかもですが)。それと、最新のバージョンを確かめていませんが、Btrfs RAID1の場合も1ストリームだと同時には1ドライブにしかREADを出さないようでした(2年程度前の記憶)。


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

2015年7月1日水曜日

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 モードで1秒が補正されるまでのデータを残しておきます。
まず、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
実際は、上位サーバは4つ指定してあり、そのうちの1つについて 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
※データ採取準備をして1度マシンを再起動した
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からメッセージは出なかった
というわけで、めでたし、めでたし。

2015年6月17日水曜日

うるう秒(閏秒)の際に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 を1日止めた場合のズレはどの程度か?

2015年6月15日月曜日

中古 HDD の初期確認

記憶する限り初めて、中古 HDD を購入した(中古 SSD は買ったことありましたが)のですが、Linux 上での初期確認ポイントについて、備忘録です。
CentOS 7.1 で操作しています。
■関連記事 中古 HDD の初期確認、2個目(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 を意味するそうです。というわけで6歳でした。

そして、不良セクタ関係の項目(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追記
その後、2週間経ちましたが、ひとまずは安定した様子で、エラーが出なくなりました。

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ヶ月前)から変化なしです。

2015年6月2日火曜日

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

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




設備の都合上、2サンプルだけですが、だいたい 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 の挙動観測データ

2015年5月30日土曜日

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

2015年5月27日水曜日

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

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年発表
Core 2 Duo L7100 1.20GHz 9.5 (107%) 34.0 (91%) 519 (125%) 2007年
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
括弧内%は、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
括弧内%は、Pentium 4 3.06GHz を基準にした性能比です。技術の進歩を感じますね。

2015年4月23日木曜日

ファイルシステムの痕跡(メタデータ)をクリアする方法あれこれ(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 の後半で確認できる)が搭載されていないからだろうとは思いましたが。。。

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

2015年4月17日金曜日

1年ぶりに 3つの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)
の3つの OS で行いました。マシン環境は次の通り(前回とほぼ同じ)です。3つの OS をマルチブートできるようにしてあります。

・lenovo ThinkPad T510
・CPU Intel Core i7 M620 2.67GHz
・MEM 8GB
・OS ディスク R2021D
(Plextor M5M 256GB SSD 2枚による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 ~]# 
というわけで、1ユーザのパーソナル利用環境での数値ですし、参考までですが、実験したワークロードにおいては、CentOS (Linux実装) が圧勝な数値になりました。v0.6.2 の時は、削除 (rm) に時間かかってましたが、克服された様子です。開発者の方々に感謝です!

2015年4月11日土曜日

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
はい。これで解決です。スッキリ。

2015年3月23日月曜日

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 です。

2015年3月8日日曜日

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 補完が動くのだが、戻るのが面倒

2015年2月15日日曜日

ZFS on Linux の snapshot 運用スクリプト例

legacy なファイルサーバ (ext3+sambaを利用) のバックアップを、rsync を使って、ZFS on Linux 上に採取しているのですが、ZFS の snapshot 機能を使うことで、例えて言うと「タイムマシン」のような効果を得ています。

具体的には、毎日1回 rsync で、ファイルサーバの内容を ZFS 上へバックアップして、その後、その ZFS 領域に対して1日1回の snapshot を採取しています。これで、間違ってファイルを消したりした場合に、snapshot を過去に辿って参照することで、間違って消してしまう以前の出来るだけ最新状態のファイルを復活させるということが可能になります。

ただ、1日1回の snapshot とはいえ、日々繰り返せば1年では 365 もの snapshot が残ることになり、そのファイルサーバの更新頻度から考えると過剰に思えました。そこで、次のようなアルゴリズムで、古い snapshot を削減するようにしました。

■わたしが考えた古い snapshot を削除するゴルゴリズム
(1) 先月の snapshot までは、1日1つを維持する。
(2) 先々月の snapshot は、奇数日だけ残して半減させる。
(3) 3ヶ月めに入ったら、1日・7日・13日・19日・25日を残して、その他を削除する。
(4) 4ヶ月めに入ったら、13日の snapshot だけを残す。
このような条件で過去の snapshot を削除することで、直近なら1日の粒度で、古くは1ヶ月に1つの粒度の snapshot を残すようにしました。

以下、そのスクリプトを掲載したいと思います。同じようなことをしたいと考える人が居るかなと思いますし、一から書くのも骨なので、ご参考まで。

まず、平凡ですが、スナップショットを採るスクリプトです。
#!/bin/bash
#
# Name: my-zfs-snapshot
#
# Authors: staka <blue3waters at gmail dot com>
#
# This file is subject to the GNU General Public License.
# It comes with NO WARRANTY.
#

TARGET_ZFS=tankX/fsvdata  ※対象を指定

TIME_STAMP=`date +%F-%H%M`

/sbin/zfs snapshot ${TARGET_ZFS}@${TIME_STAMP}

exit $?
次に、古いスナップショットを削除するスクリプトです。
#!/bin/bash
#
# Name: my-zfs-destroy-snapshot
#
# Authors: staka <blue3waters at gmail dot com>
#
# This file is subject to the GNU General Public License.
# It comes with NO WARRANTY.
#

PATH=/sbin:$PATH

TARGET_ZFS=tankX/fsvdata  ※対象を指定

B2_MONTH=`date -d "$(date +%Y-%m-15) -2 month" +%Y-%m`
B3_MONTH=`date -d "$(date +%Y-%m-15) -3 month" +%Y-%m`
B4_MONTH=`date -d "$(date +%Y-%m-15) -4 month" +%Y-%m`
B4_FLAG13=

DESTROY_LIST=

for SNAPSHOT in `zfs list -H -t snapshot -o name`
do
    DESTROY=no

    [[ $SNAPSHOT != "${TARGET_ZFS}@"* ]] && continue

    if [[ $SNAPSHOT = *"${B2_MONTH}-"* ]] ; then
        case $SNAPSHOT in
        *"${B2_MONTH}-"?[02468]-*)
            DESTROY=yes
            ;;
        esac
    fi

    if [[ $SNAPSHOT = *"${B3_MONTH}-"* ]] ; then
        case $SNAPSHOT in
        *"${B3_MONTH}-01-"*)
            ;;
        *"${B3_MONTH}-07-"*)
            ;;
        *"${B3_MONTH}-13-"*)
            ;;
        *"${B3_MONTH}-19-"*)
            ;;
        *"${B3_MONTH}-25-"*)
            ;;
        *)
            DESTROY=yes
            ;;
        esac
    fi

    if [[ $SNAPSHOT = *"${B4_MONTH}-"* ]] ; then
        case $SNAPSHOT in
        *"${B4_MONTH}-13-"*)
            B4_FLAG13=yes
            ;;
        *)
            DESTROY=yes
            ;;
        esac
    fi

    if [ $DESTROY = "yes" ] ; then
        DESTROY_LIST="$DESTROY_LIST $SNAPSHOT"
    fi
done

for SNAPSHOT in $DESTROY_LIST
do
    if [[ $SNAPSHOT = *"${B4_MONTH}-"* ]] && [ "$B4_FLAG13" != "yes" ] ; then
        continue
    fi
    zfs destroy $SNAPSHOT
done

exit 0
この2つのスクリプトを cron で1日1回実行するようにスケジュールしています。

これを書いて使い始めたのが 2013年11月 なので、1年3ヵ月ほど使っています。
この間、1度だけ、復活させたいファイル(たぶん誤操作で、いつの間にか消えていた)があり、恩恵を得られました。非常に助かりました。

このスクリプトの中で肝となる部分は、先々月(B2_MONTH)などを、どうやって求めるか?ですが、それについては、次の記事も参照ください。
■関連記事
date コマンドで先月を求める方法

2015年1月25日日曜日

RHEL7 / CentOS7 で ext4 を使ってみる(16T 越えの確認)

RHEL7 / CentOS7 では、デフォルトのファイルシステムが XFS になっていて、しきりと推奨/宣伝されているように感じますが、個人的には、16T を越える領域を扱うのでもなければ、ext4 を利用してもよいのではと思います。慣れている&(自分の利用範囲で)XFS より実績があるので。
特に、OS 領域(大抵の場合 20G〜50G 程度で済むのではと思う)は ext4 でもいいのではと思います。16T を越えるデータ領域に XFS を利用するので、OS 領域も全て XFS で統一するという考え方もあろうかと思いますが。。。

さて、最近は ext4 も拡張されており、16T 越えも可能なはずなので、試してみました。ただし、16T ものディスクを所有していませんので、ZFS on Linux の機能(sparse ZVOL)を利用しました。
[root@hoge ~]# zfs create -s -V 200T tankS/ext4_test    ※ZFS のチカラを借りて、200T の領域を作成
[root@hoge ~]# mkfs -t ext4 /dev/tankS/ext4_test        ※ext4 ファイルシステム作成
mke2fs 1.42.9 (28-Dec-2013)
Discarding device blocks:  8193142done                            
Filesystem label=
OS type: Linux
Block size=4096 (log=2)
Fragment size=4096 (log=2)
Stride=2 blocks, Stripe width=2 blocks
3355443200 inodes, 53687091200 blocks
2684354560 blocks (5.00%) reserved for the super user
First data block=0
1638400 block groups
32768 blocks per group, 32768 fragments per group
2048 inodes per group
Superblock backups stored on blocks: 
 32768, 98304, 163840, 229376, 294912, 819200, 884736, 1605632, 2654208, 
 4096000, 7962624, 11239424, 20480000, 23887872, 71663616, 78675968, 
 102400000, 214990848, 512000000, 550731776, 644972544, 1934917632, 
 2560000000, 3855122432, 5804752896, 12800000000, 17414258688, 
 26985857024, 52242776064

Allocating group tables: done                            
Writing inode tables: done                            
Creating journal (32768 blocks): done
Writing superblocks and filesystem accounting information: done

[root@hoge ~]# mount /dev/tankS/ext4_test /mnt_temp
[root@hoge ~]# df -Th /mnt_temp
Filesystem     Type  Size  Used Avail Use% Mounted on
/dev/zd0       ext4  200T   20K  190T   1% /mnt_temp
[root@hoge ~]# dd if=/dev/zero of=/mnt_temp/test.dd bs=1M count=500 conv=fsync
500+0 records in
500+0 records out
524288000 bytes (524 MB) copied, 28.1099 s, 18.7 MB/s
[root@hoge ~]# df -Th /mnt_temp
Filesystem     Type  Size  Used Avail Use% Mounted on
/dev/zd0       ext4  200T  501M  190T   1% /mnt_temp
200T ほど試してみましたが、ちゃんとマウントして利用できました。なお、下地になっている ZFS プールのディスクが USB 2.0 接続になっており、dd の書き込みが遅いのはそのせいです。これなら難無く使えそうに思われるかもしれませんが、上記操作例の中で、mkfs が5分ほどかかっています。USB 2.0 の影響もあるだろうと思いますが、XFS ならば、もっと速いだろうと思います。
それから、てっきり ext4 の 16T 越え機能拡張は、ブロックサイズを 4K よりさらに大きくすることで達成されているものと勘違い/誤認識していましたが、mkfs の出力にもあるとおり、ブロックサイズは 4K のままのようです。ただし、作成された ext4 には、新しい feature flag である 64bit が付与されます。
[root@hoge ~]# tune2fs -l /dev/tankS/ext4_test
...
Filesystem features:      has_journal ext_attr resize_inode dir_index filetype needs_recovery extent 64bit flex_bg sparse_super large_file huge_file uninit_bg dir_nlink extra_isize
...
この 64bit フラグは、デフォルトになっており、16T 未満の場合でも付与されてしまうので、RHEL6 / CentOS6 でもマウントしたい領域を作る場合は、注意必要と思われます。
次は、/etc/mke2fs.conf から抜粋です。
...
[fs_types]
 ext3 = {
  features = has_journal
 }
 ext4 = {
  features = has_journal,extent,huge_file,flex_bg,uninit_bg,dir_nlink,extra_isize,64bit
  inode_size = 256
 }
...
もし、64bit フラグを付与したくないならば、次のようにすれば良いです。
[root@hoge ~]# mkfs.ext4 -O ^64bit /dev/sdXXX

ただし、この 64bit フラグは、後から追加することはできないようです。
[root@hoge ~]# tune2fs -O 64bit /dev/tankS/ext4_test
tune2fs 1.42.9 (28-Dec-2013)
Setting filesystem feature '64bit' not supported.
64bit フラグなしで 15T から 17T への resize2fs も試してみましたが、NG です。
[root@hoge ~]# zfs get volsize tankS/ext4_test
NAME             PROPERTY  VALUE    SOURCE
tankS/ext4_test  volsize   17T      local    ※あとから zfs set volsize で 15T から 17T にサイズを拡張
[root@hoge ~]# df -Th /mnt_temp
Filesystem     Type  Size  Used Avail Use% Mounted on
/dev/zd0       ext4   15T  6.3M   15T   1% /mnt_temp    ※15T の段階で mkfs して mount しておいた
[root@hoge ~]# resize2fs /dev/tankS/ext4_test
resize2fs 1.42.9 (28-Dec-2013)
resize2fs: New size too large to be expressed in 32 bits    ※NG です。予想通りですが

2015-01-28追記
もしも、許される&自分で面倒みることができるならば ZFS が最強 (End-to-Endチェックサム+RAID機能によるデータ破損検出と自動修復・・・抜群の安心感が得られるし実際に助かったことがあるスナップショット・・・こまめに採ることでファイルサーバを「Time Capsule」化できるZVOL・・・これ意外と重宝する透過圧縮・・・ソース置き場や大容量テキスト解析に便利重複排除・・・効果発揮できる局面が限定されますが) だろうと思っていますが、商用利用のサーバだと難しい(ディストリビュータや商用サポートサービスなどの後ろ盾がないと許されない)かと思います。その場合、現在のところは、やっぱり無難な ext4 が、良いんじゃないのと思うわけです。


2015-01-28追記
XFS よりも ext4 のほうがネット上の情報(ノウハウ)も多いに違いないと思いましたが、ためしに Google 検索で、キーワード「Linux XFS」と「Linux ext4」を試してみると、やはり ext4 のほうが2倍程度のヒット数となりました。参考メモ。
人気ブログランキングへ にほんブログ村 IT技術ブログへ