Költői kérdés egy régi-régi fájlrendszerről

 ( bzs | 2016. december 19., hétfő - 18:30 )

Sziasztok.

Mesebeli talány előttem mind a mai napig.

Amióta Raspberryt használok, a kérdés egyre élesebben rajzolódik ki előttem.
Ha adott bármilyen linux disztribúció, aminek van egy külön 6boot partíciója, miért pont fat16-os fájlrendszerre íródik mindez? Csak azért, hogy vadul sérülhessen, vagy valami mély technikai oka van?

Másik kérdés, ami szintén vad:
fényképezőgépeknél, videokameráknál miért csak egyféle fájlrendszert használ a szerkezet, pláne olyat, ami szintén sérülékeny?

Nem feltétlenül várok választ, éppen a dühömet vezetem le írással, mert álmomban nem gondoltam volna, hogy egy upgrade-megszakadás szétgyilkolhat egy raspberryre tervezett oprendszert. Természetesen van backup, mint mindig. De hát mégis...

Na, ez egy szép topiknyitó.

----------
Topiknyitó oka: leállt a distribfrissítés, áramszünet, sérült a /boot partíció, és a júzer (én) azt hitte, meghalt az RPI, mert nem villogott bootoláskor a led. Dühlevezetés a fájlrendszer mibenlétén zajlik, pohárdobálás helyett.

Hozzászólás megjelenítési lehetőségek

A választott hozzászólás megjelenítési mód a „Beállítás” gombbal rögzíthető.

Mi az, hogy íródik? Nem olyan a /boot, amilyenre formázod? A fényképezőgép szerintem azért, mert a FAT faék egyszerűségű, s mindegyik oprendszer biztosan ismeri. Ha sérül, legfeljebb újra lesz inicializálva a filerendszer. Itt a konzisztencia nem túl érdekes. Mire mennél vele? Attól, hogy konzisztens a filerendszered, még lehet adatvesztésed, csak annyi, hogy egy régebbi jó állapot lesz. De ennek semmi lényege, hiszen nem a kártyán kell tárolni a képeket. Csak addig tartod ott, míg letöltöd a gépre.


tr '[:lower:]' '[:upper:]' <<<locsemege
LOCSEMEGE

raspbianoknál és arch-nál a boot bizony nem olyan, amire formázod.

A fényképezőgépnél a faék egyszerűségben igazad lehet. De mégis: szóval CSAK azért, mert az a legprimitívebb...?

---
--- A gond akkor van, ha látszólag minden működik. ---
---

Csak tippelek.
Broadcom chip spec módon boot-ol, és a filerendszer implementáció nem vihet el sok helyet.

Hmm.
Lehet, hogy mégsem költői a kérdésem

---
--- A gond akkor van, ha látszólag minden működik. ---
---

Csak neked költői.
Amúgy meg minden évben felteszi egy laikus ezt a kérdést.

Laikus ilyet nem tesz fel, mert nemhogy fájlrendszerekről, de partíciós táblákról sem tud semmit

Mindenfajta trollkodás nélkül, de a költői kérdés az amire nem vársz választ...

Gondolom azért FAT16 a /boot, mert az van implementálva a hardverbe.

Valószínűleg. De miért pont az? Mert az a legegyszerűbb, vagy mert a m$-nak abból is haszna van?

---
--- A gond akkor van, ha látszólag minden működik. ---
---

A Microsoftnak "mindenből" haszna van. Az Androidból is marha sok, mivel irgalmatlan mennyiségű kütyün az fut.

Microsoft makes much more money from Android than Windows Phone. Every time you buy an Android smartphone or tablet, Microsoft is likely receiving $5 to $15. They likely make at least $2 billion per year from Android.
http://www.howtogeek.com/183766/why-microsoft-makes-5-to-15-from-every-android-device-sold/

Mi a halál haszon van a szar FAT16-on vagy 32-n?

Ez nem olyan, mint a formatervezett dolgokon, hogy 10%-ot változtatsz rajta és az már új termék.

---
--- A gond akkor van, ha látszólag minden működik. ---
---

a felhasználók közt sok olyan is van, aki még nem látott linuxot. Ők legalább látják win alatt, hogy van ott valami. Esetleg meg is tudják szerkeszteni a config.txt-t. Később pedig azért panaszkodnak, hogy "elrontotta a kártyát", mert csak 512MB-osnak látja (az első partició) :D

FAT írás-olvasás még a lassan 35 éves ZX Spectrumra is van implementálva. Még én is írtam ilyet assemblyben jó régen. Szóval ja, ez a legegyszerűbb.

A szalagra Fat-tal írt? Mik derülnek ki 26-28 év után..

---
--- A gond akkor van, ha látszólag minden működik. ---
---

Azért ott sem állt meg az élet :)

http://divide.cz/index.php

http://esxdos.org

A legjobb, hogy 1 db 2 gigás CF kártyára elfér az összes program, amit valaha írtak rá.

Pontosan ezért (még pontosabban: FAT32 is lehet, mert azt is ismeri).

The Raspberry Pi’s Broadcom BCM2835 system on a chip (SoC) powers up with its ARM1176JZF-S 700 MHz processor held in reset. The VideoCore IV GPU core is responsible for booting the system. It loads the first stage bootloader from a ROM embedded within the SoC. The first stage bootloader is designed to load the second stage bootloader (bootcode.bin) from a FAT32 or FAT16 filesystem on the SD Card.

Az igazán költői kérdés az, hogy miért kellett így megoldaniuk, miért nem volt nekik jó az, ahogy egy jó PC csinálja (MBR, aktív partíció, boot sector)

Mert a PC az egy definialt architektura, mig az ARM az csak egy CPU ISA. Nincs definialva, hogy ARM lapok eseten mi a szabvanyos, egymassal kompatibilis megoldas, ezert nincs is ilyen, minden gyarto maga szarakodik midnennel, ahogy neki tetszik.

Ez oké, te azt mondod, hogy nem volt muszáj a "megszokott" módszert követniük. De attól még, hogy valami nem muszáj, lehetőségként ott van :)

Valószínűleg nincs a PC BIOS-hoz hasonló a SoC-ban, ezért először azt kellett volna megírni, csak azért, hogy betöltsenek pár blokkot az SD kártyáról és/vagy hogy menüből lehessen tekergetni azt, amit amúgy a config.txt-ben egyszer-egyszer beállítok.

Félreérted amit írtam. Én csupán a rendszerbetöltésről beszéltem, nem biosról vagy config.txt kezelésről.

- Egy FATfs olvasót egy tepsi olajos halon kívül kb. mindenen meg tudsz valósítani, se hely, se memória, se idő, se igényesség nem kell hozzá
- Miért nem read only mountolod, ha nem akarod, hogy sérüljön? A /boot tipikusan lehet ro.

+1
+1

+1
- mert épp updatelte?

Te mikor updatelsz boot partíciót? (Nem a linuxos /boot, hanem RPi boot vagy EFI boot)

RPi boot:
Egyrészt a config.txt-t szerkeszthetem manuálisan, a raspi-config tool is hozzányúl, sőt, néhány kodis disztrónál a kodin belül van lehetőség olyasmiket állítani, ami a config.txt-t módosítja.
Másrészt nem tartanám kizártnak, hogy egy frissítéssel frissebb bootloader érkezzen.

EFI:
Ebben nem vagyok 100% biztos, de Ubuntu esetenként hozzányúl, ha a grub környékén frissül valami.

Egy érdekesség: Ha UEFI-t használsz, az EFI rendszerpartíciónak is FAT kell (FAT32). Erősen meglepődtem, amikor ezzel először találkoztam, de attól még így van.

Ezen én is elképedtem. Ez lenne a fejlődés?


tr '[:lower:]' '[:upper:]' <<<locsemege
LOCSEMEGE

Hát, van az UEFI-ben egy U betű, az adhat magyarázatot.

Az miben jobb, hogy beolvasom az adathordozó első szektorát, és azt kezdem futtatni? Akármi is legyen benne...
Mondom ezt úgy, hogy kifejezetten nem értem, hogy miért kellett a régi boot rendszert megbolygatni.

Szerintem az egy logikus, egyszerű megoldás, de nagyon sovány az az egy szektor. Sőt, kevesebb, mert a partíciós tábla is ott van.


tr '[:lower:]' '[:upper:]' <<<locsemege
LOCSEMEGE

Jaja, csak epp a mai szupermodern x64-es procik is kenyetelenek miatta a 30 eves real mode-ban bootolni, hogy ez igy meg mindig mukodjon. Ami penz es ido, tesztelgetni, esatobbi. Jo lenne vegre megszabadulni tole.

Az, hogy nem minden esetben jelenti ugyanazt a dolgot, hogy "az adathordozó első szektora". Például egy SSD/HDD esetén is egy 512 byteos szektorokkal rendelkező vagy éppen 4 kilobyteos szektorokkal rendelkező lemez már más.

Az, hogy mit kell bootolni, logikai dolog (absztrakció): a boot file-t. A filerendszer pedig elabsztrahálja neked, hogy ez a boot file hány fizikai szektorra mappelődik le. Nem pedig egy fizikai, adathordozótól függő dolgot.

Na meg miért legyen 512 byte a limit a boot kód esetén? Amikor jó esetben egy bootloader ma már egy csomó filerendszert vagy éppen filerendszer kiterjesztést ismer, hogy a root FS sokféle lehessen.

Az UEFI-s megoldással nincs szükség n stage bootloaderre (mint a Grub), egy darab file betöltésével átadható a vezérlés, nem kell szarakodni.

A "töltsük be az első szektort, 512 byte-ban úgyis elfér minden" pont ugyanaz a korlátos gondolkodás, mint a "640kbyte mindenre elég".

A "töltsük be az első szektort, 512 byte-ban úgyis elfér minden" pont ugyanaz a korlátos gondolkodás, mint a "640kbyte mindenre elég".

Az mondjuk tényleg mindenre elég, csak elszemtelenedtek a programozók, és nem tudnak programozni. :D


tr '[:lower:]' '[:upper:]' <<<locsemege
LOCSEMEGE

Mindenre ufgyan nem elég, de tényleg elszemtelenedtek. Kollega múltkor valami vindozt telepített, driverek közül az egyiknek .net X.Y kellett a telepítéshez, egy másik pedig 800 megás volt. Nem elírás, nyolcszáz. Megabyte.

Ezen én is elhűltem, amikor kolléga új laptopjához egyikfajta wifi drájver 140 mega volt, a másik pedig 260. Hát izé.

De azért szerencsére nem akkora szörnyűség a Windows-világ - ugyanez Linux alatt is létezik: a linuxos usb_modeswicth utilitás működéséhez kell shell (mert vannak benne shell-scriptek), valamint vagy perl vagy python (nem emlékszem már), mert valami eléggé triviális lépést viszont abban implementált az a drágalátos programozó (amit kb ugyanolyan erővel megtehetett volna shellből is). Lehet mondani, hogy de ezek minden OS-terjesztésben alapból elérhetők (már ez sem igaz, van ahol nem; ráadásul ha ezt jogosan utáljuk Win alatt a dotnettel, akkor it is utáljuk), de attól még fölöslegesen erőforráspazarló 3-féle futtatókörnyezetet berántani azért, hogy egy X.Y ID-jű eszközre rátoljunk egy UVZ szekvenciát.

/OT
=====
tl;dr
Egy-két mondatban leírnátok, hogy lehet ellopni egy bitcoin-t?

Nem a driverhez kell a .net, hanem az OEM bloatware-hez...

Ha megnezed az a nehany 10-100 .inf .cat .dll .sys nem lesz tobb mint 30-50MB...

--

"You can hide a semi truck in 300 lines of code"

Sajnos ez ilyen.

Az én gépemen KDE van, meg egy halom gnome csomag, mert mindenféle csomagoknak a függőségei behúzzák ezeket.

Ugyanígy Ruby például. Soha az életben nem írtam ruby programot, nem is hiszem, hogy valaha fogok, de mindig ott van, mert van 1-2 csomag, amiben kell. Mert valaki úgy gondolta, hogy egy feladathoz neki épp ez a kényelmes.

Perl, python sem az én igényem miatt települ, de ezeket legalább sok csomag használja, szóval így az overhead szétoszlik :-)

leállt a distribfrissítés, áramszünet

Örülj neki, hogy az SD kártyád nem pukkant el ennyitől... az SD kártya és az áramszünet nem barátok.

bootmanager, bzImage, esetleg initrd meg néhány fájl van a /boot-ban, minek bonyolítani, jó a legegyszerűbb fájlrendszer. Egy rosszul időzített áramszünet meg akármilyen fájlrendszert összezagyválhat.
A /boot partíciók amúgy is akkorák, hogy ezek épphogy elférnek, tehát felülíráskor már jó eséllyel azok a szektorok is íródnak, ami a régi fájlhoz tartozik. Hiába lenne ext4, vagy egyéb okosság, a félig felülírt fájllal már nem tudna mit tenni.

Videókameránál meg szempont, hogy minél kevesebb "mellékadat" íródjon, meg minél kevesebb számítást kelljen végezni fájlíráshoz. Legideálisabb, ha szektorfolytonosan tudja írni a tárolóra az adatot,
max azt ellenőrzi, hogy szabad-e az adott szektor, meg jegyzi a FAT-ban, hogy lefoglalta.

-fs-
Az olyan tárgyakat, amik képesek az mc futtatására, munkaeszköznek nevezzük.
/usr/lib/libasound.so --gágágágá --lilaliba

Örülj inkább, hogy ilyen olcsón megúsztad: a kommersz SD kártyáknál az áramszünet olyat is okozhat -- ha írás közben történik --, hogy a kártyában megvalósított FTL (Flash Translation Layer) adatai sérülnek meg és a következő bekapcsoláskor 0 bájtos médiaként látszódik.

Régebben jellemző volt, hogy sok kompakt fényképezőgépen DOS volt az alaprendszer. Manapság nem tudom, mi a helyzet.
Nem olyan rossz egyébként a FAT, hordozható adattárolókra kiváló. Nem kezel jogosultságokat --> megúszod az ebből eredő szopást.
Az egyetlen fájdalmam, hogy legjobb esetben is FAT32-t ismer általában az eszköz. Pedig ott volna az exFAT, aminek nincsenek meg a címzés miatti korlátai. Ilyen helyre ez tökéletes lenne.
Milyen jó is a haver NTFS-es külső vinyója, amit csak adminként lehet olvasni az access control miatt.

Raspberry-n csak a konfig partíció (vagy minek hívják) FAT, azt meg kb. úgyse írod soha.

Hívjuk csak boot-partíciónak (ha már egyszer arról bootol), és sajnos valahányszor módosul valami a bootban, illetve hát persze rendszer konfig piszkálásakor azért módosul.

=====
tl;dr
Egy-két mondatban leírnátok, hogy lehet ellopni egy bitcoin-t?

A gyakorlatban számomra még nem okozott problémát több éves RPi használat során.
NFS szervernek és médialejátszónak vannak beállítva a Pi-k, illetve van egy játszós.
Azt se felejtsük el, hogy kis méretű partíciók esetén már jelentős lehet a modernebb fájlrendszerek által ,,elpazarolt'' hely is.

exFAT for prezident!