Ken je Linux-filesystem

[rickiii]

Na enkele maanden geleden weer serieus naar Linux te zijn gaan kijken als potentieel Desktop OS ben ik na het testen van verschillende distro's (FC5, Ubuntu 6.06 en uiteindelijk SuSE 10.1) mij redelijk thuisgaan voelen in deze Desktop omgevingen.

Een van de grootste bezwaren echter op dit moment, is dat ik het Linux filesysteem nauwelijks ken. Daar waar ik de Windows omgeving (Register, Program Files, Documents & Settings .... etc) op mijn duimpje kende, ben ik nu in Linux bij elke stap bang iets kapot te maken, of een situatie te creeren die moeilijk te herstellen is. Vooral omdat veel applicaties soms gewoon (nog) niet in de repositories te vinden zijn, ik sommige software in een vroeg stadium uitprobeer of gewoon wil kunnen spelen met instellingen om de kwaliteit van sommige software te verbeteren. Met als voorbeeld de ATI video-drivers of Skype.

Daarom zou ik graag een soort van handleiding of overzichtelijke tour door de componenten van Linux (zowel algemeen, als specifiek gericht op de 3 grote distributies) krijgen. Veel termen zoals bijv. RPM, Deb, Yum, Mount, init, fstab, X Windows, Gnome & KDE ken ik en weet wat je ermee kunt doen en heb er ook gebruik van gemaakt. Maar de precieze werking heb ik nooit begrepen.... de vele HOWTO's hebben namelijk alleen nog maar beschreven hoe je iets doen, maar niet wat er dan onder de motorkap gebeurt.

Mocht hier overzichtelijke documentatie van bestaan, dan lees ik het graag. En als het even kan overzichtelijke schema's die de verschillende modules en hun plaats in het geheel weergeven. Als je een boekentip wilt geven, mag dat ook... maar een mooie verzameling links zou wat mij betreft voldoende zijn.

Ik heb een VMWare installatie met Ubuntu 6.06 draaien, dus ik kan wel een hoop uitproberen, maar mijn voorkeur gaat toch uit naar de vorm van studeren ipv prutsen.

[ Voor 7% gewijzigd door rickiii op 04-06-2006 19:11 ]

[Charles Nasi]

Ik ben op het moment bezig met Xubuntu 6.06

Ik heb nog nooit serieus gewerkt met Linux, wel ooit om te kijken hoe de GUI Eruitziet (KDE, Gnome, XFCE) Maar wil me toch iets meer gaan verdiepen in Linux. Waaronder ook het Linux-Filesystem..

Voor mijn gevoel werkt het fijn en alles onder controle hebben. Maar hoe zit het Filesystem in elkaar? Waar zitten programma's Waar staat de commando's voor etc. en wat doen de commando's?

Op internet staan veel handleidingen, maar niet echt een specifieke. Van hoe moet ik het aanpakken etc. En hoe houd ik mijn Systeem in een goede conditie.

Charles.

[kaconst]

Dit is eigelijk een online-boek. Het gaat zo ongeveer over alles wat met linux te maken heeft, van samba over scripting, naar filehierarchieën, tot processen. Heel duidelijk, in detail en diepgaand uigelegd.
Precies wat je wou (tis wel heel algemeen dus niet over een bepaalde distributie.)

[rickiii]

kaconst schreef op zondag 04 juni 2006 @ 19:18:
Dit is eigelijk een online-boek. Het gaat zo ongeveer over alles wat met linux te maken heeft, van samba over scripting, naar filehierarchieën, tot processen. Heel duidelijk, in detail en diepgaand uigelegd.
Precies wat je wou (tis wel heel algemeen dus niet over een bepaalde distributie.)

Thanks! Dit lijkt echt een schitterend overzicht van alle bekende tools en filesysteem-locaties in een notendop. Vooral deze sectie gaat mij waarschijnlijk veel duidelijk maken:

Packages almost never install files across different superstructures.

Ook fijn om te weten

Maar voorzover ik kon zien geen schematische overzichten of beschrijvingen van de architectuur... bestaat er een website of document die de modules beschrijft? Bijvoorbeeld hoe X.org zich verhoudt tot Gnome en KDE.

Zie hier een voorbeeld van hoe een Java OS is opgebouwd.
http://khpi-iip.mipk.khar.../extent/os/os/java_os.gif

Of hoe Windows 2000 uit verschillende identicifeerbare componenten is opgebouwd.
http://upload.wikimedia.o...ows_2000_architecture.PNG

En dan zou ik graag ook nog zoveel mogelijk willen inzoomen op de verschillende onderdelen.

[ Voor 10% gewijzigd door rickiii op 04-06-2006 20:03 ]

[rickiii]

Ik heb een soort van handleiding gevonden voor X Windows
http://www-h.eng.cam.ac.u...aphics/X/X11R5/node3.html
Alleen deze laat niet de relatie zien tot andere componenten.

Een hele hoop informatie over X Windows, RPM en een hoop andere componenten is ook te vinden op Wikipedia blijkt. Dus ik denk dat ik voorlopig wel even zoet ben.

[ Voor 31% gewijzigd door rickiii op 04-06-2006 20:28 ]

[Lord Daemon]

Charles Nasi schreef op zondag 04 juni 2006 @ 19:14:
Voor mijn gevoel werkt het fijn en alles onder controle hebben. Maar hoe zit het Filesystem in elkaar? Waar zitten programma's Waar staat de commando's voor etc. en wat doen de commando's?

Programma's kunnen overal staan, maar het meest voor de hand liggend zijn: /bin, /usr/bin, /usr/local/bin, en /home/[user-naam]/bin. In /bin staan over het algemeen de echte systeem-tools, zoals chmod, mount, ls en dergelijke. In /usr/bin staan meer algemene programma's, die door alle users gebruikt kunnen worden. In /home/[user-naam]/bin/ staan meestal programma's die een user zelf ge-installeerd heeft.

Als je een overzicht wilt van alle paden waar je shell zal zoeken naar executables moet je "echo $PATH" intypen. Bij mijn SuSE 10.0 geeft dat bijvoorbeeld:

/home/victor/bin : /usr/local/bin : /usr/bin : /usr/X11R6/bin : /bin : /usr/games : /opt/gnome/bin : /opt/kde3/bin : /usr/lib/jvm/jre/bin : /usr/lib/mit/bin : /usr/lib/mit/sbin

Dit betekent dat als ik een commando intype, mijn PC eerst in /home/victor/bin gaat zoeken, daarna in /usr/local/bin, enzovoorts, totdat het een executable met de goede naam vindt.

Wat commando's doen kan je meestal zien met "[commando] --help" (korte uitleg) of "man [commando]" (lange uitleg).

[ajvdvegt]

als je je afvraagt waar een programma staat wat je uitvoert, kan je dat achterhalen met 'which'. Bv. 'which ls' geeft (bij mij) /bin/ls terug.

[Verwijderd]

Was het niet zo dat Linux distro's geen defragmentatie mogelijkheid kende? Defragmentatie lijkt mij op élk filesystem noodzakelijk.

[kaconst]

Linux systemen hebben geen defragmentatie nodig:

7.3. Some facts about file systems and fragmentation

Disk space is administered by the operating system in units of blocks and
fragments of blocks. In ext2, fragments and blocks have to be of the same
size, so we can limit our discussion to blocks.

Files come in any size. They don't end on block boundaries. So with every
file a part of the last block of every file is wasted. Assuming that file
sizes are random, there is approximately a half block of waste for each file
on your disk. Tanenbaum calls this "internal fragmentation" in his book
"Operating Systems".

You can guess the number of files on your disk by the number of allocated
inodes on a disk. On my disk
# df -i
Filesystem Inodes IUsed IFree %IUsed Mounted on
/dev/hda3 64256 12234 52022 19% /
/dev/hda5 96000 43058 52942 45% /var
there are about 12000 files on / and about 44000 files on /var. At a block
size of 1 KB, about 6+22 = 28 MB of disk space are lost in the tail blocks of
files. Had I chosen a block size of 4 KB, I had lost 4 times this space.

Data transfer is faster for large contiguous chunks of data, though. That's
why ext2 tries to preallocate space in units of 8 contigous blocks for
growing files. Unused preallocation is released when the file is closed, so
no space is wasted.

Noncontiguous placement of blocks in a file is bad for performance, since
files are often accessed in a sequential manner. It forces the operating
system to split a disk access and the disk to move the head. This is called
"external fragmentation" or simply "fragmentation" and is a common problem
with MS-DOS file systems. In conjunction with the abysmal buffer cache used
by MS-DOS, the effects of file fragmentation on performance are very
noticeable. DOS users are accustomed to defragging their disks every few
weeks and some have even developed some ritualistic beliefs regarding
defragmentation.

None of these habits should be carried over to Linux and ext2. Linux native
file systems do not need defragmentation under normal use and this includes
any condition with at least 5% of free space on a disk. There is a
defragmentation tool for ext2 called defrag, but users are cautioned against
casual use. A power outage during such an operation can trash your file
system. Since you need to back up your data anyway, simply writing back from
your copy will do the job.

The MS-DOS file system is also known to lose large amounts of disk space due
to internal fragmentation. For partitions larger than 256 MB, DOS block sizes
grow so large that they are no longer useful (This has been corrected to some
extent with FAT32). Ext2 does not force you to choose large blocks for large
file systems, except for very large file systems in the 0.5 TB range (that's
terabytes with 1 TB equaling 1024 GB) and above, where small block sizes
become inefficient. So unlike DOS there is no need to split up large disks
into multiple partitions to keep block size down.

Use a 1Kb block size if you have many small files. For large partitions, 4Kb
blocks are fine.

bron

[rickiii]

ajvdvegt schreef op zondag 04 juni 2006 @ 21:47:
als je je afvraagt waar een programma staat wat je uitvoert, kan je dat achterhalen met 'which'. Bv. 'which ls' geeft (bij mij) /bin/ls terug.

Ah, zoiets is hardstikke handig. Maar ik heb net bijvoorbeeld Eclipse geinstalleerd (via YaST) maar zou ik nu achteraf ook met een console-command kunnen zien welke files allemaal horen bij de installatie van eclipse? Ik gezien dat de Software Management tool ook die informatie heeft.

[wica]

Als yast nog steeds werkt met rpm's. Dan kan je via het command rpm na kijken waar die wat geinstalleerd heeft.
Hoe je dit voor elkaar krijgt. Kan je het beste lezen met.
man rpm.

En als je bang bent om je systeem omzeep te helpen
Wat best wel eens kan gebeuren.

Kan je natuurlijk eerst een backup van je systeem maken. man tar

Wat ik meestal doe is het volgende.
Al mijn config files staan in /etc
Dus voordat ik aan iets begin. Maak ik een back-up met tar -cjf etc-backup.tar.bz2 /etc

En als ik iets verkeerd doe. Is het gemakkelijk om de schade te herstellen door.
cd /
tar -xjf etc-backup.tar.bz2
En de schade is hersteld.

Met nieuwe software, Ik neem aan dat je dan de source gebruikt.
Is bij ./configure --prefix=/opt/programname zeer geschrikt. Om je systeem redelijk schoon te houden.

[terabyte]

Mahler schreef op zondag 04 juni 2006 @ 19:07:
Na enkele maanden geleden weer serieus naar Linux te zijn gaan kijken als potentieel Desktop OS ben ik na het testen van verschillende distro's (FC5, Ubuntu 6.06 en uiteindelijk SuSE 10.1) mij redelijk thuisgaan voelen in deze Desktop omgevingen.

Een van de grootste bezwaren echter op dit moment, is dat ik het Linux filesysteem nauwelijks ken. Daar waar ik de Windows omgeving (Register, Program Files, Documents & Settings .... etc) op mijn duimpje kende, ben ik nu in Linux bij elke stap bang iets kapot te maken, of een situatie te creeren die moeilijk te herstellen is. Vooral omdat veel applicaties soms gewoon (nog) niet in de repositories te vinden zijn, ik sommige software in een vroeg stadium uitprobeer of gewoon wil kunnen spelen met instellingen om de kwaliteit van sommige software te verbeteren. Met als voorbeeld de ATI video-drivers of Skype.

Zoek op Filesystem Hierarchy Standard (ja, hier is een standaard voor, waar bijna alle distro's zich aan houden)


Korte samenvatting: in de meeste directories zul je *nooit* hoeven te rommelen omdat de inhoud wordt beheerd door Ubuntu's package manager (dpkg).

/bin: hier staan de meest belangrijke systeemprogs/utils. Je zult nooit een geldige redenen hebben om hier te rommelen.
/boot: hier staat de Linux kernel, boot loader config, etc. Als je je Ubuntu goed gebruikt zul je hier nooit handmatig hoeven te rommelen
/etc: system-wide configuratie van de meeste programma's, heeft effect op alle users. Normaalgesproken heeft alleen de systeembeheerder heeft hier schrijftoegang. Dit is dus een soort Windows-register met systeem-globale settings, maar ipv een grote binaire bestand dat alleen met regedit gelezen kan worden, is het gewoon een directory met tekstbestanden en subdirs (dit heeft alleen maar voordelen tov register+Regedit)
/home: (vergelijkbaar met Documents and Settings) hier binnen heb je voor elke user een directory waar zijn/haar persoonlijke spullen staan:
documenten, muziek, video, persoonlijke programma's (niet system wide), configuratiebestanden (er is een strikte scheiding tussen system-wide en user-only config)
/lib: hier staan de meest belangrijke systeembibliotheken (soort DLLs). Je zult nooit een geldige redenen om hier te rommelen.
/opt: hier kun je je zelfgecompileerde spul van hele grote softwarepaketten in kwijt. (zoals een zelfgecompileerde KDE), meestal zul je van deze dir geen gebruik maken.
/root: hier staan documenten/bestanden/etc van de systeembeheerder.
/sbin: hier staan de meest belangrijke systeemprogs/utils die alleen door de systeembeheerder gebruikt kunnen worden. Je zult nooit een geldige redenen hebben om hier te rommelen.
/srv: in toekomstige linux distro's zal deze dir gebruikt worden voor zaken zoals site-global Apache websites, etc.
/tmp: tijdelijke bestanden (vergelijkbaar met c:\windows\temp) wordt leeggemaakt bij elke reboot
/var: dynamische bestanden tbv draaiende processen, denk aan caches, printer spools, mail spools, websites, logfiles!, lock-files, etc. Enkele dirs zullen interessant zijn om te bekijken (zoals /var/log) of te wijzigen (zoals /var/www), maar voor de rest moet je overal van afblijven.
/usr: bevat statische bestanden, dwz bestanden die niet gewijzigd hoeven te worden (bijv programma's, documentatie).
Bijv bij hele grote netwerken staat /usr vaak op een server (en niet lokaal) en wordt deze read-only geexporteerd naar alle clients. Extra handig voor de systeembeheerder, want alle progs staan dus centraal. (Er is geen Windows equivalent hiervoor)

/usr/bin: alle normale programma's zoals deze geinstalleerd zijn door Ubuntu. Als je je Ubuntu package manager heel wilt houden, dan rommel je niet in deze directory.
/usr/sbin: idem, maar dan alleen programma's die alleen door de systeembeheerder gerund mogen worden
/usr/include: hier staan de header files (Include files voor C programma's) geparkeerd. Wederom, je hebt normaal gesproken geen reden om iets aan deze dir te veranderen. Als je weinig -dev pakketten hebt geinstalleerd zal deze dir niet zo vol zitten.
/usr/lib: shared objects ('DLL' bestanden) en 'interne' programma executables (die door progs in /usr/bin gebruikt worden). Wederom: geen reden om hier iets te veranderen.
/usr/share: vanalles: documentatie, icoontjes, system wide wallpapers, etc. Ook deze dir wordt voor je beheerd door de package manager.
/usr/local: Hier mag je je zelf gecompileerde spul in kwijt. De Ubuntu package manager laat deze dir met rust.


De dirs waar je wel in kunt rommelen zijn dus:
/etc: (systeemconfiguratie)
/home/username: je persoonlijke dir
/usr/local/: Als je een prog wilt installeren die niet door je package manager geinstalleerd kan worden (niet beschikbaar), dan doe je dat dus hier.
/var/www/: site-wide website. Je persoonlijke website moet normaalgesproken in /home/username/public_html/

In /usr/local zitten nog een aantal subdirs, (bijv bin voor executables), maar meestal hoef je je geen zorgen te maken over wat waar moet, want ook dat wordt bijna altijd voor je geregeld.

Bijna alle source code komt met een autotools gegenereerde ./configure en Makefile.
Als je
./configure
make
make install

intikt, dan zal make install ervoor zorgen dat alles netjes in /usr/local/* wordt neergezet

Kortom: de Linux filesystem is heel simpel: bijna overal van afblijven omdat je simpelweg *geen reden* hebt om er iets aan te veranderen (tenzij je een masochist bent ). Bijna alles wordt voor je beheerd door je package manager. Zelfs control-freaks zoals ik hebben hier vrede mee Als je toch ongestoord wilt rommelen in belangrijke systeemdirs, dan moet je geen Linux distro gebruiken, maar Linux From Scratch

[ Voor 3% gewijzigd door terabyte op 04-06-2006 23:23 ]

[Spider.007]

Nog een kleine toevoeging op de hierboven geplaatste uitgebreidde post; ik denk dat de TS niet bang moet zijn om te rommelen, ook al geef je een aantal keren aan dit niet te doen. Zeker als het om een VMware installatie gaat zou ik niet bang zijn om te knoeien. Rename maar eens je /lib directory en kijk wat er foutgaat. Knoei maar eens met rechten en zie wat er doodgaat. Al doende leert men; en door software te breken en te repareren begrijp je waarom dingen werken.

[Soultaker]

Voor de hand liggend, maar nog niet genoemd: type eens man hier. (Komt in feite op hetzelfde neer als wat terabyte behandelde).

[terabyte]

Spider.007 schreef op zondag 04 juni 2006 @ 23:29:
Nog een kleine toevoeging op de hierboven geplaatste uitgebreidde post; ik denk dat de TS niet bang moet zijn om te rommelen, ook al geef je een aantal keren aan dit niet te doen.

*Normaal gesproken* hoef je niet in al die dirs te rommelen en dat is wat ik aangeef. Als TS wil experimenteren met z'n VMware installatie dan moet ie dat doen. Maar *normaal gesproken* hoef je niks in die dirs te veranderen.

[Verwijderd]

Spider.007 schreef op zondag 04 juni 2006 @ 23:29:
Nog een kleine toevoeging op de hierboven geplaatste uitgebreidde post; ik denk dat de TS niet bang moet zijn om te rommelen, ook al geef je een aantal keren aan dit niet te doen. Zeker als het om een VMware installatie gaat zou ik niet bang zijn om te knoeien. Rename maar eens je /lib directory en kijk wat er foutgaat. Knoei maar eens met rechten en zie wat er doodgaat. Al doende leert men; en door software te breken en te repareren begrijp je waarom dingen werken.

amen

[laurencevde]

http://www.pathname.com/fhs/pub/fhs-2.3.html
een erg uitgebreide pagina over de filesystem hierachy standard, inclusief het hoe en waarom.