Block size > 4k ?

Linux-kezdő

Üdv mindenkinek, aki elolvassa !

Most kezdtem nemrég a linuxos pályafutásom és azt tapasztaltam, hogy nem tudok 4k-nál nagyobb blokkméretet kezelni. Ugyan a reiserfs 3 támogatja a nagyobb méretet (64k-s particiciót sikerült is kreálnom), de mount-olni már nem tudom....és egy man-ban azt olvastam hogy "only 4k is supported". Tehát csak akkor tudom mountolni ha 4k. Kisebbet nem próbáltam.

Egy 80 GB-os partícion tárolnék nagyobb file-okat.....úgy érzem szükségtelen ilyen kicsi blokkméret, és úgy tudom hogy nagyobb bméret esetén a leíró bejegyzések száma is kevesebb lesz.
jelenleg elég kevés RAM van a gépben, elképzelhető hogy a bejegyzések egy része ott tárolódik?

NTFS-ben megszoktam már hogy a nagy file-oknak nagy cluster, a kicsiknek kicsi.

Vélemény? Tapasztalat?

Kerestem fórumokat itt, de ilyen témájút nem találtam.

  • 1425 megtekintés

( Celtic v | 2006. 04. 19., sze – 14:34 )

Ha eccer only 4k, akkor annyi, ne akard megeroszakolni :)
Ha nagy file-ok, akkor ugye kevesen vannak es kitoltik a blokkokat. Tudomisen, 20 dvd image, akkor az osszesen 20 blokk lesz, ahol nem lesz kitoltve a 4k. Nem veszes a veszteseg (bar mintha a reiser kezelne toredek blokkokat is, de ez nem biztos)
Hasznalj ext3-at, ott asszem 1/2K-4K lehet a blokkmeret.
(De nekem elobb fogyott el a helyem reiserfs es ext3 alatt is, mintsem az inode-tabla betelt volna :)

( zoli78 | 2006. 04. 19., sze – 17:14 )

Üdvözlünk az operációs rendszerek világában!
Felejtsd el a rossz m$-os beidegződéseidet, itt másképp mennek a dolgok. Egy percig se aggódj a blokkméret miatt, a linuxnak nagyon jól megírt fájlrendszer-kezelői vannak.
Amúgy miért akarsz egyből reiserfs-t használni? Kezdőként inkább az ext3-at ajánlanám, stabil, gyors és mindent tud, amire kezdőként szükséged lehet és nagyon jó támogatással rendelkezik.
Ha mélyebben érdekel a téma, akkor érdemes utána olvasnod, mert az ext3-ban vannak olyan dolgok, amit érdemes megismerned (pl. hogy hogyan kerüli el a fragmentációt, hogyan tárolja a szervezési információkat, hogyan lehet bekonfigurálni, stb.)

kétlem, hogy magyarul találsz erről bármilyen leírást is.
Amúgy meg fájlrendszer (second extended filesystem) faq-k, howto-k és guide-ok olvasgatását ajánlom. Valamelyikben már olvastam arról a technikájáról, amivel megelőzi, hogy apró darabokra essen szét egy fájl. Lényegében arról van szó, hogy a blokkok lefoglalásakor nem egyet foglal le, hanem többet is.
A reiserfs is használ valamilyen megoldást (és igen, ott egy blokkban lehet több fájl maradékja is).

Eloszor is butasagokat irsz, nem szeretem a win*-ot de ettol meg van olyan verzioja ami oprencer. Attol, hogy a linuxban altalaban valami "jol megirt" nem mondhato el hogy minden az. Valamint, ha a kerdes nem erre vonatkozik ne terelj.
Tehat alapvetoen architectura fuggo milyen maximalis blokkmerete lehet egy filrendszernek alapvetoen elmondhato hogy x86-on 4k ennek kotodese a PAGE_CACHE_SIZE-hez jellemzo.
Alapvetoen nem ajanlott kezdokent a disztribuciodon beallitott alap file rendszer modositasa, probakepp masik particion kiserletezz. Igazad van a 64k blokkmeret jobb lenne, kisebb memoria felhasznalas lenne, ettol meg jellemzoen nem itt kell sporolni.
A javaslat jo. ext3-at probaltd, ha szeretnel ettol gyokeresen elterot, akkor inkabb xfs, de vigyazz, backup legyen.
Mai linuxokon szamtalan filerendszertipust kezelhetsz egyidoben, jo kiserletezest!

Bár némileg off, de... jól értem, te windows környékén is képben vagy?
Én is a blokkméretekkel vagyok gondban, de pillanatnyilag windows alatt. XP Professional 1G RAM mellett érdemes játszadozni ezzel a paraméterrel? Performanciában jelenthet valami javulást akár a kisebb, akár a nagyobb méret? (frissen formázott partícióra próbáltam másolgatni, azon nem látszott eltérés de üzemi körülmények közt nem tudom, jelenthet e valamit)
--------------
Fel! Támadunk!

A windows flame-en kívül mi volt butaság? A memória lapmérethez ugyanmár mi köze van a fájlrendszer lapméretének?
Különben is már pár éve nem csak 4K lehet a memória lapmérete, hanem jóval nagyobb is.
A hozzászólásod többi részében meg gyakorlatilag nekem adtál igazat, úgyhogy nem értem miért kellett leszólnod.

Kerlek, nem hiszem hogy arrol szolna ez a forum, hogy az en alapvetoen laikus szemleletu eloadasomat kellene vegighallgatni mi koze az egyik dolognak a masikhoz. Batran nezz utanna.
A bajom az volt az irasoddal: terelsz. A ficko kerdest tett fel, te meg leirtad amit gondolsz. Ez szofosas. Bantani nem akartalak, mert amit ajanlottal az jo. Azonban ezek alapvetoen nem tartoztak a valasz kategoriajaba. Emellett leszoltad az ntfs-t ami ha nem lenne ennyire elbonyolitva, nem is lenne oly rosz valasztas.

Kezdőnek miért ajánlasz inkább ext3-at? Mert fájlrendszerekben én se vagyok profi, de van egy reiser3-as partícióm. Annyit veszek észre rajta, hogy hibás leállás után sokkal gyorsabban észhez tér. Az ext3 nem, amint nem csodálkozom, mert úgy tudom, az ,,csak'' egy naplózással megfejelt ext2.

Mert nem a naplozasrol es magahoz teresrol volt szo, hanem arrol, hogy ne fix blokkmeret legyen.
Mit ne moindjak, en is mostanaban kezdem mindenhol lecserelni a reisert ext3-ra. (nagy file-ok mozgatasanal lehalt ugy nalam a reiser, hogy csak a reboot segitett, aztan se itt, se ott nem volt meg a file). Tudom, masolas es torles ezutan,
de mar megtortent, es minthogy nem egyszer, inkabb fs-t cserelek.
Mondjuk, a hibas leallas es ujraindulas amugy sem jellemzo a gepemen.

Az eredeti kérdésemre senki se tudott választ adni sajna....
azért használok reiserfs-t mert így találtam, a telepítő is úgy írta hogy ezt érdemes, ezen most nem fogunk vitázni. Jobban tetszett a színe mittudomén.

1G RAM?
Az én samba szerveremben csak 32MB van, így is működik, de gondoltam arra, hogyan lehetne nagyobb blokkméretet....de azt nem tudom mennyire befolyásolná a memória használatot. Abban biztos vagyok hogy a háttértár kezelőnek kevesebb dolga lenne valamennyivel

Példa hogy miért tűnik nekem jobbnak nagyobb blokkméret nagy file-oknál: van egy naaaagyon nagy kenyerem és el kell raknom a zsebeimbe. Tegyük fel hogy választhatok többféle kabát közül, mindegyik más zsebméretekkel rendelkezik. Én azt a kabátot választanám, amelyiknek nagyobbak a zsebei, így a kenyeret kevesebb részre kell szétszednem és így kevesebb zsebet kell nyílvántartanom. Egy így szerintem egyszerűbb lenne, nem?

Ezért nem értem hogy miért nem lehet nagyobbat fel-mountolni....

Egyszer azt olvastam, hogy NT szervereknél a swap-ot egy külön HDD-re pakolták NAGY clusterméretekkel, ami nekem nagyon logikusnak tűnik. Ezáltal gyorsabb a swap-olás.

Viszont tegnap beszéltem 2 kollégával és azt mondták, hogy a 4k-t használnak 200 GB-os HDD-hez is, tehát nem foglalkoznak a nagyobb blokkmérettel.

Folyamatos nagy file-oknál, amik nincsenek fragmentálva gondolom ott úgy működik az olvasás/írás hogy az egymás után következő blokkokat olvassa/írja. Számít-e ilyenkor az, hogy mekkora a blokk? Van a blokk elején vagy végén vmi információ hogy ott utána egy másik kezdődik? Mert ha van, akkor minél kisebb a blokk annál több ilyen információt talál és analizál ugyanakkora file-nál.

"Én azt a kabátot választanám, amelyiknek nagyobbak a zsebei"

Ennek a kabatnak neve is van: XFS :-) Nem vagyok XFS fan, de ez kimondottan nagy fajlok tarolasara keszult.

A reiserfs pedig _tipikusan_ sok apro fajl eseten javasolt. Nem akarlak rola lebeszelni, de ha mindenkeppen ragaszkodsz a nagyobb blokkmerethez akkor le kell mondanod a reiserfs-rol, vagy maradj a reiserfs-nel es le kell mondanod a nagyobb blokkmeretekrok. :-)

Esetleg meg nezzel utana a 4-es reiserfs-nek, lehet, hogy ott mar megoldodott a problema.

BTW, filerendszerekkel kapcsolatban pedig nezzel korul itt. Talalsz rengetek leirast es tesztet is.
---------------------
Ригидус а бетегадьбол

Nagyon "okos" hozzászólásod volt, de tényleg. Kiragadtál egy mondatom és azzal apellálsz.
Helikopterrel is lehet repülni.

De miért lehet kreálni akár 64k-s blokkméretet reiserfs-sel ha nem lehet bemountolni? Valami magyarázat biztos hogy van rá.....

Xfs? Biztos érdemes lesz kipróbálni......
De pl az én disztom nem hiszem hogy így alapból támogatja ezt. Nem találtam olyan mk* file-t, amiben xfs lett volna. Most így hirtelen ezeket látom:
ext2 & ext3, dos, reiserfs, minix, msdos, bfs, cramfs

Azért ajánlottam az ext3-at, mert keveset fogsz vele szívni. Ha valami problémád van pillanatok alatt találsz rá megoldást. Pl. eszedbe jut, hogy dejó lenne menet közben a mountolt partíció méretét megnővelni. ext2/3-nál semmi gond, ha eleve ezen opcióval együtt hoztad létre (pl. fedora helyből 1000x-es méretnővelési tartalékot tesz be). Meghibásodott? vagy gyorsan találsz olyat, aki segít, vagy gyorsan kihámozod egy leírásból, hogy mit csinálj.
Kezdőként én ezt nagy előnynek értékeltem, mert így tudtam másra koncentrálni. Persze később lehet elmélyülni (pl. ext3 opciói, más fájlrendszerek, stb.)
Ajánlom, hogy az egész alá tegyél raid-et (akkor is ha csak egy hdd-d van, csinálj mirror-t két hdd-re, amiből az egyik "missing"), majd a raid-re LVM-et. Később még nagyon jól jöhet!

"Nagyon "okos" hozzászólásod volt, de tényleg. Kiragadtál egy mondatom és azzal apellálsz."

Akarcsak most. Kicsit duhito, ha tanacsot adsz, es utana kijelentik, hogy "erdemi segitseget nem kaptam". Bar, ha neked az erdemi segitseg az lenne, ha valaki patchet irna, hogy a reiserfs.c ezutan kezelje a nagyobb particiokat, akkor valoban senki sem segitett. Ez esetben viszotn mashol kellene kerdezned. Ambar, mintha par emberke linket is nyujtott volna, hol erdemes szetnezned...
De nehezen hiszem, hogy Hans reiser kiadta az ukazt, "nem erdekel, milyen nehezen illesztheto a filerendszerbe a 4k blokkmeret, en ugy dontottem, hogy ez lesz es kesz, mert igy akarom", inkabb valami oka lehet a 4k-s hatarnak. Pl. azert lehet letrehozni de mountolni nem, mert valami gond van azzal a merettel. Gondolom en...

(Hs meg az ember azt valaszolja, hogy "csak, nem lehet", akkor meg az a baja a T. usernek. Nyavalya sem erti ezt... )