Fejezet 9. Lemezek, állományrendszerek és rendszertöltők

Ezzel kapcsolatban olvassuk el a lemezek hozzáadásáról szóló részt a FreeBSD kézikönyvben.

Ezt legegyszerűbben úgy tudjuk megcsinálni, ha újratelepítjük az operációs rendszert az új lemezre és külön áttesszük a felhasználói adatokat. Ez különösen ajánlott abban az esetben, ha már több kiadás óta követjük a -STABLE változatot, vagy ha korábban már frissítettük a kiadásunkat. A boot0cfg(8) segítségével fel tudjuk rakni a booteasyt mind a két lemezre és így egészen addig váltogatni tudjuk a kettőt, amíg teljesen át nem álltunk. Ugorjuk át a következő bekezdést, és olvassuk el, hogy rakjuk át az adatokat.

Úgy is dönthetünk, hogy nem telepítjük újra a rendszert. Ekkor vagy a sysinstall(8), vagy pedig a fdisk(8) és a disklabel(8) használatával osszuk fel és címkézzük meg az új lemezt. Érdemes még a boot0cfg(8) segítségével felraknunk a booteasyt mind a két lemezre, így miután átmásoltuk a régi rendszerünket az új lemezre, ennek megtartásával ki tudjuk próbálni az új rendszert. A lemezek formázásáról szóló cikkben olvashatunk ennek pontosabb részleteiről.

Most, miután sikeresen beállítottuk az új lemezt, készen állunk az adatok átmásolására. Sajnos nem lehet csak úgy vakon átmásolni ezeket egyik lemezről a másikra. Ilyenkor ugyanis bizonyos dolgok (például a /dev könyvtárban található eszközleírók, az állományjelzők és a linkek stb.) hajlamosak elromlani. Ezért ehhez olyan eszközökre lesz szükségünk, amelyek ismerik ezeket a dolgokat, mint például a dump(8). Továbbá javasoljuk, hogy egyfelhasználós módban végezzük el az átvitelt, noha ez nem feltétlenül szükséges.

A rendszerindító állományrendszer átmozgatásához egyedül a dump(8) és restore(8) segédprogramokra lesz szükségünk. Esetleg a tar(1) parancs is használható, de nem minden esetben. A dump(8) és restore(8) páros akkor is remekül használható, ha egy partíció tartalmát egy üres partícióra akarjuk átvinni. A következő lépések szükségesek ahhoz, hogy a dump parancs segítségével átvigyük egyik partícióról a másikra az adatokat:

Például, ha a /mnt könyvtárba csatlakoztatott /dev/ad1s1a eszközről akarjuk átvinni a jelenlegi gyökérpartíciónkat, akkor ezeket a parancsokat kell kiadnunk:

# newfs /dev/ad1s1a
# mount /dev/ad1s1a /mnt
# cd /mnt
# dump 0af - / | restore rf -

További munkát igényel, ha a dump parancs segítségével a partícióinkat is át akarjuk szervezni. Például a /var partíciót úgy tudjuk beleolvasztani a tövébe, ha létrehozunk egy olyan partíciót, amely mind a kettő számára elegendő nagy, majd a fentebb leírt módszerrel először átmozgatjuk a tövét, utána pedig átmozgatjuk az alpartíció tartalmát az első mozgatás során létrejött egyik üres könyvtárba:

# newfs /dev/ad1s1a
# mount /dev/ad1s1a /mnt
# cd /mnt
# dump 0af - / | restore rf -
# cd var
# dump 0af - /var | restore rf -

Egy könyvtárat, például /var tartalmát pedig úgy tudunk leválasztani a tövéről, vagyis átrakni egy korábban nem létező partícióra, ha először létrehozzuk mind a két partíciót, csatlakoztatjuk a leendő alpartíciót az ideiglenes csatlakozási ponton belül a megfelelő könyvtárba és mindkettőre átmozgatjuk a régi partíció teljes tartalmát:

# newfs /dev/ad1s1a
# newfs /dev/ad1s1d
# mount /dev/ad1s1a /mnt
# mkdir /mnt/var
# mount /dev/ad1s1d /mnt/var
# cd /mnt
# dump 0af - / | restore rf -

A felhasználói adatok esetén a cpio(1), pax(1), tar(1) és dump(8) eszközöket ajánljuk. Az írás pillanatában még úgy tudjuk, hogy nem tartják meg az állományjelzőkkel kapcsolatos információkat, ezért csak óvatosan használjuk ezeket!

A telepítés során két különböző módon tudjuk partícionálni a lemezeinket. Alapértelmezés szerint a rendszer igyekszik kompatbilis maradni a gépünkön található többi operációs rendszerrel. Ilyenkor normális partíciós táblabeli bejegyzéseket készít (amelyeket FreeBSD alatt “slice”-oknak hívnak), és egy ilyen slice-ba teszi az összes saját partícióját. Emellé még telepíteni tudjuk az operációs rendszerek választásának lehetőségét is a rendszer indításakor. A másik lehetőség választása esetén azonban a FreeBSD teljesen kisajátítja a lemezt és nem is próbál meg kompatibilis maradni a többi operációs rendszerrel.

Miért is nevezzük ezt “veszélyesnek”? A lemez ebben az esetben nem tartalmaz semmi olyat, amelyet a hétköznapi programok partíciós táblaként tudnának beazonosítani. Attól függően, hogy mennyire illedelmes, egy ilyen program panaszkodni fog, amikor megpróbálja értelmezni a lemez tartalmát, de rosszabb esetben anélkül felülírja a rendszerbetöltőt, hogy bármit is jelzett volna. Ráadásul a “veszélyesen dedikált módon” kiosztott lemezek még bizonyos BIOS-okat is képesek megzavarni, többek közt az Award (például amelyek a HP NetServer, Micronics és hasonló rendszerekben találhatóak) vagy Symbios/NCR (népszerű 53C8xx SCSI-vezérlők) típusúak esetén találkozhatunk ezzel a problémával. Ez a lista persze nem teljes, más gyártók termékeivel is gondok akadhatnak. Ennek a hibának jellemző tünete a “read error” hibaüzenet, amely arra utal, hogy a FreeBSD betöltője nem találja saját magát a lemezen, vagy éppen az egész rendszer megáll a rendszer indítása közben.

Akkor mégis mi értelme van ennek? Csak néhány kilobyte-tot spórolunk vele, miközben komoly gondokat okozhat egy frissen telepített rendszer esetében. A “veszélyesen dedikált mód” eredetileg az új FreeBSD telepítőket veszélyeztető egyik komoly hibát szeretné kiküszöbölni: a merevlemezek BIOS és lemez önmaga által ismert geometriai beállításainak egyeztetése.

A “lemezgeometria” fogalma tulajdonképpen már egy elavult fogalom, de a PC-k BIOS-a legbelül még mind a mai napig így kommunikál a lemezekkel. Amikor a FreeBSD telepítőjével slice-okat hozunk létre, olyan módon kell rögzítenünk a lemezre ezek pozícióját, hogy a BIOS képes legyen megtalálni. Ha ez nem sikerül, akkor nem tudjuk elindítani a rendszert.

A “veszélyesen dedikált” mód ezt a problémát az egyszerűsítésén keresztül próbálja megoldani, és néha sikerül is neki. Ezt azonban csak akkor javasoljuk, ha semmi más nem működik, hiszen az esetek túlnyomó részében más megoldás is létezik.

Hogy tudjuk tehát akkor elkerülni a “veszélyesen dedikált” mód használatát a telepítés során? Jegyezzük fel, hogy mik a BIOS szerint a merevlemezünk geometriai beállításai. Ezt a rendszerindítás közben a rendszermagtól is megkérdezhetjük úgy, hogy a boot: paranccsorába megadjuk a -v beállítást, vagy a betöltőben a boot -v parancsot használjuk. Így pontosan a telepítő indítása előtt a rendszermag ki fogja írni a BIOS által ismert geometriai beállításokat. Ne essünk pánikba, várjuk meg, amíg a telepítő elindul, tekerjünk vissza a számokhoz és olvassuk le ezeket. A lemezek általában a BIOS sorrendjében jelennek meg, tehát először az IDE aztán a SCSI típusúak.

A lemez partícionálásakor ellenőrizzük, hogy az FDISK képernyőjén megjelenő geometriai beállítások megfelelőek (tehát egyeznek a BIOS által ismert értékekkel). Ha eltérést tapasztalunk, akkor a G billentyű lenyomásával tudjuk átjavítani. Erre leginkább akkor lesz szükségünk, ha a lemez teljesen üres, vagy ha a lemezt egy másik rendszerből hoztuk át. Ez egyébként csak azoknál a lemezeknél okoz gondot, amelyekről a rendszert akarjuk indítani, a FreeBSD a többi lemezzel már remekül elboldogul.

Miután sikerült egyeztetnünk a BIOS és a FreeBSD geometriai beállításait, szinte biztos, hogy nem kell már emiatt aggódnunk, így a “veszélyesen dedikált” módra sincs szükségünk. Ha viszont mégis egy “read error” hibaüzenetet kapnánk a rendszer indítása közben, akkor tegyünk egy próbát. Semmit sem veszíthetünk.

Ha a “veszélyesen dedikált” mód használatáról szeretnénk visszatérni a megszokottra, akkor két lehetőségünk van. Először is teljesen le kell nulláznunk az MBR-t, így biztosra vehetjük, hogy az ezután következő telepítések során egy teljesen üres lemezt látunk. Ezt például így lehet megtenni:

# dd if=/dev/zero of=/dev/rda0 count=15

A másik módszer egy hivatalosan nem dokumentált DOS-os “lehetőség” használata:

C:\> fdisk /mbr

Ezzel egy új Master Boot Recordot tudunk telepíteni, ami ezzel együtt felülírja a BSD rendszertöltőjét is.

A rövid válasz: A Soft Updates bármelyik partíción minden további nélkül használható.

A hosszabb válasz: Korábban voltak bizonyos kétségek afelől, hogy a Soft Updates jól működik a rendszerindító partíciókon is. Ez alapvetően a Soft Updates két jellemzőjére vezethető vissza. Először is, a Soft Updatest alkalmazó partíciók esetén előfordulhat, hogy a rendszerösszeomlás során elveszik valamennyi adat (maga a partíció nem lesz hibás, csupán némi adat tűnik el), illetve a Soft Updates ideiglenesen kifogyhat a tárhelyből.

A Soft Updates használata során a rendszermag legfeljebb harminc másodperc múlva írja ki fizikailag a változtatásokat a lemezre. Tehát amikor egy nagyobb állományt törlünk, akkor ez az állomány egészen addig a lemezen marad, amíg a rendszermag ténylegesen el nem végzi ezt a törlést. Ezzel viszont nagyon egyszerűen létrehozható egy “ütközés” (race condition) az állományrendszeren. Tegyük fel, hogy letörlünk egy nagyobb állományt és utána közvetlenül létrehozunk egy másik nagyobb állományt. Mivel az első állomány ilyenkor még nem törlődik le valójában a lemezről, ezért a második számára már nem lesz elegendő helyünk. A rendszer ekkor egy hibaüzenetben fog figyelmeztetni minket, miközben pontosan az imént töröltünk le egy óriási állományt! Ha néhány másodperccel később újra megpróbáljuk létrehozni ezt az állományt, akkor már minden a megfelelő módon fog zajlani. Ezt régebben sok FreeBSD felhasználó nem tudta mire vélni.

Ha a rendszerünk olyankor omlik össze, amikor a rendszermag már elkezdte egy nagyobb mennyiségű adat kiírását a lemezre, de még nem fejeződött be, akkor könnyen előfordulhat, hogy ez az adat elveszik vagy meghibásodik. Ennek kockázata nagyon kicsi, és általában kezelhető, viszont az IDE-meghajtókban található írási gyorsítótár használata jelentősen növeli ezt. Ezért a Soft Updates alkalmazása során nem javasoljuk ennek használatát.

Ezek a problémák az összes Soft Updates partíciót veszélyeztetik. Mennyiben vonatkoznak viszont ezek a gyökérpartícióra?

A gyökérpartíción nagyon ritkán változnak fontos információk. A /boot/kernel/kernel és az /etc egyedül a rendszer karbantartása során frissül, vagy például amikor a felhasználók jelszót változtatnak. Ha a rendszer egy ilyen változtatás harminc másodperces idején belül omlik össze, akkor megvan rá az esélyünk, hogy elvesznek az adataink. Ez a kockázat a legtöbb alkalmazás számára elfogadható, de semmiképpen sem szabad figyelmen kívül hagynunk. Ha a rendszerünk nem képes vállalni még ennyi kockázatot sem, akkor a rendszerindító partíción tiltsuk le a Soft Updates használatát!

A gyökérpartíció hagyományosan az egyik legkisebb partíció. Ha viszont az ideiglenes állományok tárolására szánt /tmp könyvtárat is ezen belülre tesszük és gyakran használjuk, akkor ebből időszakosan tárhelyproblémáink adódhatnak. Könnyen megoldhatjuk azonban ezt a problémát, ha a /tmp könyvtárhoz létrehoznunk egy szimbolikus linket a /var/tmp könyvtárra.

A hibajelenség:

# ccdconfig -C
ccdconfig: ioctl (CCDIOCSET): /dev/ccd0c: Inappropriate file type or format

Ez általában olyankor történik, amikor olyan c partíciókat próbálunk meg összefűzni, amelyek alapértelmezés szerint unused (“nem használt”) típusúak. A ccd(4) meghajtó azonban megköveteli, hogy az érintett partíciók FS_BSDFFS típusúak legyenek. Szerkesszük át a lemezeken található címkéket és változtassuk meg a partíciók típusát a 4.2BSD értékre.

A hibajelenség:

# disklabel ccd0
(itt valami gondot ír ki, ezért megpróbáljuk szerkeszteni a címkét)
# disklabel -e ccd0
(edit, save, quit)
disklabel: ioctl DIOCWDINFO: No disk label on disk;
use "disklabel -r" to install initial label

Ezt általában azért kapjuk, mert a ccd(4) által visszaadott lemezcímke valójában “nem létezik” a lemezen. Ezen úgy tudunk segíteni, ha explicit módon visszaírjuk, valahogy így:

# disklabel ccd0 > /tmp/lemezcimke.tmp
# disklabel -Rr ccd0 /tmp/lemezcimke.tmp
# disklabel -e ccd0
(most már működni fog)

A FreeBSD több más állományrendszert is ismer.

A FreeBSD hálózati állományrendszereket is támogat, többek közt az NFS-t (lásd mount_nfs(8)), a NetWare-t (lásd mount_nwfs(8)), és Microsoft-féle SMB állományrendszereket (lásd mount_smbfs(8)). Más egyéb FUSE-alapú állományrendszer (sysutils/fusefs-kmod) támogatását is megtalálhatjuk a portok között.

A logikai DOS partíciók az elsődleges partíciók után találhatóak. Például, ha van egy “E” betűjelű logikai partíciónk a második SCSI-meghajtónkon, akkor lennie kell egy “ötödik slice-nak” a /dev könyvtárban, amelyet majd csatlakoztatni tudunk:

# mount -t msdosfs /dev/da1s5 /dos/e

Igen. Erre a célra a gbde(8) és a geli(8) is tökéletesen alkalmas. A részleteket lásd a FreeBSD kézikönyv A lemezpartíciók titkosítása című fejezetében.

Ehhez tulajdonképpen csak annyit kell csinálnunk, hogy átmásoljuk a FreeBSD rendszerindító partíciójának az első szektorát egy állományba a DOS/Windows NT partíción belül. Legyen ez például a C:\BOOTSECT.BSD állomány (a C:\BOOTSECT.DOS mintájára), amelyhez aztán így igazítjuk a c:\boot.ini állományt:

[boot loader]
timeout=30
default=multi(0)disk(0)rdisk(0)partition(1)\WINDOWS
[operating systems]
multi(0)disk(0)rdisk(0)partition(1)\WINDOWS="Windows NT"
C:\BOOTSECT.BSD="FreeBSD"
C:\="DOS"

Ha a FreeBSD ugyanazon a lemezen található, ahonnan a Windows NT is indul, akkor egyszerűen csak másoljuk át a /boot/boot1 állományt C:\BOOTSECT.BSD néven. Ha viszont a FreeBSD egy másik lemezen található, akkor a /boot/boot1 önmagában már nem elegendő, hanem helyette a /boot/boot0 állományra lesz szükségünk.

A /boot/boot0 állományt a sysinstall(8) használatával kell telepíteni abból a menüből, ahol a FreeBSD boot managerét kell kiválasztani. Erre azért van szükség, mert a /boot/boot0 állományon belül a partíciós tábla teljesen üres, azonban a sysinstall(8) át fogja másolni a partíciós táblát mielőtt a /boot/boot0 állományt az MBR-be tenné.

Amikor a FreeBSD boot managere lefut, az utoljára indított operációs rendszert a partíciós táblában aktívként jelöli meg (ezzel lényegében megjegyzi), majd ezután beírja magát az MBR-be. Emiatt, hogy ha csak egyszerűen átmásoljuk a /boot/boot0 állományt a C:\BOOTSECT.BSD állományba, akkor csak egy egyetlen aktív bejegyzést tartalmazó üres partíciós táblát fog visszaírni az MBR-be.

Ha a FreeBSD és a Linux® is ugyanazon a lemezen helyezkedik el, akkor nincs más teendőnk, mint követni a LILO telepítési útmutatójában a nem-Linux típusú operációs rendszerek indítására vonatkozó utasításokat. Ezek röviden összefoglalva a következők:

Indítsuk el a Linuxot és vegyük fel a következő sort az /etc/lilo.conf állományba:

other=/dev/hda2
        table=/dev/hda
        label=FreeBSD

(A fentiekben feltételeztük, hogy a FreeBSD-t tartalmazó slice a Linux számára /dev/hda2 néven érhető el. Ez természetesen a saját konfigurációnkhoz kell szabni.) Ezután egyszerűen csak futtassuk le a lilo parancsot root felhasználóként és már készen is vagyunk.

Ha a FreeBSD egy másik lemezen található, akkor a loader=/boot/chain.b LILO-bejegyzést kell használnunk. Például:

other=/dev/dab4
        table=/dev/dab
        loader=/boot/chain.b
        label=FreeBSD

Bizonyos helyzetekben előfordulhat, hogy a FreeBSD rendszertöltőjének át kell adnunk a meghajtó BIOS szerinti sorszámát, mert csak így tudjuk rendesen elindítani a második lemezről. Például, ha a FreeBSD szerint a SCSI-lemezünk a BIOS-ban az 1-es lemez, akkor ezt kell megadnunk a FreeBSD rendszertöltőjének:

Boot: 1:da(0,a)/boot/kernel/kernel

A boot(8) beállítható úgy, hogy a rendszer indításakor automatikusan mindig ezt a beállítást használja.

A FreeBSD és Linux együttes használatáról további részleteket a Linux+FreeBSD mini-HOWTO című írásból tudhatunk meg.

A FreeBSD-t nagyon könnyű elindítani a GRUB segítségével. Ehhez csupán annyit kell tennünk, hogy felvesszük a következő sorokat a GRUB konfigurációs állományába (/boot/grub/menu.lst, vagy bizonyos, például Red Hat-típusú rendszerekben a /boot/grub/grub.conf):

title FreeBSD 6.1
	root (hd0,a)
	kernel /boot/loader
	  

Itt a hd0,a az első lemezen található rendszerindító partícióra mutat. Ha a lemezen belül a slice számát is szeretnénk megadni, akkor írhatjuk így is: (hd0,2,a). Ha ezt nem adjuk meg, akkor a GRUB alapértelmezés szerint a lemezen levő első a partícióval rendelkező slice-ot keresi meg.

A LILO-t ne a Master Boot Recordba, hanem a linuxos partíciónk elejére telepítsük. Ezután a BootEasyből már el tudjuk indítani a LILO-t.

Abban az esetben is ezt javasoljuk, ha Windows® és Linux is van a gépünkön, mivel így szintén egyszerűbb lesz elindítani a Linuxot, ha netalán valamikor újra kellene telepíteni a Windows-t (ami viszont egy “irigy” operációs rendszer, mert nem tűr meg semmilyen más operációs rendszert maga mellett a Master Boot Recordban).

Ez az szabványos boot managerrel csak úgy lehet megoldani, ha újratelepítjük. A portok között viszont a sysutils kategóriában rengeteg olyan más boot managert találhatunk, amely tud ilyet is.

Legyen az akár egy Zip®, EZ drive meghajtó (esetleg egy floppy, ha így akarjuk használni), vagy éppen egy új merevlemez, miután már telepítettük és felismerte a rendszert, illetve behelyeztük a lemezt, kártyát vagy akármit, minden esetben szinte ugyanaz a teendő.

(Ez a válasz leginkább Mark Mayo ZIP GYIK című írásán alapszik.)

Ha tehát egy ZIP meghajtóról vagy floppylemezről beszélünk, amelyen egy DOS-os állományrendszer található, akkor azt parancssorból így érhetjük el, ha floppy:

# mount -t msdosfs /dev/fd0c /floppy

vagy így, ha egy gyári beállításokkal rendelkező ZIP-lemez:

# mount -t msdosfs /dev/da2s4 /zip

A többi lemez esetén a fdisk(8) vagy a sysinstall(8) segítségével nézzük meg, hogy milyen partíciók és hogyan találhatóak meg rajtuk.

A következő példákban egy da2 eszközként, vagyis egy harmadik SCSI-lemezként megjelenő ZIP-meghajtót fogunk használni.

Hacsak nem floppyval van dolgunk, illetve nem tervezzük másoknak is odaadni a cserélhető médiumot, akkor érdemes inkább BSD típusú állományrendszert telepíteni rá. Így támogatottak lesznek a hosszú állománynevek, és legalább egy kétszer gyorsabb és egy sokkal megbízhatóbb megoldást kapunk. Ehhez először is le kell szednünk a DOS-szintű partíciókat és állományrendszereket. Erre a célra egyaránt megfelel a fdisk(8) vagy a sysinstall(8), illetve kisebb lemezek esetén valószínűleg nem is lesz szükségünk több operációs rendszer támogatására, így aztán közvetlenül is törülhetjük ezeket:

# dd if=/dev/zero of=/dev/rda2 count=2
# disklabel -Brw da2 auto

A disklabel(8) vagy a sysinstall(8) használatával ezután létre tudunk hozni BSD típusú partíciókat. Valószínűleg erre lesz szükségünk, ha lapozóállományt is tenni akarunk a lemezre, noha ennek nem sok értelme van például egy ZIP-meghajtó esetén.

Végezetül hozzunk létre egy új állományrendszert. Itt most ez egész ZIP-lemezen egyetlen partíció lesz:

# newfs /dev/rda2c

Csatlakoztassuk:

# mount /dev/da2c /zip

Emellett még hasznos lehet felvenni hozzá egy sort az /etc/fstab állományba is (lásd fstab(5)), így a jövőben elegendő csak a mount /zip parancsot kiadnunk a csatlakoztatásához:

/dev/da2c /zip ffs rw,noauto 0 0

Fel kell világosítanunk a mount(8) parancsot a csatlakoztatandó eszköz típusáról. Erről a kézikönyv lézeres tárolóeszközökről szóló részében olvashatunk, innen is különösen a Adat CD-k használata című szakaszt ajánljuk.

Ez általában arra utal, hogy nincs CD a meghajtóban, vagy a meghajtó nem érhető el a buszon. Ezzel kapcsolatban a kézikönyv Adat CD-k használata című szakaszát javasoljuk elolvasásra.

A CD-n valószínűleg a “Joliet” kiterjesztés használatával tárolják az állományok és könyvtárak adatait. Erre vonatkozóan a kézikönyvben a Lézeres tárolóeszközök (CD-k) létrehozása és használata című rész elolvasását javasoljuk, különös tekintettel az Adat CD-k használata című szakaszra.

Ez minden bizonnyal abból fakad, hogy nem egy ISO 9660 állományrendszert vettük fel rá, hanem közvetlenül maguk az állományokat. Olvassuk el a kézikönyvben a Lézeres tárolóeszközök (CD-k) létrehozása és használata című fejezetet, de különösen a Nyers adat CD-k írása című részt.

Erről a kézikönyvben találunk hasznos információkat, azon belül is az Adat CD-k másolása című szakaszban. A CD-kkel végezhető további műveletekről a kézikönyv Lézeres tárolóeszközök (CD-k) létrehozása és használata című részében találhatunk részletes útmutatásokat.

Ha zenei CD-ket próbálunk meg csatlakoztatni, akkor például egy “cd9660: /dev/acd0c: Invalid argument” hibát fogunk kapni a rendszertől. Ez azért történik, mert a mount parancs csak állományrendszerekkel használható. A zenei CD-ken viszont semmilyen állományrendszer nincs, egyszerűen csak maga az adat. Az olvasásukhoz olyan programra lesz szükségünk, amely képes zenei CD-kkel dolgozni, mint például az audio/xmcd port.

A mount(8) alapértelmezés szerint az CD-n található utolsó adatsávot (menetet, vagy sessiont) próbálja meg olvasni. Ha viszont egy korábbi menetet szeretnénk vele betöltetni, akkor erre használjuk a -s paranccsori paramétert. Erre a mount_cd9660(8) man oldalon találhatunk különböző példákat.

A normál felhasználók számára engedélyezni tudjuk az eszközök csatlakoztatását. Íme:

Most már mindegyik felhasználó képes csatlakoztatni a /dev/fd0 eszközleírón keresztül elérhető lemezt a saját könyvtárába:

% mkdir ~/az-én-csatlakozási-pontom
% mount -t msdosfs /dev/fd0 ~/az-én-csatlakozási-pontom

A operator csoport tagjai is képesek most már az /dev/acd0c eszközleírón keresztül elérhető CD-ket csatlakoztatni a saját könyvtárukba:

% mkdir ~/az-én-csatlakozási-pontom
% mount -t cd9660 /dev/acd0c ~/az-én-csatlakozási-pontom

Az eszközök leválasztása is hasonlóan egyszerű:

% umount ~/az-én-csatlakozási-pontom

A vfs.usermount engedélyezésével azonban együttjár némi biztonsági kockázat is. Az MS-DOS® formátumú lemezek csatlakoztatására ezért inkább a Portgyűjteményben található emulators/mtools csomagot javasoljuk.

A válaszhoz meg kell értenünk a du és a df működését. A du végigmegy a könyvtárszerkezeten és megnézi, hogy mekkorák az egyes állományok, majd megjeleníti a végösszegüket. A df ezzel szemben egyszerűen csak lekérdezi az állományrendszertől, hogy mennyi szabad hely maradt rajta. Ezek látszólag ugyanazt a módszer fedik, azonban miközben a könyvtár nélkül állományok befolyásolják a df parancsot, addig a du parancsot nem.

Amikor egy program használ egy olyan állományt, amelyet eközben letörlünk, egészen addig létezni fog, amíg a program be nem fejezi a használatát. Ettől függetlenül viszont az állomány azonnal eltűnik a könyvtárból. Ezt nagyon könnyen ki is tudjuk próbálni egy olyan programmal, mint például a more. Tegyük fel, hogy van akkora állományunk, amely elég nagy ahhoz, hogy feltűnjön a du és a df kimenetében. (Mivel manapság már nagyok a tárolóeszközök, ennek egy igen nagy állománynak kell lennie!) Ha letöröljük ezt az állományt, miközben a more paranccsal még használjuk, a more nem fog rögtön leállni és panaszkodni az állomány hiányára. Egyedül csak az állományhoz tartozó bejegyzés tűnik el a könyvtárból, így más program már nem tud hozzáférni. A du erre már azt mondja, hogy nem létezik -- bejárta a könyvtárat és nem találta. A df szerint azonban még mindig ott van, hiszen az állományrendszer tudja, hogy a more parancsnak még szüksége van rá. Ahogy a more befejezte a dolgát, a du és a df által mutatott értékek ismét egyezni fognak.

Azt sem szabad elfelejtenünk, hogy a Soft Updates használata esetén akár 30 másodpercet is várnunk kell, hogy a változtatásaink láthatóvá váljanak!

Ez a helyzet nagyon gyakori webszerverek esetén. Sokan úgy állítanak be a FreeBSD rendszerükön webszervert, hogy elfelejtik beállítani hozzá a naplók archiválását és váltását. Ilyenkor a hozzáférések naplózása gyorsan meg tudja tölteni a /var könyvtárat. Ekkor a rendszergazda törli az adott állományt, de a rendszer még mindig panaszkodik a szabad hely hiánya miatt. A webszerver leállítása és újraindítása ekkor segít felszabadítani az állományt, így az állományrendszerről is törlődhet. Ennek megelőzésére használjuk a newsyslog(8) programot.

A kézikönyv Beállítás és finomhangolás című fejezetében található egyik szakaszban olvashatunk erről.

A merevlemezek gyártói általában a gigabyte-okat egy milliárd byte-ként számolják, miközben a FreeBSD pedig 1 073 741 824 byte-nak. Ez remekül megmagyarázza, hogy a FreeBSD rendszerüzenetei között egy elméletileg 80 GB méretű lemez miért 76 319 MB-osnak jelenik meg.

Emellett érdemes még tisztában lennünk azzal is, hogy a FreeBSD (alapértelmezés szerint) fenntartja a lemezterület 8 százalékát.

Az UFS partíciók egy részét (amely alapértelmezés szerint a teljes kapacitás 8 százaléka) az operációs rendszer fenntartja a saját és a root felhasználó számára. A df(1) ezt a területet nem számolja a Capacity oszlopban megjelenő értékhez, ezért tudja átlépni a 100 százalékos arányt. Sőt még azt is láthatjuk, hogy a blokkok számát jelző Blocks oszlopban megjelenő érték mindig, általában pontosan 8 százalékkal nagyobb, mint a használt blokkokat jelző Used és a rendelkezésre álló blokkokat jelző Avail oszlopokban szereplő értékek összege.

A részleteket a tunefs(8) man oldalon belül a -m opció bemutatásánál olvashatjuk.