„Különben lehet, hogy Slack-rõl lehet, mert ott van XFS támogatású kernel, de a Grub biztos, hogy nem támogatja.”
?! grubnak annyi a feladata (_nagyvonalakban_), hogy beolvassa a megadott allomanyrendszerbol a megadott kernel imaget es berakja a memoria megfelelo reszebe;
ha egyszer van benne xfs tamogatas („can dynamically read Linux ext2fs, ReiserFS, JFS and XFS, BSD ufs, MS-DOS FAT16 and FAT32, Minix fs, and VSTa fs filesystems, plus hardcoded blocklists”), akkor mi lenne a gond?
az, hogy a kernelben benne van-e az xfs tamogatas, hogy a _kernel_ tudjon olvasni arrol a particiorol, az mar mas kerdes;

nos, ez mar eleg hard core tema, megvallom meg nem foglalkoztam vele eleget, de lassuk:
a fragmentacio oka, hogy egy allomany fizikailag nem egybefuggo teruleten helyezkedik el a merevlemezen / memoriaban;
miert baj ez?
1. mivel az allomany nem egybefuggo teruleten van , ahelyett, hogy a mervelemzrol folyamatosan olvasna a fej folyton ugralnia kell; ez persze nem sokat szamit egy allomany eseten, de ha sok kis allomany sok kis reszre van szakadva, az mar … szinten nem annyira jelentos, mint …
2. (ez a fontos, es ez kihat a memoriara is!) mivel az allomany tobb daraban van, ezert a rendszernek folyamatosan kell tudnia, hogy a reszek hol helyezkednek el es hogyan kapcsolodnak egymashoz; hosszu evek alatt kialakulhat olyan allapot, hogy mar logikailag hibak keletkeznek ebben a tarolasban es a rendszer mar keptelen helyesen osszeallitani a fragmenteket; (tudom, en egyszer tapasztaltam fat eseten, kb 2 ev utan);
minden allomanyrendszer fragmentalodik, de nem mindegy, hogy hogy kezelik a kerdest; a modernebb allomanyrendszerek, mint az ext2fs / reiserfs / stb mar nem csak folyamatosan irjak az allomanyt a mervelemez elejetol, mint a fat, hanem megproblnak egy megfelelo nagysagu fizikailag ures reszt keresni, es csak akkor bontjak meg az allomanyt, ha tul nagy es tul sok idot venne igenybe az elhelyezese; ez azt jelenti, hogy egy atlagos, 10-20 gigas mervelemzen, kb felig telitve par tizezer allomannyal durvan 2-3% a fragmentacio egy ev utan, hosszabb tavon 5-6%, de ez nem no jelentosen;

DE! nagyon fontos, hogy az adott particio ne teljen meg jobban, mint ~75%, mert ekkor mar nehezen talal a rendszer megfelelo ures helyeket es tenyleg kezd majd fragmentalodni; durvan ~90%nal nem ajanlott tartosan hasznalni a rendszert (ez itt honapokat jelent);

osszesegeben: fragmentacio van, de a modern allomanyrendszerek kepesek urra lenn a helyzeten;

akit melyebben erdekel a tema olvassa el pld a kernelhez jaro Documentation/filesystems/ext2.txt allomanyt;

aki jobban tajekozott a temaban nyugodtan irjon, erdekelne;

megj.:
van defragmentalo program ext2fshez ‘defrag’ neven, de 0 tapasztalatom vele;

a reiser4 ben lesz benne egy olyan funkcio, hogy egy allomany kisebb, mint egy block, akkor ugyanabban a blockban el tud helyezni meg egy allomanyt, ami helymegtakaritashoz vezet;

„valahogy elég nehezen olvasható lett.”
legjobb lenne ujrairni mondjuk sgmlben, azt konnyu txt/html/pdf konvetalni;
majd egyszer, most debian telepitest irogatom; jo lesz 😉

ennyit tudok segiteni:
http://www.google.com/search?q=sata+linux&…=utf-8&oe=utf-8
http://kerneltrap.org/node/view/1787

persze, a gcc is csak egy csomag akarcsak a tobbi; _minden_ beletratozik vmilyen csomagba, vagy csomag generalja (pld a ‘/dev’-et a „makedev” csomagban levo ‘MAKEDEV’);

persze egy gcc mar picit bonyuloltabb csomagok szintjen:
a ‘gcc’ csomag csak minimalis allomanyokat tartalmaz, lenyegeben azert ekll, mert fugg a az aktualis gcc-[verzio] es cpp-[verzio] csomagoktol; tehat, ha telepited a gcc csomagot, akkor ezek is telepulnek; ha van ujabb gcc-[verzio], akkor atirjak a gcc metacsomag fuggosegit, hogy ezt telepitse fel;

ha gcc-2.95-tel akarsz forgatni, akkor szukseges van erre a csomagra, mert (legalabbis a sid) gcc metacsomagja per pillanat a gcc-3.3-tol fugg;

stb stb

errol eleg sok info van ezeken a helyeken: http://qref.sourceforge.net/ http://www.debian.org/doc/