Выявляем процессы с дисковой активностью в Linux

    TL;DR: статья рассказывает об удобном, быстром и надежном способе определения Linux-программ, записывающих данные на диск, что помогает в выявлении большой или аномально частой нагрузки на дисковую подсистему, а также позволяет оценить накладные расходы файловой системы. Это особенно актуально для SSD в ПК, EMMC и Flash-памяти в одноплатных компьютерах.
    В ходе написания статьи обнаружилось, что запись нескольких килобайт данных на файловую систему BTRFS приводит к записи 3 мегабайт реальных данных на диск.

    Введение

    «Ой, ерунда, ячейки памяти на современных SSD выйдут из строя через десятки лет обычного использования, не стоит об этом беспокоиться, и уж тем более переносить swap, виртуальные машины и папку профиля браузера на HDD» — типичный ответ на вопрос о надежности твердотельных накопителей c гарантированными ≈150 TBW. Если прикинуть, сколько типичное ПО может писать данных, то кажется, что 10-20 ГБ в сутки — уже большая цифра, пусть будет максимум 40 ГБ, куда уж больше. При таких цифрах ответ вполне разумен — нужно 10 лет, чтобы достичь гарантированных значений по количеству перезаписи ячеек, при 40 ГБ записанных данных ежедневно.
    Однако за 6 лет я пользуюсь уже третьим SSD: у первого вышел из строя контроллер, а второй начал перемещать данные между ячейками несколько раз в день, что оборачивалось 30-секундными задержками в обслуживании записи.

    После 7 месяцев использования нового SSD я решил проверить количество записанных данных, как их сообщает сам диск через SMART.
    19.7 ТБ.
    Всего за 7 месяцев я использовал 13% от гарантированного количества записанных данных, притом, что он настроен в соответствии с рекомендациями по выравниваю разделов и настройке ФС, swap у меня почти не используется, диски виртуальных машин размещены на HDD!
    Это аномально большая цифра, такими темпами гарантийный TBW будет превышен раньше достижения 5-летнего срока гарантии диска. Да и не может мой компьютер писать по 93 гигабайта в сутки! Нужно проверить, сколько данных пишется на диск за 10 минут…
    Total:
    Writes Queued: 24,712, 2,237MiB
    Writes Completed: 25,507, 2,237MiB
    Write Merges: 58, 5,472KiB
    2.2 ГиБ, о-го-го!

    Определение количества записанных данных на дисковое устройство

    Если ваше устройство поддерживает S.M.A.R.T. (SSD, EMMC, некоторые промышленные MicroSD), то первым делом следует запросить данные с накопителя программами smartctl, skdump или mmc (из состава mmc-utils).

    Пример вывода программы smartctl
    $ sudo smartctl -a /dev/sdb
    smartctl 7.0 2019-03-31 r4903 [x86_64-linux-5.3.11-200.fc30.x86_64] (local build)
    Copyright (C) 2002-18, Bruce Allen, Christian Franke, www.smartmontools.org
    
    === START OF INFORMATION SECTION ===
    Model Family:     Samsung based SSDs
    Device Model:     Samsung SSD 860 EVO mSATA 250GB
    Serial Number:    S41MNC0KA13477K
    LU WWN Device Id: 5 002538 e700fa64b
    Firmware Version: RVT41B6Q
    User Capacity:    250 059 350 016 bytes [250 GB]
    Sector Size:      512 bytes logical/physical
    Rotation Rate:    Solid State Device
    Form Factor:      mSATA
    Device is:        In smartctl database [for details use: -P show]
    ATA Version is:   ACS-4 T13/BSR INCITS 529 revision 5
    SATA Version is:  SATA 3.1, 6.0 Gb/s (current: 3.0 Gb/s)
    Local Time is:    Tue Nov 19 01:48:50 2019 MSK
    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:      (   0) The previous self-test routine completed
                                            without error or no self-test has ever 
                                            been run.
    Total time to complete Offline 
    data collection:                (    0) seconds.
    Offline data collection
    capabilities:                    (0x53) SMART execute Offline immediate.
                                            Auto Offline data collection on/off support.
                                            Suspend Offline collection upon new
                                            command.
                                            No Offline surface scan supported.
                                            Self-test supported.
                                            No 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:        (  85) minutes.
    SCT capabilities:              (0x003d) SCT Status supported.
                                            SCT Error Recovery Control supported.
                                            SCT Feature Control supported.
                                            SCT Data Table supported.
    
    SMART Attributes Data Structure revision number: 1
    Vendor Specific SMART Attributes with Thresholds:
    ID# ATTRIBUTE_NAME          FLAG     VALUE WORST THRESH TYPE      UPDATED  WHEN_FAILED RAW_VALUE
      5 Reallocated_Sector_Ct   0x0033   100   100   010    Pre-fail  Always       -       0
      9 Power_On_Hours          0x0032   098   098   000    Old_age   Always       -       5171
     12 Power_Cycle_Count       0x0032   099   099   000    Old_age   Always       -       459
    177 Wear_Leveling_Count     0x0013   096   096   000    Pre-fail  Always       -       62
    179 Used_Rsvd_Blk_Cnt_Tot   0x0013   100   100   010    Pre-fail  Always       -       0
    181 Program_Fail_Cnt_Total  0x0032   100   100   010    Old_age   Always       -       0
    182 Erase_Fail_Count_Total  0x0032   100   100   010    Old_age   Always       -       0
    183 Runtime_Bad_Block       0x0013   100   100   010    Pre-fail  Always       -       0
    187 Uncorrectable_Error_Cnt 0x0032   100   100   000    Old_age   Always       -       0
    190 Airflow_Temperature_Cel 0x0032   058   039   000    Old_age   Always       -       42
    195 ECC_Error_Rate          0x001a   200   200   000    Old_age   Always       -       0
    199 CRC_Error_Count         0x003e   100   100   000    Old_age   Always       -       0
    235 POR_Recovery_Count      0x0012   099   099   000    Old_age   Always       -       29
    241 Total_LBAs_Written      0x0032   099   099   000    Old_age   Always       -       38615215765
    
    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.

    Мой SSD хранит количество записанных данных в параметре 241 Total_LBAs_Written, в логических блоках (LBA), а не в байтах. Размер логического блока в моём случае — 512 байт (его можно увидеть в выводе smartctl, в Sector Size). Чтобы получить байты, нужно умножить значение параметра на 512.
    38615215765 × 512 ÷ 1000 ÷ 1000 ÷ 1000 ÷ 1000 = 19,770 ТБ
    38615215765 × 512 ÷ 1024 ÷ 1024 ÷ 1024 ÷ 1024 = 17,981 ТиБ


    Программа skdump на моём SSD пытается интерпретировать значение Total_LBAs_Written как-то по-своему, из-за чего выводит 1296217.695 TB, что, очевидно, некорректно.

    Чтобы узнать количество записываемой информации на уровне устройства, воспользуемся программой btrace из состава пакета blktrace. Она показывает как общую статистику за всё время работы программы, так и отдельные процессы и потоки (в т.ч. ядра), которые выполняли запись.

    Запустите следующую команду, чтобы собрать информацию за 10 минут, где /dev/sdb — ваш диск:
    # btrace -w 600 -a write /dev/sdb

    Типичный вывод команды
    …
      8,16   0     3253    50.085433192     0  C  WS 125424240 + 64 [0]
      8,16   0     3254    50.085550024     0  C  WS 193577744 + 64 [0]
      8,16   0     3255    50.085685165     0  C  WS 197246976 + 64 [0]
      8,16   0     3256    50.085936852     0  C  WS 125736264 + 128 [0]
      8,16   0     3257    50.086060780     0  C  WS 96261752 + 64 [0]
      8,16   0     3258    50.086195031     0  C  WS 94948640 + 64 [0]
      8,16   0     3259    50.086327355     0  C  WS 124656144 + 64 [0]
      8,16   0     3260    50.086843733 15368  C WSM 310218496 + 32 [0]
      8,16   0     3261    50.086975238   753  A WSM 310218368 + 32 <- (8,20) 291339904
      8,16   0     3262    50.086975560   753  Q WSM 310218368 + 32 [dmcrypt_write/2]
      8,16   0     3263    50.086977345   753  G WSM 310218368 + 32 [dmcrypt_write/2]
      8,16   0     3264    50.086978072   753  I WSM 310218368 + 32 [dmcrypt_write/2]
      8,16   0     3265    50.086979159   753  D WSM 310218368 + 32 [dmcrypt_write/2]
      8,16   0     3266    50.087055685     0  C WSM 310218368 + 32 [0]
      8,16   0     3267    50.087060168   753  A WSM 310218592 + 160 <- (8,20) 291340128
      8,16   0     3268    50.087060367   753  Q WSM 310218592 + 160 [dmcrypt_write/2]
      8,16   0     3269    50.087061242   753  G WSM 310218592 + 160 [dmcrypt_write/2]
      8,16   0     3270    50.087061698   753  I WSM 310218592 + 160 [dmcrypt_write/2]
      8,16   0     3271    50.087062361   753  D WSM 310218592 + 160 [dmcrypt_write/2]
      8,16   0     3272    50.087386179     0  C WSM 310218592 + 160 [0]
      8,16   0     3273    50.087436417 15368  A FWS 0 + 0 <- (253,1) 0
      8,16   0     3274    50.087437471 15368  Q FWS [LS Thread]
      8,16   0     3275    50.087440862 15368  G FWS [LS Thread]
      8,16   0     3276    50.088300047     0  C  WS 0 [0]
      8,16   0     3277    50.088470917   753  A WFSM 18882688 + 8 <- (8,20) 4224
      8,16   0     3278    50.088471091   753  Q WFSM 18882688 + 8 [dmcrypt_write/2]
      8,16   0     3279    50.088471688   753  G WFSM 18882688 + 8 [dmcrypt_write/2]
      8,16   0     3280    50.088474334 32254  D WSM 18882688 + 8 [kworker/0:2H]
      8,16   0     3281    50.088515572     0  C WSM 18882688 + 8 [0]
      8,16   0     3282    50.089229069     0  C WSM 18882688 [0]
    CPU0 (8,16):
     Reads Queued:           0,        0KiB  Writes Queued:         345,   25,932KiB
     Read Dispatches:        0,        0KiB  Write Dispatches:      331,   25,788KiB
     Reads Requeued:         0               Writes Requeued:         0
     Reads Completed:        0,        0KiB  Writes Completed:    1,597,  117,112KiB
     Read Merges:            0,        0KiB  Write Merges:            1,       16KiB
     Read depth:             0               Write depth:           177
     IO unplugs:             0               Timer unplugs:           0
    CPU1 (8,16):
     Reads Queued:           0,        0KiB  Writes Queued:         502,   39,948KiB
     Read Dispatches:        0,        0KiB  Write Dispatches:      495,   40,076KiB
     Reads Requeued:         0               Writes Requeued:         0
     Reads Completed:        0,        0KiB  Writes Completed:        0,        0KiB
     Read Merges:            0,        0KiB  Write Merges:            0,        0KiB
     Read depth:             0               Write depth:           177
     IO unplugs:             0               Timer unplugs:           0
    CPU2 (8,16):
     Reads Queued:           0,        0KiB  Writes Queued:         297,   26,800KiB
     Read Dispatches:        0,        0KiB  Write Dispatches:      287,   26,800KiB
     Reads Requeued:         0               Writes Requeued:         0
     Reads Completed:        0,        0KiB  Writes Completed:        0,        0KiB
     Read Merges:            0,        0KiB  Write Merges:            0,        0KiB
     Read depth:             0               Write depth:           177
     IO unplugs:             0               Timer unplugs:           0
    CPU3 (8,16):
     Reads Queued:           0,        0KiB  Writes Queued:         418,   24,432KiB
     Read Dispatches:        0,        0KiB  Write Dispatches:      408,   24,448KiB
     Reads Requeued:         0               Writes Requeued:         0
     Reads Completed:        0,        0KiB  Writes Completed:        0,        0KiB
     Read Merges:            0,        0KiB  Write Merges:            2,      272KiB
     Read depth:             0               Write depth:           177
     IO unplugs:             0               Timer unplugs:           0
    
    Total (8,16):
     Reads Queued:           0,        0KiB  Writes Queued:       1,562,  117,112KiB
     Read Dispatches:        0,        0KiB  Write Dispatches:    1,521,  117,112KiB
     Reads Requeued:         0               Writes Requeued:         0
     Reads Completed:        0,        0KiB  Writes Completed:    1,597,  117,112KiB
     Read Merges:            0,        0KiB  Write Merges:            3,      288KiB
     IO unplugs:             0               Timer unplugs:           0
    
    Throughput (R/W): 0KiB/s / 2,338KiB/s
    Events (8,16): 9,287 entries
    Skips: 0 forward (0 -   0.0%)

    btrace позволяет наглядно посмотреть реальное количество записанных данных, но понять, какие именно программы совершают запись, из её вывода сложно.

    Определение программ, производящих запись на накопитель

    Программа iotop покажет процессы, пишущие на диск, и размер записанных данных.
    Наиболее удобный вывод обеспечивают следующие параметры:
    # iotop -obPat

    Пример вывода программы
    02:55:47 Total DISK READ :       0.00 B/s | Total DISK WRITE :      30.65 K/s
    02:55:47 Actual DISK READ:       0.00 B/s | Actual DISK WRITE:       0.00 B/s
        TIME  PID  PRIO  USER     DISK READ  DISK WRITE  SWAPIN      IO    COMMAND
    b'02:55:47   753 be/4 root          0.00 B      0.00 B  0.00 %  0.04 % [dmcrypt_write/2]'
    b'02:55:47   788 be/4 root         72.00 K     18.27 M  0.00 %  0.02 % [btrfs-transacti]'
    b'02:55:47 15057 be/4 valdikss    216.00 K    283.05 M  0.00 %  0.01 % firefox'
    b'02:55:47  1588 ?dif root          0.00 B      0.00 B  0.00 %  0.00 % Xorg -nolisten tcp -auth /var/run/sddm/{398f030f-9667-4dff-b371-81eaae48dfdf} -background none -noreset -displayfd 18 -seat seat0 vt1'
    b'02:55:47 15692 be/4 valdikss    988.00 K      9.41 M  0.00 %  0.00 % python3 /usr/bin/gajim'
    b'02:55:47 15730 ?dif valdikss      9.07 M      0.00 B  0.00 %  0.00 % telegram-desktop --'
    b'02:55:47  2174 ?dif valdikss   1840.00 K      2.47 M  0.00 %  0.00 % yakuake'
    b'02:55:47 19827 be/4 root         16.00 K    896.00 K  0.00 %  0.00 % [kworker/u16:7-events_unbound]'
    b'02:55:47 19074 be/4 root         16.00 K    480.00 K  0.00 %  0.00 % [kworker/u16:4-btrfs-endio-write]'
    b'02:55:47 19006 be/4 root         16.00 K   1872.00 K  0.00 %  0.00 % [kworker/u16:1-events_unbound]'
    b'02:55:47  1429 be/4 root        484.00 K      0.00 B  0.00 %  0.00 % accounts-daemon'
    b'02:55:47 15820 be/4 valdikss    312.00 K      0.00 B  0.00 %  0.00 % firefox -contentproc -childID 6 -isForBrowser -prefsLen 7894 -prefMapSize 223880 -parentBuildID 20191022164834 -greomni /usr/lib64/firefox/omni.ja -appomni /usr/lib64/firefox/browser/omni.ja -appdir /usr/lib64/firefox/browser 15057 tab'
    b'02:55:47  2125 ?dif valdikss      0.00 B     92.00 K  0.00 %  0.00 % plasmashell'
    b'02:55:47  1268 be/3 root          0.00 B      4.00 K  0.00 %  0.00 % auditd'
    b'02:55:47  1414 be/4 root          0.00 B      4.00 K  0.00 %  0.00 % sssd_nss --uid 0 --gid 0 --logger=files'
    b'02:55:47 15238 be/4 valdikss      0.00 B      4.00 K  0.00 %  0.00 % thunderbird'
    b'02:55:47 18605 be/4 root          0.00 B      3.19 M  0.00 %  0.00 % [kworker/u16:0-btrfs-endio-write]'
    b'02:55:47 18867 be/4 root          0.00 B     96.00 K  0.00 %  0.00 % [kworker/u16:5-btrfs-endio-meta]'
    b'02:55:47 19070 be/4 root          0.00 B    160.00 K  0.00 %  0.00 % [kworker/u16:2-btrfs-freespace-write]'
    b'02:55:47 19645 be/4 root          0.00 B      2.17 M  0.00 %  0.00 % [kworker/u16:3-events_unbound]'
    b'02:55:47 19982 be/4 root          0.00 B    496.00 K  0.00 %  0.00 % [kworker/u16:6-btrfs-endio-write]'


    В глаза бросается Firefox, записавший 283 мегабайта за несколько минут работы iotop.

    Определение файлов, в которые производится запись

    Информация о процессе, насилующим диск — хорошо, а пути, по которым производится запись — еще лучше.

    Воспользуемся программой fatrace, которая отслеживает изменения файловой системы.
    # fatrace -f W

    Пример вывода программы
    firefox(15057): CW /home/valdikss/.mozilla/firefox/xyf4vqh2.default/storage/default/moz-extension+++e5c304fb-af40-498a-9ba8-47eb0416e933^userContextId=4294967295/idb/3647222921wleabcEoxlt-eengsairo.sqlite-wal
    firefox(15057): CW /home/valdikss/.mozilla/firefox/xyf4vqh2.default/storage/default/moz-extension+++e5c304fb-af40-498a-9ba8-47eb0416e933^userContextId=4294967295/idb/3647222921wleabcEoxlt-eengsairo.sqlite
    firefox(15057): W /home/valdikss/.mozilla/firefox/xyf4vqh2.default/storage/default/https+++habr.com/ls/data.sqlite-journal
    firefox(15057): W /home/valdikss/.mozilla/firefox/xyf4vqh2.default/storage/default/https+++habr.com/ls/data.sqlite-journal
    firefox(15057): W /home/valdikss/.mozilla/firefox/xyf4vqh2.default/storage/default/https+++habr.com/ls/data.sqlite-journal
    firefox(15057): W /home/valdikss/.mozilla/firefox/xyf4vqh2.default/storage/default/https+++habr.com/ls/data.sqlite-journal
    firefox(15057): W /home/valdikss/.mozilla/firefox/xyf4vqh2.default/storage/default/https+++habr.com/ls/data.sqlite-journal
    firefox(15057): W /home/valdikss/.mozilla/firefox/xyf4vqh2.default/storage/default/https+++habr.com/ls/data.sqlite-journal
    firefox(15057): W /home/valdikss/.mozilla/firefox/xyf4vqh2.default/storage/default/https+++habr.com/ls/data.sqlite-journal
    firefox(15057): CW /home/valdikss/.mozilla/firefox/xyf4vqh2.default/storage/default/https+++habr.com/ls/usage-journal
    firefox(15057): W /home/valdikss/.mozilla/firefox/xyf4vqh2.default/storage/default/https+++habr.com/ls/usage
    firefox(15057): CW /home/valdikss/.mozilla/firefox/xyf4vqh2.default/storage/default/https+++habr.com/ls/usage
    firefox(15057): W /home/valdikss/.mozilla/firefox/xyf4vqh2.default/storage/default/https+++habr.com/ls/data.sqlite-journal
    firefox(15057): W /home/valdikss/.mozilla/firefox/xyf4vqh2.default/storage/default/https+++habr.com/ls/data.sqlite
    firefox(15057): W /home/valdikss/.mozilla/firefox/xyf4vqh2.default/storage/default/https+++habr.com/ls/data.sqlite
    firefox(15057): W /home/valdikss/.mozilla/firefox/xyf4vqh2.default/storage/default/https+++habr.com/ls/data.sqlite
    firefox(15057): W /home/valdikss/.mozilla/firefox/xyf4vqh2.default/webappsstore.sqlite-wal
    firefox(15057): W /home/valdikss/.mozilla/firefox/xyf4vqh2.default/webappsstore.sqlite-wal
    firefox(15057): W /home/valdikss/.mozilla/firefox/xyf4vqh2.default/webappsstore.sqlite-wal
    firefox(15057): W /home/valdikss/.mozilla/firefox/xyf4vqh2.default/webappsstore.sqlite-wal
    firefox(15057): W /home/valdikss/.mozilla/firefox/xyf4vqh2.default/webappsstore.sqlite-wal
    firefox(15057): W /home/valdikss/.mozilla/firefox/xyf4vqh2.default/webappsstore.sqlite-wal
    firefox(15057): W /home/valdikss/.mozilla/firefox/xyf4vqh2.default/webappsstore.sqlite-wal
    firefox(15057): CW /home/valdikss/.mozilla/firefox/xyf4vqh2.default/storage/default/https+++habr.com/ls/data.sqlite-journal
    firefox(15057): W /home/valdikss/.mozilla/firefox/xyf4vqh2.default/webappsstore.sqlite
    firefox(15057): W /home/valdikss/.mozilla/firefox/xyf4vqh2.default/webappsstore.sqlite
    firefox(15057): W /home/valdikss/.mozilla/firefox/xyf4vqh2.default/webappsstore.sqlite


    Fatrace не умеет показывать количество записанных данных вследствие использования довольно простого отслеживания факта обращения к файлам через inotify.

    Из вывода видно, как хабр сохраняет мою статью в local storage браузера, пока я её пишу, а также расширение Group Speed Dial, которое, как удалось обнаружить именно с помощью fatrace, читает свои данные каждые 30 секунд. Именно читает, а не записывает: CW перед файлом говорит о том, что файл открывается на чтение и запись, с одновременным созданием файла, если он отсутствует (вызывается openat с флагом O_RDWR|O_CREAT), но не говорит, что в файл действительно писалась какая-либо информация.

    На всякий случай, чтобы удостовериться в этом, воспользуемся strace, с фильтром на файловые системные вызовы:
    strace -yy -e trace=open,openat,close,write -f -p 15057 2>&1 | grep extension

    Вывод команды
    [pid 20352] openat(AT_FDCWD, "/home/valdikss/.mozilla/firefox/xyf4vqh2.default/storage/default/moz-extension+++e5c304fb-af40-498a-9ba8-47eb0416e933^userContextId=4294967295/idb/3647222921wleabcEoxlt-eengsairo.sqlite", O_RDWR|O_CREAT|O_CLOEXEC, 0644) = 153</home/valdikss/.mozilla/firefox/xyf4vqh2.default/storage/default/moz-extension+++e5c304fb-af40-498a-9ba8-47eb0416e933^userContextId=4294967295/idb/3647222921wleabcEoxlt-eengsairo.sqlite>
    [pid 20352] read(153</home/valdikss/.mozilla/firefox/xyf4vqh2.default/storage/default/moz-extension+++e5c304fb-af40-498a-9ba8-47eb0416e933^userContextId=4294967295/idb/3647222921wleabcEoxlt-eengsairo.sqlite>, "SQLite format 3\0\20\0\2\2\0@  \0\0\0d\0\0\0\23"..., 100) = 100
    [pid 20352] read(153</home/valdikss/.mozilla/firefox/xyf4vqh2.default/storage/default/moz-extension+++e5c304fb-af40-498a-9ba8-47eb0416e933^userContextId=4294967295/idb/3647222921wleabcEoxlt-eengsairo.sqlite>, "SQLite format 3\0\20\0\2\2\0@  \0\0\0d\0\0\0\23"..., 4096) = 4096
    [pid 20352] openat(AT_FDCWD, "/home/valdikss/.mozilla/firefox/xyf4vqh2.default/storage/default/moz-extension+++e5c304fb-af40-498a-9ba8-47eb0416e933^userContextId=4294967295/idb/3647222921wleabcEoxlt-eengsairo.sqlite-wal", O_RDWR|O_CREAT|O_CLOEXEC, 0644) = 166</home/valdikss/.mozilla/firefox/xyf4vqh2.default/storage/default/moz-extension+++e5c304fb-af40-498a-9ba8-47eb0416e933^userContextId=4294967295/idb/3647222921wleabcEoxlt-eengsairo.sqlite-wal>
    …
    [pid 20352] read(54</home/valdikss/.mozilla/firefox/xyf4vqh2.default/storage/default/moz-extension+++e5c304fb-af40-498a-9ba8-47eb0416e933^userContextId=4294967295/idb/3647222921wleabcEoxlt-eengsairo.sqlite>, "\0\0\0\r\4\30\4\36\4\35\4\35\4\36\4-\0 \4\20\4!\4'\4\1\4\"\0250 &"..., 4096) = 4096
    [pid 20352] read(54</home/valdikss/.mozilla/firefox/xyf4vqh2.default/storage/default/moz-extension+++e5c304fb-af40-498a-9ba8-47eb0416e933^userContextId=4294967295/idb/3647222921wleabcEoxlt-eengsairo.sqlite>, "\0\0\0\0\1\36P\t\226\250\4\0O\245\320\16:\"\16.\27\0r\245\306>\246\1\t\1q\370"..., 4096) = 4096
    [pid 20352] close(77</home/valdikss/.mozilla/firefox/xyf4vqh2.default/storage/default/moz-extension+++e5c304fb-af40-498a-9ba8-47eb0416e933^userContextId=4294967295/idb/3647222921wleabcEoxlt-eengsairo.sqlite-wal>) = 0
    [pid 20352] close(54</home/valdikss/.mozilla/firefox/xyf4vqh2.default/storage/default/moz-extension+++e5c304fb-af40-498a-9ba8-47eb0416e933^userContextId=4294967295/idb/3647222921wleabcEoxlt-eengsairo.sqlite>) = 0

    Нет ни одного вызова write(), что говорит об отсутствии записи в файл.

    Определение накладных расходов файловой системы

    Большая разница в показаниях iotop и btrace натолкнула на мысль протестировать файловую систему путем ручной записи данных в файл и отслеживания показаний btrace.

    Если полностью исключить запись на диск, загрузившись в emergency-режим systemd, и записать вручную пару байт данных в существующий файл, btrace на SSD с btrfs сообщает о записи 3 мегабайт реальных данных. Свежесозданная файловая система флешке размером в 8 ГБ записывает минимум 264 КиБ при записи одного байта.
    Для сравнения, запись пары байт в файл на ext4 оканчивается записью 24 килобайтов данных на диск.

    В 2017 году Jayashree Mohan, Rohan Kadekodi и Vijay Chidambaram провели исследование усиления записи разных файловых систем, их результаты для btrfs и ext4 при записи 4 КБ соотносятся с моими.



    Заключение и вывод

    Путём описанных манипуляций обнаружилось:
    1. Частая запись состояний заданий для принтера демоном печати CUPS в /var/cache/cups каждую минуту. Проблема устранена очисткой /var/spool/cups (хотя никаких заданий печати не было);
    2. Факт чтения базы данных каждые 30 секунд расширением Group Speed Dial для Firefox;
    3. Периодическая запись журналов различными сервисами отслеживания производительности в Fedora, что приводило к записи нескольких мегабайт данных на btrfs: pmcd.service, pmie.service, pmlogger.service;
    4. Огромная амплификация при записи небольшого количества данных при использовании btrfs.

    Вывод: не стоит использовать btrfs, если программы часто записывают небольшое количество данных (несколько килобайт), иначе это обернется мегабайтами записанных данных. Особенно актуально для одноплатных компьютеров с ОС на MicroSD.
    Поделиться публикацией
    AdBlock похитил этот баннер, но баннеры не зубы — отрастут

    Подробнее
    Реклама

    Комментарии 71

      0
      У самого на днях система на RPi не поднялась после перезагрузки. Всего одна новая программа за две недели убила microSD, которая до этого стабильно работала около 2-х лет.

      По теме на хабре есть большая статья с не менее большими комментариями — «Малиновый Прог против Интернета Кирпичей, или Raspberry Pi с графикой на read-only microSD»
        0
        Иногда read-only-система неудобна или нецелесообразна на одноплатниках, в этом случае описанные действия позволят выявить и отключить лишнее. Также, например, Libre Computer предоставляет образы ОС в btrfs в качестве основной файловой системы, и я до анализа её поведения на своем компьютере и написания этой статьи не знал, что усиление записи настолько сильное.
        +2
        Статья несомненно полезна, но Вы меня конечно простите, но вы какие-то странные ребята, я про автора статьи, который цитирует рекомендации по переносу профиля на hdd чтобы меньше писать на ssd и пожертвовать скоростью ради сохранности ssd.

        Для чего я покупаю SSD? В первую очередь для того чтобы быстро на него писать данные и еще быстрее читать эти данные, и мне пофиг будет ли на ssd профиль гуглохрома или еще какой-то программы которая будет насиловать диск, главное что эти программы работают быстро — что мне и нужно.
        Берите дешевые ssd, размещайте на них только ОС, а критически важные данные храните на hdd ну и конечно делайте бэкапы.
        Я раз в месяц снимаю с ssd где стоит ос образ и если он умрет я без сожаления его выкину, пойду и куплю новый ssd за 3 т.р., разверну образ ОС за 10 минут и продолжу работать. А заниматься ерундой по вычислению сколько какая программа пишет — увольте.
          +12
          За 6 лет это у меня уже третий SSD, т.е. SSD в моем ноутбуке в среднем нормально работает 2 года, заметьте, с учетом того, что большая часть часто изменяющихся данных находится на HDD. Это очень мало, аномально мало, поэтому я и начал разбираться. Если бы SSD не выходили из строя, а работали так, как обычно пишут комментирующие, я бы не заморачивался, и не узнал об огромном коэффициенте увеличения записи в btrfs. А ведь её люди и на MicroSD используют.

          А заниматься ерундой по вычислению сколько какая программа пишет — увольте.
          Статья также полезна для выявления значительных проблем ПО. Например, в 2016 году Spotify очень часто выполнял команду VACUUM на sqlite-базе, что приводило к записи до 700 ГБ в сутки на диск. Один такой Spotify, и гарантия на ваш диск истечет через полгода после покупки. Программа неправильно работала в течение 5 месяцев.
          arstechnica.com/information-technology/2016/11/for-five-months-spotify-has-badly-abused-users-storage-drives
            +7
            За 6 лет это у меня уже третий SSD, т.е. SSD в моем ноутбуке в среднем нормально работает 2 года, заметьте, с учетом того, что большая часть часто изменяющихся данных находится на HDD.

            У меня SSD живут намного дольше. Моему ThinkPad с единственным SSD на 256 Гб уже 5 лет, и я его ресурс никак не экономил. Использовал и swap и торренты качал все это время (не очень активно, но регулярно). И btrfs с dm-crypt использовал. Диск живой и никакого снижения производительности.


            За статью спасибо. Увы, думаю, такие эпизоды как со Spotify будут ждать нас все чаще. :(

              0
              Наверное и SSD у вас на SLC или MLC, сейчас подавляющее большинство дисков это TLC или QLC, ресурс у них в стони и тысячи раз меньше
                0

                А как узнать тип SSD? Искать по номеру модели?
                Thinkpad купил в 2014-м году. Думаю тогда уже не было в бытовом сегменте SLC или MLC.

                  +2
                  MLC даже сейчас вполне есть.
                  вот зимой прошлой купил samsung 970 pro, например.
                    +1
                    MLC в продаже ещё есть, желающие могут успеть. Как SATA, так и NVME. Samsung серии Pro возможно будет выпускаться и далее, но цена на него будет всегда очень высокой.
                      0
                      да не сказать что прям дорогой.
                      я за 12500 брал. щас даже дешевле. летом где-то за 10000 видел.
                  +2

                  Так в чём проблема купить сейчас SSD на MLC? Ну кроме того, что цена в полтора раза выше.

                    0
                    что характерно, даже на SLC есть.
                    цены, конечно, кусaются.
                +8
                Дак не используйте btrfs. В чем ее плюсы для домашнего использования? Скорость? Надежность? А, что классика ext4 уже для дома не надежна или медлительна? Нет. Дак в чем профит? Но все равно мыши плакали, кололись, но продолжали использовать btrfs.

                А может у Вас старая версия ядра и btrfs? Посмотрите тут и сравните с тем что у Вас. А еще прочитайте про профиль хранения данных в btrfs (при создании раздела SSD detected было yes ?) и вот это в официальном FAQ

                Ну и самое главное — зная архитектуру btrfs (хорошая статья):
                К сожалению, btrfs «благодаря» своей архитектуре крайне подвержена такому явлению, как фрагментация. Дело в том, что данные записываются всегда в новое расположение на диске. Даже если прочитать файл, ничего не сделать с данными и записать их обратно в тот же файл, то данные попадут на диске в новую область. То же самое произойдет, если обновить данные в файле только частично — изменения запишутся в новую область на диске.

                Можно сделать вывод, что «насиловать» SSD она будет всегда, остается лишь поднастроить ее, чтобы это было в пределах нормы.

                Ну и каждые 2 года новый SSD — конечно маловато, но один то SSD у вас по вине контроллера умер, то есть это был скорее всего брак и если исходить из отсутствия брака, то получается каждые 3 года новый SSD — по-моему вполне нормально, если Вы не будите покупать супер-дорогие, а остановитесь на дешевых.
                  +3

                  Профит btrfs для домашнего пользователя в снэпшотах. Правда, я не очень часто их использую, но приятно знать, что такая возможность существует. Например, их можно использовать для резервного копирования, для инкрементального резервного копирования.

                    +1

                    А ext4 с lvm этого уже не умеют?

                      +1

                      Накладные расходы при использовании снапгоиов там СИЛЬНО выше чему у btrfs

                      0
                      Поддержу.
                      У меня настроено автоматическое создание снепшотов через cron. И удаление их через 14 дней.
                      Очень удобно. За считанные секунды откатиться на любую дату, а потом обратно.
                      SSD у меня родной в MacBook Pro 2013 года.
                      Соответственно ему 6 лет. И SWAP, и профиль, и виртуальные машины — все на нем.
                      Никаких проблем не наблюдается…
                      С HDD использовать такую схему не настолько комфортно. Там приходится делать принудительную дефрагментацию, минимум раз в 3 месяца. Иначе начинаются «залипания» по несколько секунд. Во время дефрагментации производительность диска падает практически до нуля.
                      Но если настроить авто дефрагментацию в период минимальной нагрузки — вполне можно жить.
                      +2
                      Дак не используйте btrfs. В чем ее плюсы для домашнего использования? Скорость? Надежность? А, что классика ext4 уже для дома не надежна или медлительна? Нет. Дак в чем профит? Но все равно мыши плакали, кололись, но продолжали использовать btrfs.
                      Раньше я везде использовал только ext4, но в Fedora btrfs предлагается по умолчанию, и я решил использовать её. В btrfs очень удобная функциональность снапшотов. Понятно, что можно использовать ext4 на lvm, но btrfs просто удобней, хотя бы в силу того, что я несколько раз создавал ФС с не очень большим количеством inode, а потом не мог распаковать что-то большое на ФС.

                      Версия ядра у меня одна из самых новых, это же Fedora.
                        0
                        К сожалению, btrfs «благодаря» своей архитектуре крайне подвержена такому явлению, как фрагментация. Дело в том, что данные записываются всегда в новое расположение на диске. Даже если прочитать файл, ничего не сделать с данными и записать их обратно в тот же файл, то данные попадут на диске в новую область. То же самое произойдет, если обновить данные в файле только частично — изменения запишутся в новую область на диске.

                        Можно сделать вывод, что «насиловать» SSD она будет всегда, остается лишь поднастроить ее, чтобы это было в пределах нормы.

                        Что вы имеете ввиду, вменяя в данном случае фрагментацию как недостаток? Ведь для SSD эта проблема неактуальна. Да, фрагментация может появиться, но, так как в SSD нет движущихся деталей, ухудшить скорость работы она не может.
                          +2
                          Для SSD эта проблема также актуальна, но не так сильно выражена, как для HDD. SSD может обеспечивать, скажем, 3200 МБ/с линейного чтения и 40 МБ/с случайного, а HDD — 250 МБ/с линейного и 1 МБ/с случайного.
                            0
                            Извините, но я усомнюсь, все-таки основной урон от фрагментации вызван лишними движениями магнитных головок и ограничений механики, которой в SSD нет. И я никогда не слышал чтобы фрагментация как-то влияла на SSD, а скорее даже наоборот. Вы не могли бы привести пруф, пожалуйста?
                              0
                              Посмотрите любой тест SSD на случайное чтение. Обычно тестируют случайное чтение блоками по 4 КБ, что мало для реальных ФС, но кое-какое представление о разнице в скорости между линейным и случайным чтением, а следовательно, о воздействии фрагментации дать может.
                                +1
                                Если интересно, вот что сходу нашлось: www.overclock.net/forum/355-ssd/1538878-yes-file-system-fragmentation-does-affect-ssd-read-speed.html

                                image
                              0
                              Еще бы хотел добавить, что запись всегда в новое место естественным образом реализует выравнивание износа ячеек. Что для твердотельного накопителя плюс.

                              Я лично не встречался, но много раз слышал как флешки быстро умирали при использовании журналируемых ФС (ext4, ntfs etc.) Считается, что это происходит из-за того что журнал, находящийся в одном месте, постоянно обновляется и это вызывает очень быстрый износ ячеек.
                                +2
                                Еще бы хотел добавить, что запись всегда в новое место естественным образом реализует выравнивание износа ячеек. Что для твердотельного накопителя плюс.

                                Глупость. В SSD используется таблица трансляции, контроллер каждый раз пишет данные в новое место.


                                Я лично не встречался, но много раз слышал как флешки быстро умирали при использовании журналируемых ФС

                                А вот во флешках контроллер тупой.

                                  0
                                  А куда пишется сама таблица трансляции?
                                    0

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

                                +1
                                Ведь для SSD эта проблема неактуальна

                                Ещё как актуальна, и связано это, в первую очередь, с износом ячеек, а не со скоростью.


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


                                В случае последовательной записи маленькими фрагментами контроллер имеет возможность консолидировать данные и обойтись одной перезаписью, но в случае рандомной записи придётся перезаписывать ячейку на каждый чих. Потому это и приводит к высокому Write Amplification.

                                  0
                                  контроллеру SSD совершенно пофиг, что вы считате рандомной записью, а что последовательной
                                  он забирает из буфера данные, записывает их туда, куда считает нужным и сохраняет операцию у себя в табличке
                                  когда кончаются тримнутые ячейки — да, производительность деградирует, ну так и это тоже забота контроллера, следить, чтобы запас был, а если он не успевает, значит вы выбрали неподходящую для вашей задачи модель
                                    0
                                    контроллеру SSD совершенно пофиг, что вы считате рандомной записью, а что последовательной

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


                                    он забирает из буфера данные, записывает их туда, куда считает нужным и сохраняет операцию у себя в табличке

                                    Контроллер оперирует на уровне блоков флеш-памяти — вот их он и может тасовать как ему вздумается, при этом деградации вскорости не будет.


                                    когда кончаются тримнутые ячейки — да, производительность деградирует, ну так и это тоже забота контроллера, следить, чтобы запас был, а если он не успевает, значит вы выбрали неподходящую для вашей задачи модель

                                    Это не забота контроллера, а забота драйвера файловой системы. Контроллер никак не может узнать, свободна ли ячейка или нет, пока вы ему не скажете об этом явно.

                                      0
                                      Если бы ему было пофиг, то в тестах на скорость записи/чтения не было бы разницы между случайной и последовательной записью.

                                      ну да, не совсем пофиг, внутренний конвейер же тоже страдает, ок

                                      Контроллер оперирует на уровне блоков флеш-памяти — вот их он и может тасовать как ему вздумается, при этом деградации вскорости не будет.

                                      не совсем так, очищен может быть только блок целиком, оперирует контроллер всё-таки традиционными страницами

                                      Контроллер никак не может узнать, свободна ли ячейка или нет, пока вы ему не скажете об этом явно

                                      эмм, так-то контроллер их записывает, читает и удаляет, он обязан знать, где свободные ячейки, а где занятые
                                      ОС вообще не в курсе про этот низкий уровень, для неё любой накопитель выглядит, как набор LBA
                                        0
                                        не совсем так, очищен может быть только блок целиком, оперирует контроллер всё-таки традиционными страницами

                                        Да, это так. Дописать страницу в свободную часть блока — легко, прочитать страницу — легко. Но перезаписать страницу — тяжело, нужна полная очистка блока.


                                        Плюс последовательно идущие логические страницы в итоге все равно должны быть записаны в один блок, иначе будет дико страдать производительность в том числе и на чтение из-за большого количества уровней индирекции.


                                        эмм, так-то контроллер их записывает, читает и удаляет, он обязан знать, где свободные ячейки, а где занятые
                                        ОС вообще не в курсе про этот низкий уровень, для неё любой накопитель выглядит, как набор LBA

                                        Так ОС явно и говорит, что надо почистить. Конечно, есть модели SSD, где физически ячеек больше, чем доступно ОС, этот объём и используется контроллеров для собственных нужд.

                              +2
                              Не могли бы вы указать на конкретные модели ssd, которые вы использовали?
                                0
                                Первый — OCZ Nocti 32 GB msata
                                Второй — Plextor M5M 128 GB msata
                                Сейчас — Samsung EVO 860 256 GB msata.
                                +2
                                вот это цифры… прочитав статью, судорожно полез на свой сервак, в который впихнул 860-ю прошку от самсунга. (они обещают 600 tbw для моего размера — тоже как-то «подозрительно вечный» диск, ну, под мои нужды, конечно)

                                За 6 месяцев — 6 с небольшим терабайт и это сборочный сервак (ci) в отделе из 10 человек, а в статье ноут в монопольном доступе для одного человека — почти 20 тб за 7 месяцев… чудесато…
                                  +1
                                  а в статье ноут в монопольном доступе для одного человека — почти 20 тб за 7 месяцев… чудесато…

                                  Write amplification — ужасная штука

                                  +4

                                  Когда-то, в 2013-2014 был большой и длительный «петабайтный тест». По результатам того теста я купил себе Samsung SSD 850 PRO 256GB.
                                  Он уже работает более 5-и лет и на него записано более 30-и ТиБ. По показометру он исчерпал только 10% ресурса. Я на пенсию раньше выйду чем он помрёт. :-) Этот SSD — единственный в компе, на нем делаю всё, и домашнее, и рабочее. Использую ext4. Каждую ночь делается LVM snapshot и с него обычный инерементарный бэкап на внешнее файлохранилище (tar -g). Раз в неделю делается fstrim, опцию монтирования ФС «discard» не использую.


                                  SMART
                                  # smartctl -i /dev/sda
                                  smartctl 6.6 2016-05-31 r4324 [x86_64-linux-4.19.7-1] (local build)
                                  Copyright (C) 2002-16, Bruce Allen, Christian Franke, www.smartmontools.org
                                  
                                  === START OF INFORMATION SECTION ===
                                  Model Family:     Samsung based SSDs
                                  Device Model:     Samsung SSD 850 PRO 256GB
                                  Serial Number:    S251NXAGB25293J
                                  LU WWN Device Id: 5 002538 8400fe803
                                  Firmware Version: EXM02B6Q
                                  User Capacity:    256 060 514 304 bytes [256 GB]
                                  Sector Size:      512 bytes logical/physical
                                  Rotation Rate:    Solid State Device
                                  Device is:        In smartctl database [for details use: -P show]
                                  ATA Version is:   ACS-2, ATA8-ACS T13/1699-D revision 4c
                                  SATA Version is:  SATA 3.1, 6.0 Gb/s (current: 6.0 Gb/s)
                                  Local Time is:    Tue Nov 19 19:15:32 2019 +03
                                  SMART support is: Available - device has SMART capability.
                                  SMART support is: Enabled
                                  
                                  # smartctl -A /dev/sda
                                  smartctl 6.6 2016-05-31 r4324 [x86_64-linux-4.19.7-1] (local build)
                                  Copyright (C) 2002-16, Bruce Allen, Christian Franke, www.smartmontools.org
                                  
                                  === START OF READ SMART DATA SECTION ===
                                  SMART Attributes Data Structure revision number: 1
                                  Vendor Specific SMART Attributes with Thresholds:
                                  ID# ATTRIBUTE_NAME          FLAG     VALUE WORST THRESH TYPE      UPDATED  WHEN_FAILED RAW_VALUE
                                    5 Reallocated_Sector_Ct   0x0033   100   100   010    Pre-fail  Always       -       0
                                    9 Power_On_Hours          0x0032   090   090   000    Old_age   Always       -       45510
                                   12 Power_Cycle_Count       0x0032   099   099   000    Old_age   Always       -       93
                                  177 Wear_Leveling_Count     0x0013   090   090   000    Pre-fail  Always       -       578
                                  179 Used_Rsvd_Blk_Cnt_Tot   0x0013   100   100   010    Pre-fail  Always       -       0
                                  181 Program_Fail_Cnt_Total  0x0032   100   100   010    Old_age   Always       -       0
                                  182 Erase_Fail_Count_Total  0x0032   100   100   010    Old_age   Always       -       0
                                  183 Runtime_Bad_Block       0x0013   100   100   010    Pre-fail  Always       -       0
                                  187 Uncorrectable_Error_Cnt 0x0032   100   100   000    Old_age   Always       -       0
                                  190 Airflow_Temperature_Cel 0x0032   062   039   000    Old_age   Always       -       38
                                  195 ECC_Error_Rate          0x001a   200   200   000    Old_age   Always       -       0
                                  199 CRC_Error_Count         0x003e   100   100   000    Old_age   Always       -       0
                                  235 POR_Recovery_Count      0x0012   099   099   000    Old_age   Always       -       47
                                  241 Total_LBAs_Written      0x0032   099   099   000    Old_age   Always       -       74207594731

                                  Статья интересная и полезная, спасибо. Никогда не знаешь заранее откуда ждать неприятности, как со спотифаем. Или с очередной ФС. :-)

                                    0

                                    В 2011 году я купил себе OCZ RevoDrive X2 240 GB за $600, использовал его, не жалея ресурса (24/7, виртуалочки, торренты, своп). Записано около 80 ТБ "грязными" (с учётом компрессии компресии контроллером — около 20 ТБ), ресурс выработан всего на 2%.


                                    Скорее PCI-E слоты станут устаревшими, чем выработает ресурс это чудо.

                                  +1
                                  Я только page перенес на хард, но это Винда 7.
                                  +1
                                  > Вывод: не стоит использовать btrfs, если программы часто записывают небольшое количество данных (несколько килобайт)

                                  Одна из ключевых фишек Btrfs — поддержка сжатия на лету (zstd, zlib, lz4). Естественно, далеко не все данные хорошо сжимаются, но некоторые ужимаются очень хорошо, как известно. Так что каковы, в таком случае, будут значения коэффициента усиления записи — вопрос открытый. Понятно, что на размерах в несколько килобайт (то есть одна-две 4k-страницы) вряд ли что-то сильно поменяется, но есть и другие шаблоны записи на диск, естественно. Будет ли в итоге выигрыш, или же нет — вопрос мало того, что открытый, так еще и несколько индивидуальный.

                                  Кроме того, нужно помнить, что Btrfs — использует парадигму Copy-on-Write, что подразумевает лучшее распределение записи по всему объему, а не перезапись in place.
                                    +3
                                    Кроме того, нужно помнить, что Btrfs — использует парадигму Copy-on-Write, что подразумевает лучшее распределение записи по всему объему, а не перезапись in place.
                                    Этим, вообще-то, контроллер SSD занимается, так что перезаписи in place не происходит. Но, может, для HDD какой-то смысл есть? Сомневаюсь…
                                      +1
                                      > Этим, вообще-то, контроллер SSD занимается

                                      1. Использование «вообще-то» какБыНамекает™ звучит так, что информация выше неверна. А это не так.

                                      2. Чем занимается отдельно-взятый контроллер (ресурсы которого, по сравнению с системными, довольно скромные), как правило, известно мало. На Github'е их как-то не много. :) Кроме того, там бывают баги, и даже обновления прошивок, которые, естественно устанавливаются далеко не всеми, и не всегда. Другими словами — шансы получить обновление, на уровне OS, существенно выше, чем на уровне контроллера.

                                      3. Как известно, зачастую трансляция одной парадигмы в другую — менее эффективна, чем изначальное следование целевой. Именно по этой причине для SSD (и прочих накопителей схожих принципов) разрабатываются специализированные файловые системы (например JFFS2), где wear-levelling, опять же, является изначальным свойством самой FS.
                                    +2
                                    Однако за 6 лет я пользуюсь уже третьим SSD: у первого вышел из строя контроллер, а второй начал перемещать данные между ячейками
                                    Контроллер выходит из строя не из-за износа ячеек.
                                    Третий SSD — это значит, что за шесть лет у вас их накрылось два штуки. С нынешним мусорным качеством — вполне в рамках, HDD.бывает, и того меньше живут.
                                      0
                                      Огромная амплификация при записи небольшого количества данных

                                      А ещё есть у SSD одно свойство, что-то вроде необходимости записать все 512 байт «сектора» при записи любой информации. Так, нашел точнее инфу:
                                      Спойлер
                                      Одно из функциональных ограничений SSD заключается в том, что чтение и запись с/на пустой диск происходит очень быстро, а вот перезапись информации в разы медленней. Это из-за того, что когда SSD читает информацию на уровне страницы (в значении отдельных строк в памяти типа NAND) и могут записывать тоже на уровне страницы, предполагая, что окружающие ячейки пусты, они могут удалять данные только на уровне блоков. Это потому, что акт стирания NAND памяти требует большого напряжения. Хотя теоретически вы можете стереть NAND память на уровне страниц, объем требуемого напряжения устанавливается запросом отдельных ячеек вокруг ячейки, которая переписывается. Стирание данных на уровне блока помогает смягчить эту проблему.

                                      То есть «записать 1 байт» так просто не получится. И ещё я не в курсе — как создаются сектора при технологии «3 бита на ячейку» — скажем 512 на 3 не делится.
                                        0
                                        ECC тоже хранить надо, хотя не знаю хранится ли, вроде у твердотельников писали 4кб сектора, хотя у макбуке пишет что там 512
                                          0

                                          3 бита — это, грубо говоря — от 000 до 111 в двоичной системе. То есть делить 512 надо на 8

                                            +3
                                            Что-то Вы не то говорите. 3 бита — это 3 бита. Требуется для задания разделять уровни заряда, которые можно условно сопоставить значениям от 0 до 7.
                                            +1
                                            При чтении/записи SSD оперируют страницами, а не секторами, размер страницы может быть от 2 до 16 кб (зависит от конкретной модели), соответственно запись 1 байта никак не может занять меньше 2K в лучшем случае.

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

                                            Всё усложняется тем что хоть писать и можно на уровне страницы, запись не может быть сделана «поверх» — сначала нужно стереть аж целый блок (состоящий из многих страниц, от 256K до 4M), и только потом писать.

                                            Если пустых страниц нет (диск был записан полностью как минимум один раз, при этом TRIM не использовался — частый случай когда SSD используются в RAID), то всё просто кошмарно — контроллер сначала читает весь блок, где находится тот злосчастный байт, читает его весь (да, до 4M), стирает его и перезаписывает полностью. На самом деле чуть сложнее — он может попытаться начать джонглировать блоками в рамках оптимизации износа и сборки мусора, ища то что реже всего стиралось и перетасовывая найденное в процессе, вовлекая в процесс резервную зону (недоступную для обычного использования).

                                            Разумеется, всё это дорого обходится — производительность падает, и чем дальше тем больше. TRIM помогает сильно улучшить ситуацию, но, как я уже сказал раньше, не все RAID контроллеры его поддерживают (увы), хотя для «домашних» применений (нет RAID и система поддерживает TRIM) всё достаточно неплохо (если диск под завязку не забит).
                                            +2
                                            Статья отличная, но многие читатели спросят:
                                            Почему мой SSD по формуле
                                            Чтобы получить байты, нужно умножить значение параметра на 512.
                                            показывает такое маленькое значение.
                                            241 Total_LBAs_Written 0x0032 100 100 000 Old_age Always - 38360

                                            Что получается очень мало для активного в работе диска
                                            38360 × 512 ÷ 1000 ÷ 1000 ÷ 1000 ÷ 1000 = 0.00001964032 ТБ

                                            На самом деле если обновить базу smartctl
                                            параметр 241 превращается… в Host_Writes_32MiB
                                            241 Host_Writes_32MiB 0x0032 100 100 000 Old_age Always - 38360

                                            И умножать надо на 32MiB, а не 512 байт.
                                              +1
                                              На старых системах базу можно было обновить командой
                                              /usr/sbin/update-smart-drivedb

                                              Но на новых системах после обсуждения
                                              bugs.debian.org/cgi-bin/bugreport.cgi?bug=804299
                                              Такую прекрасную возможность убрали.

                                              Поэтому если в 241 слишком маленькое значение, умножайте его на 32MiB вместо 512 байт.
                                                +2
                                                Если используется Total_LBAs_Written, и SSD оперирует логическими блоками в 4 КиБ, то умножать нужно на 4096, а не на 512.
                                                В общем, надёжней поискать информацию об интерпретации данных SMART на конкретной модели диска в документации или интернете.
                                                +1

                                                Есть ещё такой запрос: smartctl -l devstat /dev/sda


                                                smartctl 7.0 2019-03-31 r4903 [x86_64-linux-5.2.18-100.fc29.x86_64] (local build)
                                                Copyright (C) 2002-18, Bruce Allen, Christian Franke, www.smartmontools.org
                                                
                                                Device Statistics (GP Log 0x04)
                                                Page  Offset Size        Value Flags Description
                                                0x01  =====  =               =  ===  == General Statistics (rev 1) ==
                                                0x01  0x008  4              55  ---  Lifetime Power-On Resets
                                                0x01  0x010  4           19417  ---  Power-on Hours
                                                0x01  0x018  6     59930947692  ---  Logical Sectors Written
                                                0x01  0x028  6     26589423280  ---  Logical Sectors Read
                                                0x04  =====  =               =  ===  == General Errors Statistics (rev 1) ==
                                                0x04  0x008  4               0  ---  Number of Reported Uncorrectable Errors
                                                0x05  =====  =               =  ===  == Temperature Statistics (rev 1) ==
                                                0x05  0x008  1              33  ---  Current Temperature
                                                0x05  0x020  1              33  ---  Highest Temperature
                                                0x05  0x028  1              33  ---  Lowest Temperature
                                                0x06  =====  =               =  ===  == Transport Statistics (rev 1) ==
                                                0x06  0x018  4               3  ---  Number of Interface CRC Errors
                                                0x07  =====  =               =  ===  == Solid State Device Statistics (rev 1) ==
                                                0x07  0x008  1              24  ---  Percentage Used Endurance Indicator
                                                                                |||_ C monitored condition met
                                                                                ||__ D supports DSN
                                                                                |___ N normalized value
                                                

                                                Вообще можно много всякого про свой девайс найти в smartctl --xall ... и потом посмотреть в мане, как получить самое интересное без лишней портянки.

                                                0
                                                Удалено
                                                  +3

                                                  А для zfs кто-то замерял?

                                                    0
                                                    Намучался отучая просыпаться диск на сервере, дольше всего пришлось перепиливать пути для самбы.
                                                      0
                                                      Насколько я знаю, очень сильно зависит от диска. Я бы не стал покупать самые дешевые диски просто потому, что экономия будет небольшая, а, скорее всего, сделано сильное упрощение.
                                                      На хороших дисках запись не должна напрямую вести к записи в ячейку, данные должны накапливаться в оперативной памяти и записываться по мере заполнения. Конечно, усиление записи приведет к увеличению общего количества записанных данных, но от него срок службы не зависит линейно.
                                                      Вторая вещь на что смотреть — размер overprovisioning области. Эта область (как и TRIM) может помочь диску писать намного меньше в ячейки. Некоторые диски позволяют выделять эту область в процентном выражении при помощи утилит. Еще есть вариант сделать secure erase и потом разметить разделы меньше, чем размер диска. Т.о. дать диску возможность использовать эту область для перераспределения данных. Мне кажется, такое сильно поможет особенно в случаях, когда диск под завязку уже записан.
                                                      Для MicroSD это вряд ли поможет, не знаю что там.
                                                      По поводу надежности. По сути, при правильных расчетных параметрах SSD по моему предположению должны были бы быть такие же надежные как и оперативка. В реальности, по моему опыту, в сотнях новых серверов с SSD (хорошего бренда) обычно 5-10 дисков могут не работать прямо с самого начала или получить сбой почти сразу. Далее диски вылетают реже, чем HDD, но намного более часто, чем RAM и достаточно случайным образом.
                                                        +1
                                                        Недавно надоел жутко высокий Load Average и очень низкая скорость работы MySQL на BTRFS с CoW. btrfs balance работал сутками, доводил сервер до почти неотзывчивого состояния и никак не мог завершиться. И это при том, что с самого начала использовал btrfsmaintenance для регулярных автоматических балансировок.
                                                        Нашел статью человека, который сравнил производительность MySQL на BTRFS, где в первом случае БД были на одном разделе с другими данными, в т.ч. системой, как в отдельном подтоме, так и нет, во втором — на отдельном разделе. На общем разделе была огромная (более чем в 10 раз) просадка производительности по сравнению с другими ФС, во втором случае просадка была совсем небольшой. Сейчас статью не получается найти заново.
                                                        К этому времени в связи с невозможностью нормально отбалансировать старый диск (HDD) уже решил все данные через btrfs send | btrfs receive перенести на второй диск такого же размера, затем отключив первый. Заодно решил вынести MySQL в отдельный раздел BTRFS. Стало работать намного быстрее.
                                                        Эта статья заставила задуматься: а как отследить, что именно записывает на диск btrfs и почему? Это, вероятно, поможет понять, почему такая просадка производительности при БД на одном разделе с системой.
                                                          0
                                                          Что-то многовато у вас всего записано. Да, FF любит гадить на диск (про это писали и давно). Но использование tmpfs для /tmp и перенос туда временных директорий для кэша браузеров облегчат жизнь вашему твердотельнику. Вот для примера статистика на моей домашней машине, при том, что время работы диска в 2+ раза больше вашего (комп ночью не выключается):

                                                          === START OF INFORMATION SECTION ===
                                                          Model Family: Samsung based SSDs
                                                          Device Model: Samsung SSD 860 EVO 500GB
                                                          Serial Number: S3Z1NB0K316508K
                                                          LU WWN Device Id: 5 002538 e40207f83
                                                          Firmware Version: RVT01B6Q
                                                          User Capacity: 500,107,862,016 bytes [500 GB]
                                                          Sector Size: 512 bytes logical/physical
                                                          Rotation Rate: Solid State Device
                                                          Form Factor: 2.5 inches
                                                          Device is: In smartctl database [for details use: -P show]
                                                          ATA Version is: ACS-4 T13/BSR INCITS 529 revision 5
                                                          SATA Version is: SATA 3.1, 6.0 Gb/s (current: 6.0 Gb/s)
                                                          Local Time is: Wed Nov 20 00:18:17 2019 EET
                                                          SMART support is: Available — device has SMART capability.
                                                          SMART support is: Enabled

                                                          SMART Attributes Data Structure revision number: 1
                                                          Vendor Specific SMART Attributes with Thresholds:
                                                          ID# ATTRIBUTE_NAME FLAG VALUE WORST THRESH TYPE UPDATED WHEN_FAILED RAW_VALUE
                                                          5 Reallocated_Sector_Ct 0x0033 100 100 010 Pre-fail Always — 0
                                                          9 Power_On_Hours 0x0032 097 097 000 Old_age Always — 11572
                                                          12 Power_Cycle_Count 0x0032 099 099 000 Old_age Always — 248
                                                          177 Wear_Leveling_Count 0x0013 099 099 000 Pre-fail Always — 6
                                                          179 Used_Rsvd_Blk_Cnt_Tot 0x0013 100 100 010 Pre-fail Always — 0
                                                          181 Program_Fail_Cnt_Total 0x0032 100 100 010 Old_age Always — 0
                                                          182 Erase_Fail_Count_Total 0x0032 100 100 010 Old_age Always — 0
                                                          183 Runtime_Bad_Block 0x0013 100 100 010 Pre-fail Always — 0
                                                          187 Uncorrectable_Error_Cnt 0x0032 100 100 000 Old_age Always — 0
                                                          190 Airflow_Temperature_Cel 0x0032 045 028 000 Old_age Always — 55
                                                          195 ECC_Error_Rate 0x001a 200 200 000 Old_age Always — 0
                                                          199 CRC_Error_Count 0x003e 100 100 000 Old_age Always — 0
                                                          235 POR_Recovery_Count 0x0012 099 099 000 Old_age Always — 125
                                                          241 Total_LBAs_Written 0x0032 099 099 000 Old_age Always — 7291759803

                                                          — Всему «виной» одна строчка в fstab:

                                                          tmpfs /tmp tmpfs defaults,noatime,nosuid,nodev,mode=1777,size=8G 0 1

                                                          и в /tmp — директории кэша для браузеров (и Хрома и Фокса).
                                                            0

                                                            После этой статьи обнаружил, что из десятков вкладок в Firefox какие-то несколько постоянно писали что-то в sqlite с куками и примерно в то же время писали что-то UBO с uMatrix. А еще довольно много на диск пишет приложение на Electron.


                                                            Firefox решился установкой расширения-suspender'а, а electron был заменен менее функциональным аналогом на Qt.

                                                            0
                                                            А есть способ узнать какой sql запрос делает Group Speed Dial каждые 30 сек?
                                                              0

                                                              btrace — специфическое ПО для btrfs? Не могу его в арч линуксе найти

                                                              0
                                                              Не ясны причины таких показателей, либо это как-то объясняется с точки зрения архитектуры ФС, либо это неправильные показания соответствующих утилит. Понятно, что CoW, процессы в фоне, но не в 32 раза же…
                                                                +1
                                                                btrace показывает информацию, которое сообщает ядро для блочного устройства. Она должна быть точна.
                                                                Можно посмотреть количество записанной информации с момента загрузки системы вручную, через статистику в /sys/block/sd*/stat, но это не так удобно:
                                                                awk '{printf "Uptime read: %.3fMiB (%.1f%% I/Os merged) written: %.3f MiB (%.1f%% I/Os merged)\n", $3*512/1048576, $2/$1*100, $7*512/1048576, $6/$5*100}' /sys/block/sdb/stat

                                                                Нужно протестировать другую copy-on-write ФС — zfs.
                                                                  +1
                                                                  ZFS работает в обход VFS и, возможно, других API, эти утилиты отработают правильно?
                                                                    0
                                                                    Статистика блочного устройства (btrace) должна считаться правильно, fatrace тоже должен работать, т.к. использует inotify. Насчет iotop — не знаю.
                                                                    0
                                                                    С момента загрузки? Какие-то у меня на XFS дикие цифры выходят. 200Гб за 21 минуту:
                                                                    alekciy@alekciy-myplaycity:~$ uptime 
                                                                     10:55:17 up 21 min,  1 user,  load average: 0,72, 0,41, 0,29
                                                                    alekciy@alekciy-myplaycity:~$ awk '{printf "Uptime read: %.3fMiB (%.1f%% I/Os merged) written: %.3f MiB (%.1f%% I/Os merged)\n", $3*512/1048576, $2/$1*100, $7*512/1048576, $6/$5*100}' /sys/block/sda/stat
                                                                    Uptime read: 1732.387MiB (0.4% I/Os merged) written: 200141.217 MiB (31.4% I/Os merged)
                                                                    
                                                                  –2
                                                                  Вот поэтому у меня swap уехал на hdd.
                                                                    +2
                                                                    Сомнительное «ускорение» работы.
                                                                    Сколько ОЗУ в системе?
                                                                      +1

                                                                      Ага. Это все равно, что купить автомобиль бизнес-класса, но не ездить на нём, потому что жалко. Или купать чайный сервис и поставить его за стекло, а не пользоваться им — вдруг разобьют? Или купить одежду для ребёнка, но не разрешать в ней ходить — вдруг запачкает?

                                                                      0
                                                                      1. Будет ли эта статья на английском?
                                                                      Весьма нужна.

                                                                      2. Что можете сказать о ZFS — так же себя ведёт?
                                                                      На FreeBSD зачастую доступна только она

                                                                      Только полноправные пользователи могут оставлять комментарии. Войдите, пожалуйста.

                                                                      Самое читаемое