Diskuzní fórum Elektro Bastlírny

Netušíte prosím někdo, jak je to s použitím SSD disku při připojení jinak než přes SATA kabel? Konkrétně o SSD umístěný v USB3 rámečku a přes USB kabel komunikující s nějakým zařízením, jako je PC, STB, Androidní telefon nebo Smart televize. Jde mi o to, zda se u těhle zařízení nebudou stále používat stejný oblasti a SSD rychle zdegraduje.
Hledal jsem na netu a našel, že Trim jede až od W7 na klasických AHCI zařízeních ale nejede třeba přes PCIe slot. Netuším, jak to je myšleno, jako že SATA III Axagon řadič zastrčenej v PCIe portu nepodporuje Trim? Já tady mám takhle zapojenýho SSD Kingstona 250GB jako systémový C už asi 7 let a stále maká.
O připojení SSD přes USB řadič není nikde o podpoře Trim ani čárka.
Všude píšou, že to je o komunikaci mezi jádrem operačního systému a řadičem SSD. Když to neproleze skrz PCIe, tak přes USB to proleze a ten šváb v převodníku USB na SATA v rámečku to propustí?
Zase naopak u Androida jsem se dočetl, že od verze 4.3 je Trim podporován. Protože k Androidu jde připojit SSD disk jen přes USB, tak to vypadá, že přes USB Trim prolejzá. Tak nevím...
Jak je to u STB či Smart TV není zase nikde nic o tom, co je v nich za "operační systém" a zda vůbec Trim podporují.
Zkusil jsem u Panasonic 50GX700 připojit SSD v USB3 rámečku Axagon. Po formátu jsem zkusil test rychlosti, vypsalo to jen 26 Mbps. Po nahrání pár pořadů a novým naformátování už ten test rychlosti neproběhne, že by si Panasonic zjistil, že je na něm připojenej SSD a ten test zakáže aby se SSD nedegradoval? Pokud udělám to samý s klasickým HDD, test rychlosti jde spustit kdykoliv.
Nevíte k tomu někdo něco bližšího?

Pro podporu TRIM je nutné mít správný operační systém a taky řadič SSD disku, jenž TRIM podporuje. TRIM je tedy příkaz standardu ATA.
TV a SSD nebudou komunikovat o TRIMu pokud to tam v tom OS není.

SSD disky mají implementované různé strategie pro vyrovnávání opotřebení, které fungují i bez TRIMu. TRIM samozřejmě poskytuje užitečné informace pro algoritmy vyrovnávání opotřebení, ale neznamená to, že bez TRIMU ti to "do roka a do dne" odejde. Primárním účelem TRIMu je zvýšení rychlosti zápisu disku (předvýmaz buněk). Z hlediska vyrovnávání opotřebení je myslím význam TRIMu přeceňován.

TRIM nic nezrychluje, ale ošetřuje jen to, aby se na danou buňku nezapisovalo tak dlouho až to vyhlásí generální pardon, zatímco vedle je těch buněk nevyužitých plno. TRIM bez komunikace s obslužným softwarem přes příkazy ATA prostě nefunguje, to by šlo i v XP atd. Stejně to není důležité, protože jestli to má na filmy, které nemusí hned mazat, tak přepis stejných buněk na začátku se zase tak nekoná. SSD má smysl prto, že jich má plno, jsou tiché a rychlé a houby žerou (ne ty francouzské).

TRIM informuje, kterou oblast lze uvolnit k dalšímu zápisu. To slouži ssd disku k tomu, aby mohl danou oblast v době, kdy nechodí požadavky, předvymazat. Příští zápis do této oblasti tak bude rychlejší, protože buňky už budou vymazané. Kdyby k zápisu mělo dojít na nevymazanou buňku, musí se buňka nejdřív vymazat a pak zapsat, což zabere víc času, než když se jako předem smazaná rovnou jen zapíše. Tím se v podstatě zadarmo docílí zvýšení efektivní rychlosti zápisu.

Tady je je jedno, jestli je to disk zapíchnutej v SATA, v USB, nebo na síti.

Jseš si jistej? Tak proč potom píšou, že Trim nefunguje s disky připojený přes PCIe sběrnu? Je tam doslova napsáno že Trim je podporován jen klasickými AHCI zařízeníma, což disk připojenej přes USB není.
Podpora TRIM
Linux
Jádro Linuxu podporuje příkaz TRIM od prosince 2008. Podpora ATA TRIM příkazu byla přidána v jádře 2.6.33. Automatické využití příkazu TRIM je možné u souborových systémů Ext4, Btrfs, FAT, GFS2 a XFS. Automatické použití TRIM však není implicitně aktivní kvůli možnému zpomalení práce s diskem. Uživatel může podporu zapnout parametrem discard u příkazu mount. Ext3, NLFS2 a OCFS2 poskytují ioctl, která slouží pro offline použití TRIM.
Android
V systému Android je podpora standardně zahrnuta od verze 4.3 (červenec 2013). Příkaz TRIM je spuštěn jen tehdy, pokud je baterie nabita alespoň z 80 % nebo je baterie nabita alespoň z 30 % a systém je zároveň připojen k nabíječce (tj. nejspíše bude proveden při nočním nabíjení telefonu).
Microsoft Windows
V systémech Windows NT je podpora příkazu TRIM od Windows 7 a Windows Server 2008 R2 (říjen 2009), avšak podpora je omezena na klasická AHCI zařízení a nelze jej používat například pro SSD disky v PCI-Express slotech.

Jasně, a v mobilech je SATA, co? Chyba je ve Woknouzu, protože je to 🤐 systém s nesmyslnejma limitama - např. limitovaná kapacita RAM; 32bitovej Linux umí s PAE adresovat až 64GiB, Woknouz asi 3.2-3.5GiB. 64bitovej Linux umí pracovat až se 16EiB (16777216TiB) RAM, Woknouz 10 maximálně se 2TiB v enterprise provedení, u starších a především domácích provedení, hlavně u W7, jsou limity výrazně skromnější.

Z toho, co jsem čistě laicky pochopil, mi vychází, že rovnoměrné opotřebení buněk SSD je věc řadiče a fw, a s trimem to přímo nesouvisí.

USB mass storage zariadenia nepouzivaju ATA prikazy, takze ziadny TRIM nepoznaju. Niektore ale podporuju UAS protokol (USB Attached SCSI), tam by to fungovat mohlo.

MetalGod píše: Chyba je ve Woknouzu, protože je to 🤐 systém

Nojo, to je všecko hezký, že je Wokno paskvil, to víme ale můj dotaz to neřeší.
Budu doufat, že si to rovnoměrný opotřebení řeší řadič SSD a na trim se vykašlu. Myslel jsem, že má zásadnější vliv, v nejhorším to bude trochu pomalejší.
Ale stejně by mě zajímalo, pokud zapíšu na LBA adresu 1H (tedy u klasickýho HDD 1. cylindr, 1. sektor, 1. hlava) jestli ty data jsou opravdu v případě SSD stále na stejným místě a nebo je řadič po dalších mnoha zápisech "přemapuje" někam jinam v rámci svého paměťového prostoru. Kdysi jsem dělal ovladač pro klasickej PATA disk pro osmibitovej počítač takže proto ten zájem. Tam bylo vše stále na stejným místě.

SSD si tie sektory prehadzuje podla potreby - firmware ma pod vrstvou LBA este dalsie vnutorne adresovanie. Takze ked zapisujes len cast bloku, nemusi sa cely blok hned mazat - urobi sa vo volnom bloku jeho kopia uz s upravenymi datami. Povodny sa oznaci ako neplatny a moze sa neskor vymazat.

HDD to dokazu tiez, ale pouziva sa to len v pripade poskodeneho sektora - remapuje sa na dobry sektor z nahradnych.

Kdybys měl možnost vidět, jak jsou na SSD uložený data byť jen jednoho souboru, asi zešedivíš, protože tam ve skutečnosti je fragmentace jako kráva, která ale ničemu vzhledem k téměř nulový přístupový době nevadí. Jenže tady náhodnost nehledej, právě ty fragmenty okupujou bloky, který maj za sebou nejmenší počet přepisů ze všech. O to se bez ohledu na systém, souborovej systém, nebo oddíly stará sám disk.
S TRIMem můžeš jen poněkud zrychlit fyzickej zápis větších souborů (v Linuxu dochází k přímým přepisům omezeně, data k zápisu/přepisu jsou v cache v RAM, která se za určitou definovatelnou dobu vyprázdní do SSD), ale určitě neprodloužíš jeho životnost.
Mimochodem, koukni dolů na data SMART mýho stařičkýho SSD, kterej se nebojím používat jako normální HDD.
Rychlost čtení je po letech kolem 288MiB/s, to máš 2.3Gib/s, zápis 84.5MiB/s, tj. 676Mib/s, přístupová doba ~90µs.

Celeron píše:Jseš si jistej? Tak proč potom píšou, že Trim nefunguje s disky připojený přes PCIe sběrnu? Je tam doslova napsáno že Trim je podporován jen klasickými AHCI zařízeníma, což disk připojenej přes USB není.

To je dané spíš dobou vydání. Tehdy existovaly SATA SSD a pak speciální rychlá SSD na PCIe kartě, což bylo nestandardní řešení závislé na výrobci. Není to o tom, že by to nefungovalo na AHCI řadiči v PCIe slotu, on ten onboard AHCI není připojený jinak. Pokud jde o USB, tak tam je vždy vše nejisté - především záleží na řadiči/převodníku USB/SATA. A je dost možné, že ani se správným to ve Win7 pořádně nepoběží, protože podporu USB3 původně neměly. Jak to MS zbastlil pro USB3 a taky NVMe by mělo být popsáno v KB pod číslem, které tyhle úpravy měly.
Ale používám SSD i pod XP, které trim neumí, a neumírá.