LINUX.ORG.RU
Форум — Linux-hardware  

Внезапно исчезнувшие с жёсткого диска бэд-блоки.

 , , , ,


1

1

Столкнулся с нижеописанной ситуацией, причём уже второй раз за несколько лет (первый раз был на работе, тогда мне просто поменяли диск и я не парился, а вот человек, который взял «сбойный» диск для некритичных данных, удивил тем, что у него никаких бэдов нет).

Debian Jessie работал из-под VirtualBox в Windows, в режиме raw disk vmdk. Внезапно оффтопик сообщил, что VirtualBox совершил недопустимую операцию (формулировку не помню) и был закрыт. При загрузке в режиме гостя виртуальной машины сразу же на консоль посыпались ошибки доступа к диску. Перезагрузился в режиме нормальной операционки (не под виртуалкой), ошибки не исчезли. Начал восстанавливать-чекать с помощью установленной рядом Ubuntu 14.04.3. После долгих шаманств перенёс все разделы на другой носитель, при этом  fsck -c <раздел на старом диске> ругался на нечитаемые блоки в линуксовых разделах, также, как ругался и ntfsclone, с помощью которого переносил виндовый раздел. После этого я очистил сбойный носитель командой shred -n1 -z -v <устройство> , собираясь уже относить обратно в магазин (диску даже года нет).

После чего на этом сбойном диске с помощью gparted создал BIOS`овскую таблицу разделов, на которой создал единственный раздел ntfs на весь диск. Перезагрузился в винду, половину дня чекал стандартной виндовой утилитой.

Какое же было моё удивление, когда оказалось, что виндовая утилита бэдов не нашла (ни одного)! Окей, перезагрузился в линукс - проблем пока не увидел. В настоящее время badblocks -s -v <устройство> прочекал уже 50% и ни одного бэда не нашёл. Подозреваю, что и дальше не найдёт.

Вопросы: 1) Здоров ли мой диск? 2) Если нужно его менять, то что говорить в магазине для обмена? 3) Что, вообще, случилось (я лично подозреваю, что из-за какого-то глюка (какого?) сошёл с ума контроллер диска, а shred его образумил - так ли это)?

Сам неистово гуглил в поисках ответов, но ничего похожего не обнаружил. Ближайший случай - это ошибки, аналогичные инфе A ниже, возникшие из-за взаимодействия virtualbox с буферизацией хоста-офтопика, но там эти ошибки исчезали после перезагрузки и fsck.

Инфа:

Linux xxx 3.16.0-4-amd64 #1 SMP Debian 3.16.7-ckt25-2 (2016-04-08) x86_64 GNU/Linux

A. Виды ошибок, сыпавшихся на консоль и в сислог:

Sep 3 22:17:48 xxx kernel: [ 1395.972304] ata3.00: exception Emask 0x0 SAct 0x20 SErr 0x0 action 0x0
Sep 3 22:17:48 xxx kernel: [ 1395.972308] ata3.00: irq_stat 0x40000008
Sep 3 22:17:48 xxx kernel: [ 1395.972312] ata3.00: failed command: WRITE FPDMA QUEUED
Sep 3 22:17:48 xxx kernel: [ 1395.972317] ata3.00: cmd 61/10:28:00:90:ee/00:00:36:00:00/40 tag 5 ncq 8192 out
Sep 3 22:17:48 xxx kernel: [ 1395.972317] res 41/10:28:00:90:ee/00:00:36:00:00/40 Emask 0x481 (invali
d argument) <F>
Sep 3 22:17:48 xxx kernel: [ 1395.972320] ata3.00: status: { DRDY ERR }
Sep 3 22:17:48 xxx kernel: [ 1395.972322] ata3.00: error: { IDNF }
Sep 3 22:17:48 xxx kernel: [ 1395.972594] ata3.00: configured for UDMA/133
Sep 3 22:17:48 xxx kernel: [ 1395.972604] ata3: EH complete

Sep 7 23:08:16 xxx kernel: [ 899.854688] ata1.00: exception Emask 0x0 SAct 0x0 SErr 0x0 action 0x0
Sep 7 23:08:16 xxx kernel: [ 899.854695] ata1.00: BMDMA stat 0x25
Sep 7 23:08:16 xxx kernel: [ 899.854701] ata1.00: failed command: READ DMA
Sep 7 23:08:16 xxx kernel: [ 899.854711] ata1.00: cmd c8/00:80:b0:88:1b/00:00:00:00:00/e0 tag 0 dma 65536 in
Sep 7 23:08:16 xxx kernel: [ 899.854711] res 51/40:1f:10:89:1b/00:00:00:00:00/e0 Emask 0x9 (media er
ror)
Sep 7 23:08:16 xxx kernel: [ 899.854716] ata1.00: status: { DRDY ERR }
Sep 7 23:08:16 xxx kernel: [ 899.854719] ata1.00: error: { UNC }
Sep 7 23:08:16 xxx kernel: [ 899.919073] ata1.00: configured for UDMA/133
Sep 7 23:08:16 xxx kernel: [ 899.919147] sd 0:0:0:0: [sda] Unhandled sense code
Sep 7 23:08:16 xxx kernel: [ 899.919150] sd 0:0:0:0: [sda] 
Sep 7 23:08:16 xxx kernel: [ 899.919152] Result: hostbyte=DID_OK driverbyte=DRIVER_SENSE
Sep 7 23:08:16 xxx kernel: [ 899.919154] sd 0:0:0:0: [sda] 
Sep 7 23:08:16 xxx kernel: [ 899.919156] Sense Key : Medium Error [current] [descriptor]
Sep 7 23:08:16 xxx kernel: [ 899.919160] Descriptor sense data with sense descriptors (in hex):
Sep 7 23:08:16 xxx kernel: [ 899.919162] 72 03 11 04 00 00 00 0c 00 0a 80 00 00 00 00 00 
Sep 7 23:08:16 xxx kernel: [ 899.919173] 00 1b 89 10 
Sep 7 23:08:16 xxx kernel: [ 899.919178] sd 0:0:0:0: [sda] 
Sep 7 23:08:16 xxx kernel: [ 899.919180] Add. Sense: Unrecovered read error - auto reallocate failed
Sep 7 23:08:16 xxx kernel: [ 899.919183] sd 0:0:0:0: [sda] CDB: 
Sep 7 23:08:16 xxx kernel: [ 899.919184] Read(10): 28 00 00 1b 88 b0 00 00 80 00
Sep 7 23:08:16 xxx kernel: [ 899.919194] end_request: I/O error, dev sda, sector 1804560
Sep 7 23:08:16 xxx kernel: [ 899.919197] Buffer I/O error on device sda2, logical block 1597712

B. Вывод smartctl ПОСЛЕ всей этой эпопеи (на «как-бы, диске без бэдов»). Когда я пытался воспользоваться smartctl из Убунты, детального отчёта по последним 5 ошибкам не было, а smartctl --test=short завершился ошибкой на 60% (инфа об этом присутствует в приведённом ниже дампе от smartctl -a: 

# smartctl -a /dev/sdb
smartctl 6.4 2014-10-07 r4002 [x86_64-linux-3.16.0-4-amd64] (local build)
Copyright (C) 2002-14, Bruce Allen, Christian Franke, www.smartmontools.org

=== START OF INFORMATION SECTION ===
Model Family: Western Digital Caviar Green (AF, SATA 6Gb/s)
Device Model: WDC WD20EZRX-00D8PB0
Serial Number: WD-WCC4xxxx
LU WWN Device Id: 5 00xxxx
Firmware Version: 80.00A80
User Capacity: 2 000 398 934 016 bytes [2,00 TB]
Sector Sizes: 512 bytes logical, 4096 bytes physical
Rotation Rate: 5400 rpm
Device is: In smartctl database [for details use: -P show]
ATA Version is: ACS-2 (minor revision not indicated)
SATA Version is: SATA 3.0, 6.0 Gb/s (current: 6.0 Gb/s)
Local Time is: Sun Sep 11 20:17:23 2016 AST
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: (26100) 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: ( 264) minutes.
Conveyance self-test routine
recommended polling time: ( 5) minutes.
SCT capabilities: (0x7035) SCT Status 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 199 199 051 Pre-fail Always - 4040
3 Spin_Up_Time 0x0027 177 173 021 Pre-fail Always - 4125
4 Start_Stop_Count 0x0032 098 098 000 Old_age Always - 2192
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 098 098 000 Old_age Always - 1824
10 Spin_Retry_Count 0x0032 100 100 000 Old_age Always - 0
11 Calibration_Retry_Count 0x0032 100 100 000 Old_age Always - 0
12 Power_Cycle_Count 0x0032 098 098 000 Old_age Always - 2192
192 Power-Off_Retract_Count 0x0032 200 200 000 Old_age Always - 39
193 Load_Cycle_Count 0x0032 191 191 000 Old_age Always - 27120
194 Temperature_Celsius 0x0022 119 110 000 Old_age Always - 28
196 Reallocated_Event_Count 0x0032 200 200 000 Old_age Always - 0
197 Current_Pending_Sector 0x0032 200 199 000 Old_age Always - 0
198 Offline_Uncorrectable 0x0030 200 200 000 Old_age Offline - 0
199 UDMA_CRC_Error_Count 0x0032 200 200 000 Old_age Always - 0
200 Multi_Zone_Error_Rate 0x0008 200 200 000 Old_age Offline - 0

SMART Error Log Version: 1
ATA Error Count: 416 (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.

# Комментарий: как видно, крайняя ошибка произошла больше 30 часов назад, - это соответствует тому моменту, когда я уже делал shred
Error 416 occurred at disk power-on lifetime: 1791 hours (74 days + 15 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 08 80 b5 30 e5 Error: UNC 8 sectors at LBA = 0x0530b580 = 87078272

Commands leading to the command that caused the error were:
CR FR SC SN CL CH DH DC Powered_Up_Time Command/Feature_Name
-- -- -- -- -- -- -- -- ---------------- --------------------
c8 00 08 80 b5 30 e5 08 01:09:17.737 READ DMA

Error 415 occurred at disk power-on lifetime: 1791 hours (74 days + 15 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 08 80 b5 30 e5 Error: UNC 8 sectors at LBA = 0x0530b580 = 87078272

Commands leading to the command that caused the error were:
CR FR SC SN CL CH DH DC Powered_Up_Time Command/Feature_Name
-- -- -- -- -- -- -- -- ---------------- --------------------
c8 00 08 80 b5 30 e5 08 01:09:14.310 READ DMA

Error 414 occurred at disk power-on lifetime: 1791 hours (74 days + 15 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 08 80 b5 30 e5 Error: UNC 8 sectors at LBA = 0x0530b580 = 87078272

Commands leading to the command that caused the error were:
CR FR SC SN CL CH DH DC Powered_Up_Time Command/Feature_Name
-- -- -- -- -- -- -- -- ---------------- --------------------
c8 00 08 80 b5 30 e5 08 01:09:10.928 READ DMA

Error 413 occurred at disk power-on lifetime: 1791 hours (74 days + 15 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 06 82 b5 30 e5 Error: UNC 6 sectors at LBA = 0x0530b582 = 87078274

Commands leading to the command that caused the error were:
CR FR SC SN CL CH DH DC Powered_Up_Time Command/Feature_Name
-- -- -- -- -- -- -- -- ---------------- --------------------
c8 00 06 82 b5 30 e5 08 01:09:07.498 READ DMA

Error 412 occurred at disk power-on lifetime: 1791 hours (74 days + 15 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 01 81 b5 30 e5 Error: UNC 1 sectors at LBA = 0x0530b581 = 87078273

Commands leading to the command that caused the error were:
CR FR SC SN CL CH DH DC Powered_Up_Time Command/Feature_Name
-- -- -- -- -- -- -- -- ---------------- --------------------
c8 00 01 81 b5 30 e5 08 01:09:04.051 READ DMA
ec 00 00 00 00 00 a0 08 01:09:04.042 IDENTIFY DEVICE
ef 03 46 00 00 00 a0 08 01:09:04.034 SET FEATURES [Set transfer mode]

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% 1824 -  # комментарий: это тест, который я запросил недавно
# 2 Short offline Completed: read failure 60% 1788 1804560 # а это - тот, когда я разбирался со спамом сообщений об ошибках

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.

Причины могут быть 2
1) Блоки перераспределились. Контроллеры жёстких дисков могут их подменять незаметно для операционной системы.
2) Просто изменилась температура. У меня когда то давно были жёсткие диски которые зимой постоянно сыпались плохими блоками, а летом работали хорошо.

rezedent12 ☆☆☆
()

У тебя некоторые секторы плохо записались (чексумма не соотвтствовала данным). Когда их попытались прочитать у тебя упала виртуалкоробка. Когда ты стал чекать диски секторы как были так и оставались нечитаемыми. Когда ты сделал шред (можно было и dd if==/dev/zero и ata secure eraze) в сектор были записаны новые данные, успешно, потому что поверхность цела.

Воткни покрепче разъём питания, замени бп если старый, купи ИБП с защитой и настрой бекапы.

legolegs ★★★★★
()

бэд-блоки

Их нет до тех пор, пока тут ноль: 

5 Reallocated_Sector_Ct 0x0033 200 200 140 Pre-fail Always - 0
А вот нечитаемым сектор может быть. И когда надежда прочитать иссякает, тогда его перезаписывают. Если он после этого читается, значит не бэд.

После этого я очистил сбойный носитель командой shred -n1 -z -v <устройство>

Что и провело перезапись всех секторов.

Вопросы: 1) Здоров ли мой диск?

Как уже выше подметили, тут стоит проверить, а здоровы ли условия эксплуатации? Или не произошло ли чего в тот момент, когда посыпались: 

1 Raw_Read_Error_Rate 0x002f 199 199 051 Pre-fail Always - 4040

gag ★★★★★
()
Ответ на: комментарий от gag


Их нет до тех пор, пока тут ноль:

Вот сейчас имеется такой. Что запись что чтение пролагивает систему на этих секторах. Как считать? Заставить релокнуть не могу.

Model: HGST HTS545050A7E380
 Num  Attribute Name                Value  Worst  Raw(hex)        Threshold  
 005  Reallocation Sector Count     100    100    0000000000-0000 005
 197  Current Pending Errors Count  100    100    0000000000-0008 000

FeyFre ★★★★
()
Ответ на: комментарий от FeyFre

Насколько мне известно, диску придётся воспользоваться сектором из резерва только если будет запрошена запись в нечитаемый сектор, и она не удастся. А если удастся, то сектор будет считаться снова как новенький и pending уменьшится.

Так что локализуем сектор, потом с помощью dd пытаемся на всякий случай считать его. Если надежды получить данные больше нет, тогда перезаписываем его. Кстати, если диск не совсем старый и имеет на самом деле сектора по 4096 байт, то надёжнее писать/читать все 4K разом.

gag ★★★★★
()
Ответ на: комментарий от gag

Как уже выше подметили, тут стоит проверить, а здоровы ли условия эксплуатации? Или не произошло ли чего в тот момент, когда посыпались:

Вроде ничего не было, за исключением того, что в сам момент сбоя была активная запись (выполнялся apt-get install ). Вольтаж после этого эпизода был нормальным.

1 Raw_Read_Error_Rate 0x002f 199 199 051 Pre-fail Always - 4040

А этот Rate, судя по названию - это частота ошибок за какой-то период - так вот, за какой?

allter149 ★
() автор топика
Ответ на: комментарий от legolegs

Интересно, а они не могли плохо записаться из-за глюка на программном уровне (в VirtualBox, в linux или в винде)? Я считал, что если команда на запись попала в контроллер диска и если после этого не случилось отключения питания, то данные будут 100% записаны, если поверхность цела.

БП новый, нагружен не полностью. Про ИБП мысль интересная - про то, что он полезен для корректности работы, например, в условиях «моргающего» электричества - не думал.

allter149 ★
() автор топика
Ответ на: комментарий от gag

Их нет до тех пор, пока тут ноль

некоторые WD держат этот атрибут нулем даже при ненулевом кол-ве реаллокейтов (скажем до сотни-двух).

посмотреть вол-во можно под оффтопиком через wdmarvel demo (посмотреть g-list).

А вот нечитаемым сектор может быть. И когда надежда прочитать иссякает, тогда его перезаписывают.

что приводит либо к римэпу (если реальный бэд), либо - к записи читающегося сектора (в случае софт-бэда - при повреждении контрольной суммы/прерывании записи при отключении питания).

NiTr0 ★★★★★
()
Ответ на: комментарий от allter149

кто производитель БП? новый - не значит нормальный.

NiTr0 ★★★★★
()

Кабель смени.

Western Digital Caviar Green

И диск нормальный купи.

anonymous
()
Ответ на: комментарий от NiTr0

некоторые WD держат этот атрибут нулем даже при ненулевом кол-ве реаллокейтов (скажем до сотни-двух).

Вот уж логика у этих производителей. Есть специальный параметр - так нет, не использовать его, прятать правду от пользователя. Мало того, что кол-во резервных секторов неизвестно.

посмотреть вол-во можно под оффтопиком через wdmarvel demo (посмотреть g-list).

И как давно это уже возможно? В smartctl ещё не отреверсили?

gag ★★★★★
()

Pending в смарте может обнулиться, reallocated вроде нет. У меня было что полгода потом ещё работали совершенно нормально, а потом головы развалились (ну или та насадка выпала, это вроде часто случается в вд и особенно с зелёными). Правда я только предполагаю по звуку что проблема была с головами. До смарта не достучаться когда совершенно внезапно перестал реагировать на любые команды.

прочекал уже 50% и ни одного бэда не нашёл

вот вот, после 3-хкратного прогона деструктивного режима badblocks тоже всё хорошо стало. Короче, готовь замену и бэкапы, а ещё лучше поменяй диск на нормальный (блэк, в крайнем случае рэд раз так хочешь трешеделов вд) пока есть возможность.

anonymous
()
Ответ на: комментарий от legolegs

купи ИБП с защитой

ИБП с китайской синусоидой хуже голой розетки.

steemandlinux ★★★★★
()
Ответ на: комментарий от gag

Так что локализуем сектор, потом с помощью dd пытаемся на всякий случай считать его.

Какой ещё dd?

hdparm --read-sector xxx
hdparm --write-sector xxx
Deleted
()
Ответ на: комментарий от Deleted

Можно и так. Но hdparm может быть не всегда, а вот dd точно будет.

gag ★★★★★
()
Ответ на: комментарий от gag

Вот уж логика у этих производителей. Есть специальный параметр - так нет, не использовать его, прятать правду от пользователя. Мало того, что кол-во резервных секторов неизвестно.

дык простая логика: есть реаллокейты - значит надо винт менять по гарантии. чтобы их не было - или более жесткое (= долгое) заводское тестирование, или первую сотню к примеру бэдов не показывать в смарте.

И как давно это уже возможно? В smartctl ещё не отреверсили?

давно. софтину писали пользуясь утекшим trex (там скрипты, можете посмотреть), + реверсинг китайского wdr.

NiTr0 ★★★★★
()

У меня самсунг на 1тб (модель не помню) такой же бы, беды по появлялись то изчезали, порча при этом файлы. Меняй по гарантии или выкидывай - время/нервы дороже.

Rost ★★★★★
()
Ответ на: комментарий от NiTr0

дык простая логика: есть реаллокейты - значит надо винт менять по гарантии.

Пошлют тебя в магазине с твоей парой реаллокейтов.

legolegs ★★★★★
()
Ответ на: комментарий от allter149

Интересно, а они не могли плохо записаться из-за глюка на программном уровне

Точно нет. Только глюк диска, некачественное питание или проблема с поверхностью (но последнее ты исключил).

legolegs ★★★★★
()

Скорее всего это дефект магнитных пластин. Почему я так решил? Поточу что в моем случае битые блоки появлялись в одной и той же области. Причем после перезаписи проблемных участков, данные читались без проблем, а через неделю-месяц снова появлялись нечитабельные секторы. Если у тебя так же - избавляйся от диска срочно, питание и прочее тут не причем.

Rost ★★★★★
()
Ответ на: комментарий от legolegs

с какой радости пошлют? налицо дефектный сыпящийся винт.

NiTr0 ★★★★★
()
Ответ на: комментарий от NiTr0

И как давно это уже возможно? В smartctl ещё не отреверсили?

давно. софтину писали пользуясь утекшим trex (там скрипты, можете посмотреть), + реверсинг китайского wdr.

Пока не смотрел внутрь, но снаружи выглядит проприетарно, так что это не совсем тот реверс, который я имел ввиду. Например, smartctl поддерживает настройку IDLE таймера. В open source. Так что реверсить всё ещё нужно. Или там всё нужное в скриптах и этого достаточно, чтобы получить от винта нужные данные под линуксом?

gag ★★★★★
()
Ответ на: комментарий от legolegs

wdmarvel же... ну или любая другая сервисная утиль которая способна работать со служебкой винта (wdr, pc3000 и т.п.)

NiTr0 ★★★★★
()
Последнее исправление: NiTr0 (всего исправлений: 1)
Ответ на: комментарий от legolegs

нет. и навряд будет. как минимум - гемор с получением доступа к регистрам контроллера (а иначе с винтом, который к примеру в сейф моде и не поднимает DRDY, не пообщаешься). ну и объем раскопок (wdmarvel к примеру, хоть и с использованием утекшего trex, пилится уже лет 5 активно, и по части ремонта, пожалуй, обошел pc3000 - которая традиционно ориентирована больше на восстановление данных).

NiTr0 ★★★★★
()
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.
Linux-hardware