A to je takovy problem pridat RMW vrstvu mezi FAT16/FAT32 a 4KN disk, ktera zajisti behem bootu stejnou funkcionalitu jako 512e rezim?
Analogicky priklad je - kdyby si matematici stezovali, ze exponentem muze byt pouze kladne cislo, protoze zaporny vede k desetinnym vysledkum a koho zajimaj desetiny, ze carku neumi napsat a je to proti jejich vire :D
I kdyby to do bootu dali, tak ani chudák linuxové jádro ten mix 512 na 4096 u FAT nepřimountuje. A to je potřeba pro aktualizace.
Spíš udělají to, že ten jejich Imager detekuje velikost sektoru a pak to na disk dá správně.
Ten FAT problem s 512 vs 4K jsem resil pri automatickem vytvareni virtualek/OS images skriptem ... takze pokud nejde primountovat EFI/BOOT ESP nativne, lze translaci zajistit skrze:
losetup --sector-size $LOGICALSIZE ...
(chvili jsem s tim zapasil a netusil zda je to bug v mkfs.vfat nebo cim to je, ze to blbne)
V skriptu mam komplet radek takto:
SS=512 LS=4096 losetup --sector-size $LS --offset $(( $SS * $offs )) --sizelimit $(( $SS * $size )) /dev/loop$i "$DST"
v cyklu skrze partisny obrazu ktery vytvarim do LVM LV (ktere je 512e tedy). Myslim ze az pozdeji jsem nasel neco, co vytvori loopback device ktery je partitiovatelnej (ale nechtel jsem si tim svinit host OS).
No to je asi "chytrý design" toho FAT. Na diskových sektorech 512 to má logický sektory 512 a na diskových sektorech 4096 to má logický sektory 4096. Jinak to neumí.
EXT4 má logické sektory 4096 na čemkoli. (Nebo i více: https://www.root.cz/zpravicky/ext4-dostane-podporu-bloku-vetsich-nez-stranka-pameti/ )
Spíše dobový design
- IMHO se u FAT ani nepředpokládalo, že by to mělo fungovat na čemkoliv mimo diskety nebo podobné disky. Natož, že by to přežilo až takhle dlouho...!
Ja se prave dival na FAT12/FAT16, ze bych to nasadil prave na storage ruznych dat v 4 ~ 16 MiB eeprom u MCU. Ono to umi totiz sector size 128 a 256, tak by to melo relativne malej overhead (256B * 64K u fat16 je 16M limit).
Jako EXT2 by byla taky moznost (jednoduchej kod), ale jeste jsem nepocital overhead.
A co teprv imaginární exponent na základech kvarternionu. to je analogie, že na raspberry půjde nvme-oF :)
1. 11. 2025, 18:33 editováno autorem komentáře
Až bude Malina mít M2 na základní desce bez HATu, tak si to pořídím.
Ještě místo US-C na napájení by to mohlo mít vobyč DC konektor, páčkový svorky nebo šroubovací svorky.
Skoro to má, IO Board k Compute Module 5 https://rpishop.cz/554165/raspberry-pi-compute-module-5-io-board/
Je na to i docela rozumný case, když to má někde být samostatně postavené.
Tech ruznych moznosti jak k Pi5 pripojit nvme pres pcie konektor je tolik, ze je to spis vyhoda ze to neni primo na desce. Bezpecnejsi argument pro nekoupeni Maliny je treba, ze tam je jen jedna pcie linka, to by mohla byt vetsi tutovka. Protoze treba Pi500+ ma M2 slot na zakladni desce bez HATu :-)
Ten IO module s CM 5 mám jako mikro NAS, ale teď jsem si všiml, že se dá koupit IO module i lepší, třeba https://rpishop.cz/611710/suptronics-x1502-cm5-io-board/#tab-description
Mají verze s 2-8 NVMe a napájení je přes barelový konektor (12V, 5A).
To už se dost blíží požedavkům, ne?
tyjo, povesit 4 nvme disky a mozna jeste 2.5g ethernet (ale ten je mozna usb 3?) na jednu gen2 pcie linku, to je teda odvaha. Pi5 umi gen3 a jsou i HATy s gen3 pcie switchem ale tenhle to podle commentu pod tim nem., Takze 4 disky misto jednoho ale za to pomaleji, a to se vyplati :-)
Záleží na účelu, nějaký domácí NAS, ze kterého se sem tam přehrává film a jinak se tam ukládají třeba fotky, s tím bude fungovat v klidu. Jestli tam chcete hrnout mraky dat, musíte zamířit jinam, třeba jen, aby ty NVMe disky měly nějaké chlazení. A pokud s těmi mraky dat něco děláte, asi to bude chtít i výkonnější procesor.
Domácí NAS má jiné priority: malou spotřebu, nehlučnost, a výkon takový, aby stíhal dodat data - což při převažujícím použití WiFi znamená, že hrdlo bude někde jinde. Víc disků umožní LVM/RAID, to je v této aplikaci důležitější, než rychlost.
Ale jinak ano, gen3 tam dát mohli.