Az ext4 fájlrendszer case-insensitive funkciójának használata

Fájlrendszer, NAS, storage

Gabriel Krisman Bertazi a Collabora blogon ír arról, hogy az általa fejlesztett, az ext4 fájlrendszerben megtalálható case-insensitive funkció:

  • hogyan engedélyezhető,
  • hogyan készíthető olyan ext4 fájlrendszer, ami támogatja,
  • és végül az, hogy végül is mire jó
Linux 5.2 was released over one year ago and with it, a new feature was added to support optimized case-insensitive file name lookups in the Ext4 filesystem - the first of native Linux filesystems to do it. Now, one year after this quite controversial feature was made available, Collabora and others keep building on top of it to make it more and more useful for system developers and end users. Therefore, this seems like a good time as any to take a look on why this was merged, and how to put it to work.

Az írás elolvasható itt.

( zolti v | 2020. 08. 28., p – 09:12 )

Hasznos feature :(

Vajon mi késztette erre ? 

Igen, én is eddig olvastam. 

Balblablabla
[...]
The end result is clear: a much more user-friendly Linux experience for end-users and a much better platform to run beloved Windows games with Steam on Linux.
[...]
Blablabla

Szóval a windóz miatt kell. Az nem világos, hogy ezt miért kell kernel és fs szinten megoldani, mikor ott van maga a steam és a windows emuláció mint köztes réteg.

Mi jön még? A futtatható fájlok exe kiterjesztéssel való ellátása, mert az a much more user-friendly Linux experience for end-users? Legalábbis azoknak, akik windowson nőttek fel és másban is ezt keresik. 

Pl. a Sambának ez marha jól fof jönni, mert ott protokoll-szinten case insensitive a dolog, ha nem engedélyezed neki a normalizálást és standard gagyi szar SW használja (ami random case-ekkel éri el a fájljait), legrosszabb esetben rekurzívan (!) kell könyvtár listákat lekérnie, ami retek sok kernel hívással jár, vagyis lassú.

BlackY

"Gyakran hasznos ugyanis, ha számlálni tudjuk, hányszor futott le már egy végtelenciklus." (haroldking)

( sigellef | 2020. 08. 28., p – 09:44 )

... hát... eljött volna az idő a Linux rendszerszintű lebutítására???

-fs-
Az olyan tárgyakat, amik képesek az mc futtatására, munkaeszköznek nevezzük.

hogy a telepítő alapértelmezetten ilyen FS-t hozzon létre

Most még lehet hogy ezt humoros felvetésnek tartod ami majd sohanapja után két héttel (se...) történik meg, de én ugyanilyen szinten lehetetlennek tartottam volna korábban, hogy a mainstream Linux disztrók többsége (sőt, talán mára már mindegyik is?) alapértelmezetten systemd-vel van ellátva...

Akárhogyis, már Einstein megmondta, hogy két dolog végtelen: a Világegyetem és az emberi butaság. De aztán kis gondolkodás után óvatosan hozzátette, hogy az elsőként említettben azért nem teljesen biztos...

Tehát a butaság végtelenségében azért biztos volt az öreg. S ahogy én idősödöm én is egyre biztosabb vagyok benne.

Szóval, ez a szóbanforgó izémizé szerintem sokak szemében egy „kényelmi feature” lesz. Márpedig a Történelem arra tanít, hogy minden, de MINDEN ami fokozza az emberek kényelmét, megállíthatatlanul elterjed előbb-utóbb!

A Windows miért elterjedtebb még most is mint a Linux? Egyszerűen azért, mert hiába szar, hiába kerül pénzbe, hiába... (akármi ide tehető) de a LUSTA és/vagy OSTOBA felhasználóknak kényelmesebb!

Akik tehát e lusta/ostoba felhasználókat akarják majd kiszolgálni akármiért is (például mert belőlük van a bevételük...) azok igenis alapértelmezetté teszik majd ezt a ficsőrt. A többiek meg majd kénytelenek lesznek követni őket kompatibilitási okokból. Idővel egyszerűen ez lesz a „de facto” szabvány.

Idővel meg majd már a magamfajta vén, maradi különcök is meg kell hajoljanak előtte, egyszerűen mert megjelennek azok a programok amik maguk eleve arra építenek hogy ilyen a fájlrendszer, azaz én hiába nem így készítem majd el a magam ext4-ét, de akkor nem tudom használni rajta tisztességesen a modern programokat se. Most mondhatod, azok a programok szar programok. Igen, az én szememben is annak számítanak majd. Ennek ellenére, van az úgy hogy muszáj épp a szar programot használni. Mert más nincs, vagy mert mittudomén egyes google szolgáltatások vagy weblapok kikövetelik épp a legfrissebb webbrowser használatát, de az ilyen szarul van megírva, stb.

Rémeket látok? Lehet. Örülnék neki ha úgy volna. De nagyon szkeptikus vagyok.

( egmont | 2020. 08. 28., p – 10:24 )

Azabaaaj, hogy a case insensitivity függ a nyelvtől, írástól. Például a törökben az ı párja az I, míg az i párja az İ. Ezt csak olyan réteg tudhatja helyesen kezelni, amelyik ismeri az aktuális (per-process) nyelv fogalmát. És a kernel nem ez a réteg, ez libc-ben, a kernel fölött van implementálva.

Hogyan lehetne ezt megoldani?

- Azt mondjuk, hogy leszarjuk, nem törődünk az ilyen különc nyelvekkel. Miközben a libc törődik és jól megoldja már, tehát ez egyértelműen visszalépés.

- Fájlrendszer szintjén, vagy globálisan (kernel szinten) lehessen beállítani a nyelvet. És akkor jön a csomó fejlesztő, aki létrehozza a pistike.txt-t, majd kiolvassa a PISTIKE.TXT-t és a török userek pampognak hogy nem működik. Újabb hibalehetőség, ami senkinek nem hiányzik, fejlesztők rémálma, tesztelhetetlen.

- App szintjén lehessen beállítani a nyelvet. És persze akkor valahogy közölni kell a kernellel, új API kell, lássuk hány fejlesztő fogja beizzítani. Vagy legalább a glibc-be kell belehegeszteni hogy a setlocale() szól a kernelnek is. Na meg akkor a newlocale(), szálankénti cuccok, *_l() függvényhívások mit is csináljanak pontosan. Szintén nem egy leányálom.

Baromságnak tartom az egészet, a problémát sokkal rugalmasabban, jobban lehet kezelni libc-ben illetve user kódban. A megoldás oda való.

Magyarban simán menne az UTF-8 ékezetváltás.

 

Á - C3 81

á - C3 A1

 

Kis odafigyeléssel meg lehetne oldani. Úgy van a tábla rendezve, hogy az 5. bitet forgatni kell.

 

Persze ahogy látom, vannak részek, ahol az UTF tábla össze-vissza van. Mindenesetre nem extrém bonyolult a feladat.

( Caro | 2020. 08. 29., szo – 02:35 )

Mondjuk van olyan perverz ember, aki kihasználta valaha a fájlrendszer case-sensitivity-jét? Értsd, kellett neki egy video és egy Video, meg talán egy VIDEO mappa is?

Linux alatt úgy tudtam nem használunk nagybetűket, még forráskódban sem, csak KONSTANSOKRA :)

Nekem olyan esetem volt, hogy volt egy mappa a lemezemen sok fájllal. Ebbe át akartam másolni egy csomó másik fájlt (zenékről volt szó amúgy) egy csatlakoztatott pendrive-ról. A pendrive-on FAT fájlrendszer volt, mondhatnám hogy „természtesen”, mert egy Windowst használó havertól kaptam, ő küldött nekem rajta zenéket. Na és a másolás meg is történt, aztán később elkezdtem nézegetni a mappát az új zeneszámok végett, és akkor láttam több (kb fél tucat...!) olyan zenét aminek a neve tök azonos volt, kivéve hogy az egyikben szerepelt egy vagy több NAGY betű is ott ahol a másik fájlnévben kis betű volt... És ezek amúgy különböző zeneszámok voltak! Vagy ha mégse volt maga a szám különböző „elméletileg”, de olyan szempontból igen hogy ugyanazon zeneszám más feldolgozása...

És ekkor én igencsak örültem hogy a fájlrendszerem case-sensitive, mert különben felülírta volna a másolás folyamata az új számokkal a régi számokat, holott ezt semmiképp se óhajtottam volna.

Oké, most lehet azzal jönni hülye voltam, külön mappába kellett volna másolnom eredetileg is. Ennek ellenére, a helyzet az hogy így elkerültem egy potenciális - bár nem katasztrofális - adatvesztést.

Nem tudom mivel másoltál, de a legtöbb program ilyenkor rákérdez, hogy biztosan felül akarod-e írni az ütköző fájlokat. Desktop Linuxokon általában még a cp is aliasolva van cp -i-re. Ha csak nem választod reflexből, hogy írjon felül mindent (ami innentől PEBKAC), ez case-insensitive fájlrendszeren sem okoz problémát.

( timi | 2020. 08. 29., szo – 10:06 )

MacOS-sen van (Case-insensitive) Journaled és Case-sensitive Journaled HFS+

Vannak problémák Case-sensitive Journaled-del például Adobe szoftverekkel vagy a most szóban forgó Valve Steamjével is.