☰

新硬盘出现非特定内核错误，是硬盘出现故障吗？

tag-icon • tag-icon linux hard-drive raid smart
新硬盘出现非特定内核错误，是硬盘出现故障吗？

我在一台带有 RAID5 阵列（使用 mdadm 软件 RAID）的服务器上运行 CentOS 7.7.1908。该阵列由四个 4 TB 驱动器组成。我最近用全新的 WD Red 驱动器替换了一些驱动器。一周多的时间里一切都很顺利，直到一天早上我醒来时发现一个“故障”事件。似乎其中一个新驱动器（/dev/sda）已被标记为故障并从阵列中掉线。

我运行了简短的 SMART 自检，驱动器检查结果正常。驱动器的 SMART 日志中没有记录其他错误，因此我将其重新添加到阵列中。阵列成功重新同步，一切正常。但由于没有任何事情导致失败事件，我担心驱动器可能有问题。

以下是驱动器从阵列中“发生故障”时的系统日志消息：

Apr  9 03:34:11 server kernel: sd 0:0:0:0: [sda] tag#0 FAILED Result: hostbyte=DID_OK driverbyte=DRIVER_SENSE
Apr  9 03:34:11 server kernel: sd 0:0:0:0: [sda] tag#0 Sense Key : Aborted Command [current]
Apr  9 03:34:11 server kernel: sd 0:0:0:0: [sda] tag#0 Add. Sense: No additional sense information
Apr  9 03:34:11 server kernel: sd 0:0:0:0: [sda] tag#0 CDB: Synchronize Cache(10) 35 00 00 00 00 00 00 00 00 00
Apr  9 03:34:11 server kernel: blk_update_request: I/O error, dev sda, sector 2056
Apr  9 03:34:11 server kernel: md: super_written gets error=-5, uptodate=0
Apr  9 03:34:11 server kernel: md/raid:md127: Disk failure on sda1, disabling device.#012md/raid:md127: Operation continuing on 3 devices.
Apr  9 03:38:50 server kernel: sd 0:0:0:0: [sda] tag#0 FAILED Result: hostbyte=DID_OK driverbyte=DRIVER_SENSE
Apr  9 03:38:50 server kernel: sd 0:0:0:0: [sda] tag#0 Sense Key : Aborted Command [current]
Apr  9 03:38:50 server kernel: sd 0:0:0:0: [sda] tag#0 Add. Sense: No additional sense information
Apr  9 03:38:50 server kernel: sd 0:0:0:0: [sda] tag#0 CDB: Synchronize Cache(10) 35 00 00 00 00 00 00 00 00 00
Apr  9 03:38:50 server kernel: blk_update_request: I/O error, dev sda, sector 0
Apr  9 03:38:51 server kernel: mpt2sas_cm0: log_info(0x31110610): originator(PL), code(0x11), sub_code(0x0610)

由于错误信息显示“没有其他感知信息”，因此很难弄清楚到底发生了什么。不过，在重新同步完成后，我决定对驱动器运行扩展的 SMART 测试。我昨天下午开始运行，一切进展顺利……直到今天早上我醒来。

显然，它整晚都处于“测试剩余 10%”的状态，所以我猜想肯定是哪里出了问题。我还注意到，此驱动器的 SMART 信息表明“延长自检例程建议轮询时间”为 497 分钟，而阵列中其他驱动器（品牌和型号相同）的轮询时间约​​为 205 分钟。

所以……也许这是一个有缺陷的驱动器，其中的错误 SMART 未记录？或者还有其他事情发生？以前有人见过这样的事情吗？任何帮助都将不胜感激。谢谢！

更新：更多信息

根据要求，以下是相关驱动器的 smartctl 输出

[user@localhost]~% sudo smartctl -a /dev/sda
smartctl 7.0 2018-12-30 r4883 [x86_64-linux-3.10.0-1062.18.1.el7.x86_64] (local build)
Copyright (C) 2002-18, Bruce Allen, Christian Franke, www.smartmontools.org

=== START OF INFORMATION SECTION ===
Device Model:     WDC WD40EFAX-68JH4N0
Serial Number:    WD-XXXXXXXXXXXX
LU WWN Device Id: 5 0014ee 2bce22f9d
Firmware Version: 82.00A82
User Capacity:    4,000,787,030,016 bytes [4.00 TB]
Sector Sizes:     512 bytes logical, 4096 bytes physical
Rotation Rate:    5400 rpm
Form Factor:      3.5 inches
Device is:        Not in smartctl database [for details use: -P showall]
ATA Version is:   ACS-3 T13/2161-D revision 5
SATA Version is:  SATA 3.1, 6.0 Gb/s (current: 6.0 Gb/s)
Local Time is:    Fri Apr 10 11:02:15 2020 CDT
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:  (0x00) Offline data collection activity
                                        was never started.
                                        Auto Offline Data Collection: Disabled.
Self-test execution status:      ( 241) Self-test routine in progress...
                                        10% of test remaining.
Total time to complete Offline
data collection:                (23324) 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:        (   2) minutes.
Extended self-test routine
recommended polling time:        ( 497) minutes.
Conveyance self-test routine
recommended polling time:        (   2) minutes.
SCT capabilities:              (0x3039) SCT Status supported.
                                        SCT Error Recovery Control supported.
                                        SCT Feature Control supported.
                                        SCT Data Table supported.

SMART Attributes Data Structure revision number: 16
Vendor Specific SMART Attributes with Thresholds:
ID# ATTRIBUTE_NAME          FLAG     VALUE WORST THRESH TYPE      UPDATED  WHEN_FAILED RAW_VALUE
  1 Raw_Read_Error_Rate     0x002f   200   200   051    Pre-fail  Always       -       0
  3 Spin_Up_Time            0x0027   100   253   021    Pre-fail  Always       -       0
  4 Start_Stop_Count        0x0032   100   100   000    Old_age   Always       -       4
  5 Reallocated_Sector_Ct   0x0033   200   200   140    Pre-fail  Always       -       0
  7 Seek_Error_Rate         0x002e   200   200   000    Old_age   Always       -       0
  9 Power_On_Hours          0x0032   100   100   000    Old_age   Always       -       205
 10 Spin_Retry_Count        0x0032   100   253   000    Old_age   Always       -       0
 11 Calibration_Retry_Count 0x0032   100   253   000    Old_age   Always       -       0
 12 Power_Cycle_Count       0x0032   100   100   000    Old_age   Always       -       4
192 Power-Off_Retract_Count 0x0032   200   200   000    Old_age   Always       -       2
193 Load_Cycle_Count        0x0032   200   200   000    Old_age   Always       -       19
194 Temperature_Celsius     0x0022   114   107   000    Old_age   Always       -       33
196 Reallocated_Event_Count 0x0032   200   200   000    Old_age   Always       -       0
197 Current_Pending_Sector  0x0032   200   200   000    Old_age   Always       -       0
198 Offline_Uncorrectable   0x0030   100   253   000    Old_age   Offline      -       0
199 UDMA_CRC_Error_Count    0x0032   200   200   000    Old_age   Always       -       0
200 Multi_Zone_Error_Rate   0x0008   100   253   000    Old_age   Offline      -       0

SMART Error Log Version: 1
No Errors Logged

SMART Self-test log structure revision number 1
Num  Test_Description    Status                  Remaining  LifeTime(hours)  LBA_of_first_error
# 1  Short offline       Completed without error       00%       177         -
# 2  Extended offline    Interrupted (host reset)      10%       108         -
# 3  Short offline       Completed without error       00%         0         -
# 4  Conveyance offline  Completed without error       00%         0         -

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.

更新：更多信息

根据@dirkt 的下一个建议，我尝试读取原始系统日志错误中指出的扇区：

[user@localhost]~% sudo dd bs=512 if=/dev/sda1 of=./sector0-sda1.txt skip=0 count=1
1+0 records in
1+0 records out
512 bytes (512 B) copied, 0.00244528 s, 209 kB/s

[user@localhost]~% sudo dd bs=512 if=/dev/sda1 of=./sector2056-sda1.txt skip=2056 count=1
1+0 records in
1+0 records out
512 bytes (512 B) copied, 0.00281374 s, 182 kB/s

这不是我非常熟悉的东西，但我认为这意味着读取成功？扇区 0 的文件是空的，扇区 2056 的文件包含一些乱码。我应该尝试写入它们吗？编辑：我可能应该补充一下——读取后 SMART 信息保持不变。没有记录任何错误，扩展测试仍处于“剩余 10%”状态。

更新 #3

由于看起来我可以读取这些扇区，所以它们似乎没问题。读取它们（如上所述）后，SMART 日志中没有更新：

[user@localhost]~% sudo smartctl -a /dev/sda
...
Vendor Specific SMART Attributes with Thresholds:
ID# ATTRIBUTE_NAME          FLAG     VALUE WORST THRESH TYPE      UPDATED  WHEN_FAILED RAW_VALUE
  1 Raw_Read_Error_Rate     0x002f   200   200   051    Pre-fail  Always       -       0
  3 Spin_Up_Time            0x0027   100   253   021    Pre-fail  Always       -       0
  4 Start_Stop_Count        0x0032   100   100   000    Old_age   Always       -       4
  5 Reallocated_Sector_Ct   0x0033   200   200   140    Pre-fail  Always       -       0
  7 Seek_Error_Rate         0x002e   200   200   000    Old_age   Always       -       0
  9 Power_On_Hours          0x0032   100   100   000    Old_age   Always       -       252
 10 Spin_Retry_Count        0x0032   100   253   000    Old_age   Always       -       0
 11 Calibration_Retry_Count 0x0032   100   253   000    Old_age   Always       -       0
 12 Power_Cycle_Count       0x0032   100   100   000    Old_age   Always       -       4
192 Power-Off_Retract_Count 0x0032   200   200   000    Old_age   Always       -       2
193 Load_Cycle_Count        0x0032   200   200   000    Old_age   Always       -       19
194 Temperature_Celsius     0x0022   111   107   000    Old_age   Always       -       36
196 Reallocated_Event_Count 0x0032   200   200   000    Old_age   Always       -       0
197 Current_Pending_Sector  0x0032   200   200   000    Old_age   Always       -       0
198 Offline_Uncorrectable   0x0030   100   253   000    Old_age   Offline      -       0
199 UDMA_CRC_Error_Count    0x0032   200   200   000    Old_age   Always       -       0
200 Multi_Zone_Error_Rate   0x0008   100   253   000    Old_age   Offline      -       0

SMART Error Log Version: 1
No Errors Logged

所以我将驱动器重新添加到阵列中。重新同步成功，错误尚未再次出现。所以也许没问题？

[user@localhost]~% cat /proc/mdstat
Personalities : [raid6] [raid5] [raid4]
md127 : active raid5 sdb1[7] sdc1[5] sdd1[4] sda1[6]
      11721047040 blocks super 1.2 level 5, 512k chunk, algorithm 2 [4/4] [UUUU]

我注意到一件新事情：根据下面关于扩展自检的说明，我尝试通过指定 进行选择性自检smartctl -t select,0-max /dev/sdX。根据下面的解决方法，这应该模拟一个长时间的测试，但会提供更详细的进度指示器。我对每个驱动器都运行了这个选择性测试，因为长时间测试在每个驱动器上停留在 10% 的剩余时间长达数天。对于阵列中的 3 个“良好”驱动器，选择性测试在合理的时间内（几个小时，但不到一天）无错误地完成。对“可疑”驱动器（/dev/sda）的选择性测试花费的时间要长得多。它像以前一样显示剩余 10%，但进度指示器更有用：

SMART Selective self-test log data structure revision number 1
 SPAN  MIN_LBA     MAX_LBA  CURRENT_TEST_STATUS
    1        0  7814037167  Self_test_in_progress [10% left] (5010947864-5011013399)
    2        0           0  Not_testing
    3        0           0  Not_testing
    4        0           0  Not_testing
    5        0           0  Not_testing

此时它已经运行了大约 12 个小时。它运行得非常慢（尤其是与其他驱动器相比），但似乎仍在进步。当它完成时我会发布更新（如果它完成的话）...编辑：选择性自检终于完成了，并且没有错误。所以我想这意味着一切都很好？

更新 #4：回归

过去一周，一切都运行良好。不幸的是，今天下午同一块驱动器再次从阵列中掉线。系统日志中出现了相同的错误：

Apr 14 18:07:38 xenon kernel: sd 0:0:0:0: [sda] tag#0 FAILED Result: hostbyte=DID_OK driverbyte=DRIVER_SENSE
Apr 14 18:07:38 xenon kernel: sd 0:0:0:0: [sda] tag#0 Sense Key : Aborted Command [current]
Apr 14 18:07:38 xenon kernel: sd 0:0:0:0: [sda] tag#0 Add. Sense: No additional sense information
Apr 14 18:07:38 xenon kernel: sd 0:0:0:0: [sda] tag#0 CDB: Synchronize Cache(10) 35 00 00 00 00 00 00 00 00 00
Apr 14 18:07:38 xenon kernel: blk_update_request: I/O error, dev sda, sector 2056
Apr 14 18:07:38 xenon kernel: md: super_written gets error=-5, uptodate=0
Apr 14 18:07:38 xenon kernel: md/raid:md127: Disk failure on sda1, disabling device.#012md/raid:md127: Operation continuing on 3 devices.
Apr 14 18:08:50 xenon kernel: sd 0:0:0:0: [sda] tag#0 FAILED Result: hostbyte=DID_OK driverbyte=DRIVER_SENSE
Apr 14 18:08:50 xenon kernel: sd 0:0:0:0: [sda] tag#0 Sense Key : Aborted Command [current]
Apr 14 18:08:50 xenon kernel: sd 0:0:0:0: [sda] tag#0 Add. Sense: No additional sense information
Apr 14 18:08:50 xenon kernel: sd 0:0:0:0: [sda] tag#0 CDB: Synchronize Cache(10) 35 00 00 00 00 00 00 00 00 00
Apr 14 18:08:50 xenon kernel: blk_update_request: I/O error, dev sda, sector 0
Apr 14 18:08:51 xenon kernel: mpt2sas_cm0: log_info(0x31110610): originator(PL), code(0x11), sub_code(0x0610)

出现这些错误后，我收到了来自 mdadm 的通知：

[user@localhost]/var/log# cat /proc/mdstat
Personalities : [raid6] [raid5] [raid4]
md127 : active raid5 sdb1[7] sdc1[5] sdd1[4] sda1[6](F)
      11721047040 blocks super 1.2 level 5, 512k chunk, algorithm 2 [4/3] [_UUU]

unused devices: <none>

我已经开始进行选择性 SMART 测试/dev/sda，但是由于之前的测试均未发现任何问题，所以我并不乐观。有什么方法可以判断这是驱动器出现故障还是驱动器控制器出现故障？由于两次都是同一个驱动器掉线，我倾向于认为是驱动器的问题，但有人知道如何解读日志中的错误吗？很高兴提供更多信息。谢谢！

更新 #5：传奇仍在继续

对于那些关注此事的人来说，以下是最新消息：

  1. 因为我有一个旧的机箱，所以我把原来的 2 TB 驱动器放进去，并快速创建了一个新的“备用”阵列。
  2. 我将 4 TB 驱动器阵列的内容复制到备用阵列。
  3. 我删除了原始阵列并使用 4 TB 驱动器创建了一个新的 RAID10 阵列（基于各种搜索，似乎具有大型驱动器（特别是 4 个或更多驱动器）的 RAID5 实际上并不能提供出色的性能或冗余）。
  4. 新阵列已成功初始化。我将原始数据从 2 TB 驱动器备用阵列复制到新的 4 TB 驱动器 RAID10 阵列。
  5. 根据下面与 @dirkt（顺便说一句，他很棒）的讨论，我已通过 禁用每个 4TB 驱动器上的 NCQ echo 1 > /sys/block/sdX/device/queue_depth。这是为了降低阵列的复杂性/并行性，也因为有些讨论表明 NCQ 实际上可能不利于 RAID 性能。我让阵列使用此临时修复程序运行，看看它是否能解决问题。
  6. 根据 Mike Uchima 在 Ars Technica 评论板上的提示（原始帖子在这里），我还设置了noatime阵列文件系统的挂载选项（默认情况下 ext4 文件系统不设置该选项）。根据评论板讨论，更新上次访问时间可能会压倒驱动器中的 SMR 逻辑，最终导致驱动器掉线。
  7. 如果“故障”驱动器（或另一个驱动器）再次从阵列中掉出来，我将发布更新。

此外，许多媒体开始报道一些主要硬盘制造商的欺骗性营销行为，其中包括西部数据（一个例子链接在这里）。看来他们在几款 Red 硬盘中使用了叠瓦式磁记录 (SMR) 技术，但没有贴上标签或宣传，尽管 SMR 已知会导致 NAS 和 RAID 配置出现问题（讽刺的是，SMR 的一些问题WD 自己的材料中提到过，他们指出，由驱动器管理的 SMR 不利于并行操作……如 RAID）。这显然是一个问题，因为红色驱动器专门销售用于 NAS 和 RAID 目的。

我购买的 4 TB 硬盘型号被怀疑是使用 SMR 的硬盘型号之一（型号 WD40EFAX）。根据新闻报道，具有 256 MB 缓存的 EFAX 型号（如我的）很可能使用 SMR。使用hdparm -I显示我的硬盘支持 TRIM，这显然是硬盘使用 SMR 的另一个指标：

[user@localhost]~% sudo hdparm -I /dev/sda
/dev/sda:
ATA device, with non-removable media
    Model Number:       WDC WD40EFAX-68JH4N0
...
Capabilities:
    LBA, IORDY(can be disabled)
    Queue depth: 32
    Standby timer values: spec'd by Standard, with device specific minimum
    R/W multiple sector transfer: Max = 16  Current = 16
    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:
       *    Data Set Management TRIM supported (limit 10 blocks)
       *    Deterministic read ZEROs after TRIM

我现在怀疑/担心我的问题可能是由 SMR 引起的，这显然是无法修复的。我向 Western Digital 提交了一份支持单，提供了所有这些信息，并询问他们是否愿意将“故障”驱动器换成使用 CMR 而不是 SMR 的版本（据说 WD40EFRX 型号使用 CMR）。无论如何，我都会在这里发布更新，这样就可以再提供一个案例研究。

关于永无止境的延长测试的说明

一些谷歌搜索似乎表明，延长/长时间的 SMART 测试永远无法完成（90% 完成/10% 剩余）显然是一个常见问题——即使对于状况良好的驱动器也是如此。我开始对阵列中的另一个驱动器运行长时间测试，它也停留在 10% 剩余状态很长时间。关于为什么会发生这种情况有很多理论，但修复方法并不多。我确实找到了一个可能的解决方法（下面的链接），我会尝试一下，但除此之外，这可能是一个令人沮丧的错误。

答案1

部分答案：

但是有人知道如何解码日志中的错误吗？

Apr 14 18:07:38 xenon kernel: sd 0:0:0:0: [sda] tag#0 FAILED Result: hostbyte=DID_OK driverbyte=DRIVER_SENSE
Apr 14 18:07:38 xenon kernel: sd 0:0:0:0: [sda] tag#0 Sense Key : Aborted Command [current]
Apr 14 18:07:38 xenon kernel: sd 0:0:0:0: [sda] tag#0 Add. Sense: No additional sense information
Apr 14 18:07:38 xenon kernel: sd 0:0:0:0: [sda] tag#0 CDB: Synchronize Cache(10) 35 00 00 00 00 00 00 00 00 00

SCSI 命令Synchronize Cache(10)失败，设备未报告任何其他信息。这tag表明您可能正在使用 UAS 协议（USB 连接的 SCSI），因此您可以同时执行多个命令。

Apr 14 18:07:38 xenon kernel: blk_update_request: I/O error, dev sda, sector 2056

尝试更新块 2056 时发生了这种情况。

Apr 14 18:07:38 xenon kernel: md: super_written gets error=-5, uptodate=0

这是从md层中调用的。

Apr 14 18:07:38 xenon kernel: md/raid:md127: Disk failure on sda1, disabling device.#012md/raid:md127: Operation continuing on 3 devices.

因此该md层决定踢出该硬盘。

有什么方法可以判断这是驱动器出现故障还是驱动器控制器出现故障？

这真的很难说。考虑到 (a) 这种情况时有发生，(b) 这种情况发生在类似的扇区（即当层md执行类似操作时），以及 (c) 您启用了 UAS，我目前的猜测是驱动程序/固件错误，在并行处理命令时发生，并且出现了开发人员未预料到的奇怪情况。

由于 SMART 值良好，并且可以读取受影响的扇区，因此驱动器在物理上应该是正常的。

因此，我接下来要做的是降低软件交互的复杂性，看看是否有帮助。因此，禁用该驱动器的 UAS（谷歌），运行一段时间，看看错误是否仍然发生。禁用 UAS 可能会稍微降低性能。

答案2

使用 smartctl -x，而不是 smartctl -a

您将看到驱动器内部以这种方式记录的错误 - 很有可能是 IDNF 错误。

这是 WD固件他们目前拒绝承认错误，并且在上面该驱动器是伪装成 CMR 单元的 DM-SMR 的问题。

答案3

只是想提供一点结论。SMR 与 CMR 的问题现在常识，所以我猜测这个问题（加上上面提到的可能的固件问题）可能是导致我遇到问题的原因。我联系了 WD，询问他们是否愿意用等效的 EFRX 型号替换我的硬盘（因为该型号使用 CMR）。由于硬盘仍在零售商的退货政策期限内，他们建议我退货。由于手头没有替换品（因为它们包含数据），我无法退货，所以我订购了四个全新的 WD Red Pro 4TB 硬盘作为替代品。我想我会再给 WD 一次机会，而且 Pro 硬盘肯定不会有同样的问题（注意这是前WD 发布了有关哪些驱动器使用每种技术的详细信息）...

我收到了新硬盘，并立即使用 SMART Tools 和坏块对它们进行了测试。每个硬盘都返回了大量错误。每个。单个。硬盘。有人认为这可能是由于运输过程中的粗暴处理造成的，但无论如何——我现在有四个更多的驱动器需要退货。我将这些驱动器作为有缺陷的驱动器退回给零售商，但此时我即将用尽我的原始 EFAX 驱动器的退货期限。我无法获得一组新的驱动器，对其进行测试，将它们交换到我的阵列中，然后在剩余的退货期限内擦除原始驱动器。

我回到我原来的 WD 票并解释了情况，我再次要求他们用 EFRX 版本退回我原来的驱动器。而且...他们同意了！我有点惊讶，但支持人员确实同意退回我的 EFAX 驱动器。我告诉他们我实际上有四个 EFAX 驱动器，并询问他们是否可以为 EFRX 版本退回所有四个驱动器，他们也同意了。最后，我请求提前退回，这样我就可以现在收到新驱动器，然后在更换完所有驱动器后再寄回旧驱动器。他们也同意了。

后来，支持人员再次联系我，告诉我他们的仓库中目前 EFRX 型号缺货，但很快就会有货。所以他们给了我等待或购买 Red Pro 驱动器（而不是 EFRX 驱动器）的选择。我很高兴购买了 Red Pro 版本，并于上周收到了它们。所有这些驱动器都通过了 SMART Tools 和坏块测试，我已成功将它们交换到我的阵列中。新阵列上线时间不长，但我希望不会再出现任何问题。所以我很高兴 WD（最终）尝试纠正问题。当然，这并不能成为他们最初行为的借口，但至少他们似乎正在听取一些批评意见。

相关内容