система на hdd несколько минут тормозит.

[~]$ systemctl status man-db
● man-db.service - Daily man-db regeneration
     Loaded: loaded (/usr/lib/systemd/system/man-db.service; static; vendor preset: disabled)
     Active: inactive (dead) since Sat 2021-10-30 19:33:38 EEST; 3h 2min ago
TriggeredBy: ● man-db.timer
       Docs: man:mandb(8)
    Process: 232 ExecStart=/usr/bin/install -d -o root -g root -m 0755 /var/cache/man (code=exited, status=0/SU>
    Process: 236 ExecStart=/usr/bin/find /var/cache/man -type f -name *.gz -atime +6 -delete (code=exited, stat>
    Process: 256 ExecStart=/usr/bin/mandb --quiet (code=exited, status=0/SUCCESS)
   Main PID: 256 (code=exited, status=0/SUCCESS)

[~]$ systemctl status man-db.timer
● man-db.timer - Daily man-db regeneration
     Loaded: loaded (/usr/lib/systemd/system/man-db.timer; disabled; vendor preset: disabled)
     Active: active (waiting) since Sat 2021-10-30 19:33:29 EEST; 3h 2min ago
    Trigger: Sun 2021-10-31 00:00:00 EEST; 1h 23min left
   Triggers: ● man-db.service
       Docs: man:mandb(8)

[~]$ systemd-analyze blame | head -n1
8.958s man-db.service

Aivar
что-то не то.

systemctl status man-db.timer

nafanja
да, когда на SSD посидишь привыкнешь, то видишь на сколько же HDD тормознутый.

vs220
Кешируется со временем с hdd в оперативку и работает уже от туда

vasek
EDIT - уточнение - как пишут, нельзя долго держать SSD без питания - хотя вопрос спорный,

jim945
Это для статистики вам :)

vasek
с внезапным отключением питания

Слава нації

vs220
ext4 без последствий

vasek
не ожидал

Power loss protection (PLP) on SSDs is not a new concept but the applications and techniques to safeguard an SSD during and after a power loss event have largely improved in recent SSD designs. The objective of power loss protection is to accomplish two primary goals:

Safely flush data in-flight (or data that resides in the drive’s DRAM or SRAM cache buffers) to the persistent or non-volatile Flash memory and
Maintain the integrity of the SSD’s mapping table so that the SSD is recognized and useable again upon reboot of the system.
Note: The SSD mapping table, aka Flash Transition Layer (FTL), is responsible for the physical to logical mapping of data on an SSD.

Under a normal system shutdown, the SSD receives a command (Standby Immediate Command) from the host ATA driver alerting the SSD that the system is shutting down and the SSD prepares for power removal. In a normal system shutdown, the SSD has plenty of time to flush its cache buffers and update its mapping tables.

A well-designed SSD will employ a hardware-based design with hold-up power capacitors on-board the SSD and/or a firmware PLP implementation where important metadata information is written to Flash memory to ensure successful recovery of the SSD on the next power up. Kingston currently uses tantalum polymer capacitors for PLP.

Early generation SSDs were not as resilient to sudden power loss as today’s models. It was common for an SSD that experienced a sudden power loss event to become unresponsive on the following power cycle. In a lot of these early cases, the power loss event rendered the SSD unrecoverable and data loss occurred.

9 Power_On_Hours 0x0032 100 100 050 Old_age Always - 5748
174 Unexpect_Power_Loss_Ct 0x0032 100 100 050 Old_age Always - 528

202 Percent_Lifetime_Remain 0x0030 094 094 001 Old_age Offline - 94

Aivar
nafanja, у тебя что-то не то. Вот дефолтное поведение man-db

systemctl status man-db.timer
● man-db.timer - Daily man-db regeneration
     Loaded: loaded (/usr/lib/systemd/system/man-db.timer; disabled; vendor preset: disabled)
     Active: active (waiting) since Sun 2021-10-31 12:00:33 MSK; 11min ago
    Trigger: Mon 2021-11-01 00:00:00 MSK; 11h left
   Triggers: ● man-db.service
       Docs: man:mandb(8)

systemctl status man-db.service
○ man-db.service - Daily man-db regeneration
     Loaded: loaded (/usr/lib/systemd/system/man-db.service; static)
     Active: inactive (dead)
TriggeredBy: ● man-db.timer
       Docs: man:mandb(8)

systemd-analyze blame | grep man-db
1