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

Miniszámítógépek, SBC-k

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.

  • 4271 megtekintés

( locsemege v | 2016. 12. 19., h – 17:35 )

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

( Szenti v | 2016. 12. 19., h – 17:40 )

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

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-…

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

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.

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.

( wachag | 2016. 12. 19., h – 20:45 )

- 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.

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.

( renard | 2016. 12. 19., h – 23:32 )

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.

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

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?

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 :-)

( vl v | 2017. 01. 09., h – 21:41 )

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.

( sigellef | 2017. 01. 09., h – 23:24 )

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

( cyclops | 2017. 01. 10., k – 08:52 )

Ö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.

( pink v | 2017. 01. 10., k – 12:51 )

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.

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!