Het Journaled File System onder OS/2 en Linux

>> eComStation index <<

Een JFS partitie voor Linux en OS/2 aanmaken

JFS utilities

JFS onder Linux benaderen


Bestandsrechten onder Linux en OS/2

JFS en het Unicode systeem

Clustergrootte



Toen OS/2 versie 2.0 (1992) uitkwam was het zijn tijd ver vooruit. Het bevatte een visionaire object georiënteerde shell en het voor servers ontworpen "high performance" bestandssysteem HPFS. De PC's van die tijd beschikten echter maar over weinig schijfruimte en geheugen. Van de vele gigabytes die het High Performance File System aankon kon men slechts dromen. Ook voor OS/2 Warp 3 (1994) en OS/2 Warp 4 (Merlin, 1996) clients was de 2 gigabyte HPFS cache en bestandsgrootte van HPFS meer dan voldoende, maar een paar jaar later al niet meer.

Eind jaren negentig waren de Personal Computers zo krachtig dat ze gemakkelijk voor multimedia en servertaken konden worden ingezet. Met NT uitgeruste PC's vervingen UNIX werkstations en servers. IBM had de strijd om de PC Desktop met Microsoft al opgegeven, maar gaf zijn laatste OS/2 Warp Server for e-Business (1998) nog wel het van het Journaled File Systeem (JFS) mee. Dit ook om haar zakelijke klanten minder afhankelijk te laten zijn van het prijzige Microsofts HPFS386 bestandssysteem.

Alle versies van eComstation komen met JFS. eComStation 2.0 zal ook van JFS kunnen booten. De versies 1.0, 1.1 en 1.2 booten van HPFS, FAT of van CD via een RAM-disk, maar niet van het snelle JFS.

Logical Volume managers

Zowel Linux als eComstation komen met Logical Volume Managers (LVM). eComStation gebruikt die van IBM en Linux kent er vele. Vaak zijn ze aan een bestandssysteem gebonden. Zo maakt de Logical Volume Manager van OS/2 "incompatibility" JFS volumes zichtbaar voor OS/2. Hoewel een bestandssysteem op zich niets met een logische volumebeheerder te doen heeft, moet u LVM wel gebruiken als u onder OS/2 JFS wilt benaderen.

Doorgaans kent een logische volumebeheerder alleen de logica van zijn eigen besturingssysteem. Linux werkt niet met schijfletters. De voor Linux uitgebrachte logische volumebeheerders zijn dus niet compatibel met die van OS/2. Ook niet met die van IBM. Logische volumebeheerders zijn voor het beheer van vaste schijfruimte op servers bedoeld en niet voor multibootsystemen met verwisselbare media. Wat dat betreft is de aan OS/2's boot manager gekoppelde LVM een vreemde eend in de bijt.

JFS partities en "logische" volumes

Steeds is het belangrijk om onderscheid te maken tussen JFS partities en logische LVM volumes. Alle partities worden door een FDISK aangemaakt, maar om die partities onder OS/2 zichtbaar te maken hebt u een Logische Volume Manager en passende stuurbestanden nodig. Omdat u onder OS/2 zowel het partitioneren als logische volumebeheer met het LVM programma doet, ontstaat er verwarring. Temeer omdat de naamgeving van LVM uiterst verwarrend is.

Bij haar FDISK functie maakt LVM een kunstmatig onderscheid tussen de voor JFS bestemde partities (LVM volume) en andere partities (compatibility volume).

Create a new volume
Create a volume that does not need to be bootable

En daarna krijgt u de keus tussen :

Create a compatibility volume
Create an LVM volume

Bij het partitioneren worden de begin- en eindsector van een JFS partitie (partitietype 35) in de master boot sector van de vaste schijf vastgelegd. Een JFS partitie is dan ook niet meer dan een met LVM of een Linux FDISK aangemaakt continu deel van de vaste schijf. U kunt van een FAT partitie een nog niet geformatteerde JFS partitie maken door het partitietype van 6 in 35 te wijzigen en hem daarna onder Linux formatteren. Maar onder OS/2 moet u kiezen voor :

Create an LVM volume

Nadat u met LVM aan een type 35 partitie een stationsnaam toegekend heeft, kunt u de partitie met het JFS bestandssysteem formatteren. Het uit DOS tijden stammende formatterings programma van OS/2 wil een schijfletter zien: format [station:] /FS:JFS /BS:4096. Onder Linux gaat het ook, maar dan met de /dev/hd[letter][nummer] aanduiding van het virtuele bestandssysteem. Daarna hebt u een geformatteerde JFS partitie, die u zowel onder Linux als OS/2 kunt benaderen. Onder Linux moet u de partitie nog op het bestandssysteem mounten (fstab, mount opdacht); voor OS/2 moet u een onder Linux geformatteerde partitie een stationsaanduiding geven.

Create an LVM volume
Y: (selecteer stationsaanduiding)
Enter a name for the volume: backup
Choose a disk for the volume. Press F6 to complete creation of the volume.
1    hda                        117239                     0                0  (selecteer schijf)
Use existing partition
P12 - 20002.8 MiB           20002 (kies partitie)
Enter a name for the partition: P12 - 20002.8 MiB

F6=finish  Esc=back  F1=help

Bevestig met F6

---------------------------------------------------------------------------
backup               Y:        LVM                          None        20000
---------------------------------------------------------------------------
Disk Partition         Size (MB)                   Disk Name
P12 - 20002.8 MiB           20000                   hda
---------------------------------------------------------------------------
F1=help   F3=exit   F5=Physical View   Enter=Options  Tab=Window
---------------------------------------------------------------------------

Bevestig met met F3

 Return to the program
 Discard the changes and exit
 Save the changes and exit

En opslaan met: Save the changes and exit.



In dit geval hebben we een als JFS geformatteerde partitie die onder OS/ 2 tevens een LVM volume met stationsaanduiding is. Dergelijke partities zijn met recente stuurbestanden goed onder OS/2 en Linux te benaderen, zolang u tijdens het formatteren maar de door Linux ondersteunde blokgrootte van 4 KB gebruikt (format D: /FS:JFS /BS:4096 of de ?BS optie weglaten).

Een JFS partitie voor Linux en OS/2 aanmaken

> Top <

Toch is niet zo gemakkelijk als het lijkt. Ik ben er met twee systemen mee aan de slag gegaan. In beide gevallen ging het om SuSE Linux 8.2 en eCS 1.1.

Tijdens de installatie van Linux bleek het partioneringsprogramma GNU Parted van SuSE Linux 8.2 niet met eCS's 1.1 LVM volumes te kunnen omgaan. Doordat dit open source partioneringsprogramma het wel van te voren aangaf, bespaarde het me veel ellende. Maar andere partitioneringsprogramma's kunnen overmoedig zijn!

Ook de Linux fdisk had moeite met LVM's partities. Zo kon hij geen vrije ruimte zien nadat ik een LVM volume gewist had.

Om te beginnen heb ik OS/2 (eCS) geïnstalleerd. De door mijn werk afgedankte 1000 MHZ Compaq Deskpro P3 was vooral bedoeld als spelletjes PC voor de kinderen, vandaar dat ik naast OS/2 ook Windows 95 en Linux wilde installeren. Windows 95 voor Windows spelletje en Linux en OS/2 voor de internettoegang. OS/2 werd als eerste geïnstalleerd. Hiermee werd ook gepartitioneerd.

Voor de Linux was de eerste opzet als volgt:

/dev/hda10  /boot (EXT3)
/dev/hda14  /home (JFS)
/dev/hda15  swap
/dev/hda16  /     (JFS)

Hier kon PARTED echter niet mee overweg. De door OS/2 aangemaakte JFS partities werd niet gemount en Linux had moeite met de door OS/2 aanmaakte JFS partitie aan het eind van de schijf. Maar de zich in de partitietabel verslikkende PARTED vertikte het om partities aan te passen of te te wissen.

Daarna kwam ik tot deze oplossing:

/dev/hda10  /boot (EXT3)
/dev/hda14  /     (JFS)
/dev/hda15  swap
/dev/hda16  /home (JFS)
/dev/hda17  1 cylinder aan het eind       

Met LVM wiste ik de laatste LVM partitie en maakte ik een minimale "compatibility" (hier FAT) volume aan het eind van de vaste schijf aan en daarna JFS in de overgebleven vrije ruimte. LVM maakt standaard partities in de lege ruimte aan het eind van de schijf aan. Vandaar deze volgorde. De idee was om LVM te dwingen om zowel een begin als een eind aan het non compatibility JFS volume te geven. En dat bleek te werken. De Linux fdisk kon de met semi( lees begrensde) compatibility gevulde JFS partities schijf naar behoren te herkennen. Waarschijnlijk waren de OS/2 en Linux IDE drivers het niet een over het aantal sectoren van de schijf. Maar door het compatibity volume aan het eind van de schijf werd de partitietabel toch netjes ingevuld.

Dergelijke methoden kunnen ook nuttig zijn bij het aanmaken van Window eXtended formaten ( FAT32X), waarbij Windows zoal bekend onjuiste partitietabellen aanmaakt.



240 koppen, 63 sectoren/spoor, 2646 cylinders
Eenheden = cylinders van 15120 * 512 = 7741440 bytes

 Apparaat Opstart Start       Einde  Blokken  Id  Systeem
/dev/hda1            70       207   1043280    6  FAT16
/dev/hda2             2        69    514080   16  Verborgen FAT16
/dev/hda3   *         1         1      7528+   a  OS/2 Boot Manager
/dev/hda4           208      2646  18438840    5  Uitgebreid
/dev/hda5   *       208       345   1043248+   6  FAT16
/dev/hda6   *       346       483   1043248+   6  FAT16
/dev/hda7   *       484       551    514048+   7  HPFS/NTFS
/dev/hda8   *       552       633    619888+   6  FAT16
/dev/hda9   *       634       904   2048728+   6  FAT16
/dev/hda10  *       905       918    105808+  83  Linux
/dev/hda11  *       919      1013    718168+   7  HPFS/NTFS
---------------------------------------------------------------
/dev/hda12  *      1014      1284   2048728+   6  FAT16
/dev/hda13  *      1285      1555   2048728+   6  FAT16
/dev/hda14         1556      2097   4097488+  35  Onbekend
/dev/hda15  *      2098      2132    264568+  82  Linux wisselgeheugen
/dev/hda16  *      2133      2644   3870688+  35  Onbekend
/dev/hda17  *      2645      2646     15088+   6  FAT16



Partitietabel ingangen zijn niet in schijfvolgorde



Opdracht (m voor hulp):

Maar Linux bleek niet (zonder fschk) op de onder OS/2 aangemaakte JFS partitie te willen installeren. Een door OS/2 aangemaakte en in fstab aangemeld JFS volume bracht het booten van Linux steeds weer in de problemen. En zeker als die zich aan het eind van de schijf bevond.

Daarna bedacht ik me dat ik wel dat data, maar geen Linux programma's en /etc met OS/2 hoefde te delen. Daarom koos ik voor de volgende configuratie:



/dev/hda10  /boot (EXT3)
/dev/hda14  /     (Reisser)
/dev/hda15  swap
/dev/hda16  geen mountpoint (JFS)
/dev/hda17  1 cylinder aan het eind       

In dit geval wordt /home op /dev/hda14/home (Reisser) gemount.

Het plan was om eerst Linux erop te krijgen en daarna /home naar /dev/hda16 = /data (JFS) te kopiëren en daarna via een aangepaste fstab /data/home als /home te mounten. Dat ziet er dan zo uit:

/dev/hda14           /                    reiserfs   defaults              1 1
/dev/hda16           /data                jfs        noauto                0 0
/dev/hda10           /boot                ext2       defaults              1 2
/dev/hda15           swap                 swap       pri=42                0 0
devpts               /dev/pts             devpts     mode=0620,gid=5       0 0
proc                 /proc                proc       defaults              0 0
usbdevfs             /proc/bus/usb        usbdevfs   noauto                0 0
/dev/cdrom           /media/cdrom         auto       ro,noauto,user,exec   0 0
/dev/fd0             /media/floppy        auto       noauto,user,sync      0 0

Maar /data was zo niet zomaar te mounten.

Last login: Tue Oct 21 23:27:30 2003 from ecs
Have a lot of fun...
sjoerd@deskpro:~> su
Password:
deskpro:/home/sjoerd # mount /data
mount: slechte bestandssysteem soort, slechte optie, slecht superblok op /dev/hd
a16,of teveel aangekoppelde bestandssystemen
deskpro:/home/sjoerd #

Na een fsck (chkdsk) onder Linux ging het wel:

deskpro:/home/sjoerd # fsck /dev/hda16
fsck 1.28 (31-Aug-2002)
fsck.jfs version 1.1.1, 17-Dec-2002
The current device is:  /dev/hda16
Block size in bytes:  4096
File system size in blocks:  965900
Phase 0 - Replay Journal Log
File system is clean.
deskpro:/home/sjoerd # mount /data
deskpro:/home/sjoerd #

Daarna kopieerde ik als root /home naar /data, hernoemde /home (Reisser) naar de al backup bedoelde home1 (Reisser), maakte een symlink van /data/home (JFS) naar /home (gaat simpel via de nc) en kon daarna als "sjoerd" op /data/home/sjoerd onder JFS werken.

Kortom: eenvoudig is het delen van JFS onder Linux en OS/2 nog niet. En er zijn geen garanties. Maar aan de ander kant geldt dat de intenties van de bestandssysteemmakers (lees: een open source minded IBM) goed is. Anders dan Microsoft met zijn closed source bestandssystemen wil IBM uw data niet in een legacy val opsluiten. U kunt er onder Linux en andere JFS ondersteunende (in de toekomst wellicht die van MS) besturingssystemen goed bij.

JFS onder Linux benaderen

> Top <

Moderne Linux distributies als SuSE 8.2 (mijn testsysteem) ondersteunen het Journaling File System goed. Oudere distributies bevatten Linux JFS implementaties die niet met de OS/2 versie compatibel waren..

JFS moet met een block size van 4097 bytes aangemaakt zijn.

Vergeleken met HPFS en FAT, VFAT en FAT32 zijn er weinig mount opties aanwezig.

The following mount options are supported:

iocharset=name
Character set to use for converting from Unicode to ASCII. The default is compiled into the kernel as CONFIG_NLS_DEFAULT.  Use iocharset=utf8 for UTF8 translations. This requires CONFIG_NLS_UTF8 to be set in the kernel .config file.

resize=value
Resize the volume to <value> blocks.  JFS only supports growing a volume, not shrinking it.  This option is only valid during a remount, when the volume is mounted read-write. The resize keyword with no value will grow the volume to the full size of the partition.

Nointegrity
Do not write to the journal. The primary use of this option is to allow for higher performance when restoring a volume from backup media.  The integrity of the volume is not guaranteed if the system abnormally ends.

Integrity
Default.  Commit metadata changes to the journal.  Use this option to remount a volume where the nointegrity option was previously specified in order to restore normal behavior.

Een stukje fstab:

# Met OS/2 gedeelde HPFS en JFS partities
/dev/hda10      /mnt/os2bin  jfs defaults        1 2
/dev/hda11      /mnt/data    jfs defaults        1 2
/dev/sda5      /mnt/usbide   jfs defaults        1 2

De laatste ingang betreft een met JFS geformatteerde IDE schijf met een USB 2 interface zoals door Gerrit Schoenmaker beschreven in het VOICE artikel Mounting USB 2.0 harddisk case in eComStation.

SuSE Linux voegt de door haar herkende hot pluggable device dynamisch aan fstab toe. Als u niet weet op welk device uw partities zitten, kunt u dus cat /etc/fstab proberen. Daarnaast geeft fdisk /dev/sda vaak raad.

Bestandsrechten onder Linux en OS/2

> Top <

OS/2 is een single-user systeem. Iedere gebruiker mag op de prompt doen wat hij wil. Als Jan een bestand aanmaakt, kan gebruiker Piet ze wissen. Alleen onder HPFS386 kunnen lokale bestandspermissies worden ingesteld. Maarvanuit Linux bekeken wekt iedere OS/2 gebruiker met een rootaccount.

Linux is daarentegen een multi-user systeem: Ieder bestand krijgt de bestandsrechten van degene die ze maakt of download. Alleen de eigenaar of root mag de bestandspermissies wijzigen. Ze kunnen afhankelijk van de umask variabele scherper of minder scherp ingesteld zijn. Maar ze hebben altijd het user-id (uid) en het groups-id (gid) van zijn gebruiker aan zich gebonden.

Maar voor een bestand of map die u onder OS/2 op een JFS volume zet, geldt dit niet. Als u ze vanuit Linux benadert bezitten ze de uid en gid van root en geen enkele permissie:

 232992 d---------    2 root     root         4096 2003-09-11 15:53 licenses
 232613 ----------    1 root     root       306846 2002-09-19 17:50 mozjs.dll

Maar dat is met een rootaccount niet zo'n probleem:

sjoerd@suse8:~> su
Password:
suse8:/home/sjoerd # chown --recursive sjoerd /mnt/data
suse8:/home/sjoerd # chgrp --recursive users /mnt/data
suse8:/home/sjoerd # chmod --recursive 0711 /mnt/data

U kunt er een script van maken.

#!/bin/bash
chown --recursive sjoerd /mnt/data
chgrp --recursive users /mnt/data
chmod --recursive 0711 /mnt/data

De gewijzigde bestandspermissies gelden alleen voor Linux. Want onder OS/2 werkt u weer met het (vanuit Linux bekeken) root account. OS/2 merkt de UNIX bestandspermissies van JFS niet op. OS/2 doet dus niets met de permissies van een bestaand bestand. Ook niet als u het wijzigt. Hoogstens moet u er op letten dat uw editor UNIX compatibel is.

Maar als u het opnieuw opslaat onder een andere naam of het oude bestand vervangt, dan krijgt het bestand rootrechten. Het wordt dan een nieuw bestand met een ander inode nummer. Het zelfde geldt als de tekstverwerker tijdelijke bestanden aanmaakt of het oorspronkelijke bestand als een bak bestand opslaat. In alle gevallen maakt u via uw tekstverwerker technisch gezien een nieuw bestand aan.

Ik kwam hier tijdens het schrijven van deze tekst achter. Nadat ik deze tekst onder OS/2 bewerkt had, kon ik er plots niet meer bij.

  86104 ----------    1 root     root        12924 2003-09-12 22:39 jfs.html
  86105 -rwx--x--x    1 sjoerd   users        5114 2002-11-11 23:48 links.html
  86106 -rwx--x--x    1 sjoerd   users       49109 2002-12-03 00:19 lvm.html

In dit geval stond StarOffice zo ingesteld dat het steeds een reservekopie (bak bestand) maakte. Mogelijk hield het bak bestand de rechten van gebruiker sjoerd (ik kon het niet nagaan want het bak bestand zat op HPFS), maar het gewijzigde bestand jfs.html werd in ieder geval (dat dacht ik) als een nieuw bestand opgeslagen. En een nieuw bestand kreeg dus de bij OS/2 behorende rootrechten. Ik zette daarna StarOffice's "Altijd een reserverkopie maken" optie maar uit. Maar tot mijn verbazing had het bestand nog steeds hetzelfde inode nummer, maar waren de rechten wel veranderd.

  86104 ----------    1 root     root        12924 2003-09-12 22:39 jfs.html

Of het toegekende inode nummer was toevallig hetzelfde of mijn theorie was helemaal fout.

Ik ging weer naar mijn /home/sjoerd/.emacs bestand dat ik opnieuw onder OS/2 met e.exe had bewerkt. Het met Ctrl-S opgslagen en bewerkte bestand had nog steeds hetzelfde inode nummer en de bijbehorende permissies, alleen de kopie die ik met OS/2's rootrechten als .emacsos2 opsloeg kwam zoals verwacht met exclusieve rootrechten op de wereld. Wat me wel verbaasde was het lage inode nummer van de kopie. Ik had verwacht dat OS/2 er een hoger nummer aan zou toekennen. Blijkbaar was een eerder bestand 4226 al gewist.

   5190 -rw-r--r--    1 sjoerd   users        1683 2003-09-13 00:24 .emacs
   4226 ----------    1 root     root         1685 2003-09-13 00:24 .emacsos2

Onder Linux worden inode nummers sequentieel toegekend:

sjoerd@suse8:~> touch 1
sjoerd@suse8:~> touch 2
sjoerd@suse8:~> touch 3
sjoerd@suse8:~> touch 4

Levert het volgende op (ik laat niet alles zien):

sjoerd@suse8:~> ls -ila
 131165 -rw-r--r--    1 sjoerd   users           0 2003-09-12 23:34 1
 131166 -rw-r--r--    1 sjoerd   users           0 2003-09-12 23:34 2
 131167 -rw-r--r--    1 sjoerd   users           0 2003-09-12 23:34 3
 131169 -rw-r--r--    1 sjoerd   users           0 2003-09-12 23:34 4
 266241 drwx------    3 sjoerd   users         256 2003-09-12 22:54 Desktop

Als ik nu het bestand met inode nummer 131166 wis:

sjoerd@suse8:~> del 2
Error: Try the command: rm -iv 2
sjoerd@suse8:~> rm -iv 2
rm: remove regular empty file `2'? y
removed `2'

En een nieuw bestand 5 aanmaak:

sjoerd@suse8:~> touch 5
sjoerd@suse8:~> ls -ila
 131165 -rw-r--r--    1 sjoerd   users           0 2003-09-12 23:34 1
 131167 -rw-r--r--    1 sjoerd   users           0 2003-09-12 23:34 3
 131169 -rw-r--r--    1 sjoerd   users           0 2003-09-12 23:34 4
 131170 -rw-r--r--    1 sjoerd   users           0 2003-09-12 23:39 5

Dan zou je verwachten dat het oude inode nummer vrijkwam en er een nieuw bestand met het vrijgekomen inode nummer wordt aangemaakt. Maar dat bleek hier niet het geval. Was inode nummer 131166 door een ander proces ingepikt? Find heeft een optie hiervoor (type man find, /inode):

  -inum n
              File has inode number n.

Ik laat find erop los, want ik wil het weten.

sjoerd@suse8:~> find -inum 131166
find: ./homepage: Toegang geweigerd

De zoekactie in de home directory leverde niets op (behalve dan dat ik homepage als root onder OS/2 naar /home/sjoerd gekopieerd had.)

sjoerd@suse8:~> su
Password:
suse8:/home/sjoerd # find -inum 131166

Ik had eigenlijk verwacht dat het verdwenen inode nummer in de als /home gemounte /dev/hda15 OS/2 JFS partitie zou zitten. Maar /homes kwam in de find actie niet voor. Wel andere bestanden in /mnt/os2bin/ waarvan de door find gevonden zoeknamen je het ergste doen vermoeden over de ogenschijnlijke incompatibiliteit van JFS onder Linux en OS/2...

suse8:/home/sjoerd # find / -inum 131166
/mnt/jfs2/k/Sslurp/www1.computerwoche.de/heftarchiv/1996/19960705/a26421.html
find: /mnt/os2bin/XFree86/lib/X11/gnome/apps/Games/¶&euro;È Í? Gnome.desktop: Onbekend bestand of map
find: /mnt/os2bin/XFree86/lib/X11/gnome/apps/Utilities/Ú?ã&euro;Ê????Ð &euro; &Yuml;?ËÈ???....desktop: Onbekend bestand of map
/usr/share/texmf/doc/fonts/eurosym/COPYING
find: /proc/3528/fd/4: Onbekend bestand of map
suse8:/home/sjoerd #

Dergelijke bestandsnamen kunt u beter niet openen. Want als ze al te openen zijn (Onbekend bestand of map) kan OS/2 er daarna niets mee. En dat is vragen om WPS en bootproblemen.

Ik hoop dat met de mount optie iocharset=name op te lossen is, want ander is dit compatibiliteitsprobleem onoverkomelijk.

Het inode nummer was waarschijnlijk door een actueel proces (/proc/3528/fd/4) ingepikt. De overige mappen heb ik bij mijn weten niet benaderd. Maar het komt er dus wel op neer dat Linux de inode nummers toebedeeld en dat ook kan doen op een geheel ander station. Blijkbaar weet Linux de inodes van de verschillende partities uit elkaar te houden, maar de door find gegenereerde bestandsnamen stellen me niet gerust.

Toen ik het weer in OpenOffice onder Linux wilde openen kreeg ik geen rechten. Het uitzetten van reservekopie maken hielp ook niet. Nu verdenk ik StarOffice ervan dat het vanuit zijn tijdelijke bestanden in de %TEMP% map steeds weer nieuwe bestand genereert.

Want het verborgen bestand .emacs in mijn /home/sjoerd directory die ik met e opende, bewerkte en met Ctr-S weer opsloeg bleef zijn oude rechten behouden. Alleen als ik het met "Opslaan als" als een nieuw bestand opsloeg, raakte het zijn permissies kwijt.

JFS utilities

> Top <

Met de volgende regels wordt het JFS stuurbestand in CONFIG.SYS geladen.

DEVICE=F:\OS2\BOOT\UNICODE.SYS
IFS=F:\OS2\JFS.IFS /LW:5,20,4 /AUTOCHECK:* /CACHE:128000

Hier wordt JFS met een 128.000 KB cache gestart. De opdracht voor UNICODE.SYS moet aan JFS.SYS voorafgaan.

De JFS cache installen

Met de opdracht CACHEJFS kunt u de JFS cache parameters opvragen en bijstellen.

[F:\]cachejfs

          SyncTime:       5 seconds
            MaxAge:      20 seconds
        BufferIdle:       4 seconds
        Cache Size:  128000 kbytes
        Min Free buffers:     640 (    2560 K)
        Max Free buffers:    1280 (    5120 K)
Lazy Write is enabled

De grootte van de JFS cache is standaard 12,5 % van het fysieke geheugen. Met de JFS.IFS parameter /CACHE:128000 wordt hij op 128000 kB ingesteld. Helaas kan de grootte van de JFS cache na het booten niet meer worden bijgesteld. En ook een dynamische grootte aanpassing aan de hand van het beschikbare geheugen ontbreekt.

Wel kunt u het overige gedrag instellen met:

[F:\]cachejfs /help
CACHEJFS [[/LAZYWRITE:]{OFF|synctime[,maxage[,bufferidle]]}]
         [/MINFREE:minfree] [/MAXFREE:maxfree]

Met /LW wordt "lazy write" (vertraagd doorvoeren) ingeschakeld. Veranderingen worden pas na een bepaald interval naar de schrijf geschreven. Als een bestand (bijv. een logbestand) aldoor beschreven wordt zal de vaste schijf pas na de MaxAge periode worden beschreven.

Een synchronisatie interval van 64 seconden (hier 5 sec.)

De maximale leeftijd waarin veranderde bestanden in de buffer gehouden kunnen worden is de synchronisatietijd maal 4 seconden (hier 5*4=20 sec)

Veranderingen die jonger zijn dan de buffer idle waarde (MIN(1,synctime/8) seconden, hier 4 sec. ) worden nog niet weggeschreven.

JFS defragmenteren

JFS bevat resistentie tegen fragmentatie. Maar fragmentatie komt desalniettemin wel voor.

U kunt de mate van fragmentatie van station I: opvragen (/question) met:

[F:\]defragfs /q i:

Totaal aantal toewijzingsgroepen: 128.
15 toewijzingsgroepen zijn overgeslagen - volledig vrijgegeven.
25 toewijzingsgroepen zijn overgeslagen - te weinig vrije blokken.
1 toewijzingsgroepen zijn overgeslagen - bevat een te grote aaneengesloten
beschikbare ruimte.
87 toewijzingsgroepen komen in aanmerking voor defragmentering.
Gemiddeld aantal vrijgegeven verwerkingen in toewijzingsgroepen die
in aanmerking komen: 657.

Maar met de opdracht DEFRAGFS [schijf]: kunt u JFS volumes defragmenteren. De opdracht werkt meestal ook op een bestandssysteem met geopende bestanden.

[F:\]defragfs i:
Station i: wordt gedefragmenteerd. Even geduld a.u.b.

Totaal aantal toewijzingsgroepen: 128.
15 toewijzingsgroepen zijn overgeslagen - volledig vrijgegeven.
25 toewijzingsgroepen zijn overgeslagen - te weinig vrije blokken.
1 toewijzingsgroepen zijn overgeslagen - bevat een te grote aaneengesloten
beschikbare ruimte.
87 toewijzingsgroepen komen in aanmerking voor defragmentering.

DEFRAGFS is zonder problemen voltooid.

Totaal aantal toewijzingsgroepen: 128.
15 toewijzingsgroepen zijn overgeslagen - volledig vrijgegeven.
25 toewijzingsgroepen zijn overgeslagen - te weinig vrije blokken.
1 toewijzingsgroepen zijn overgeslagen - bevat een te grote aaneengesloten beschikbare ruimte.
87 toewijzingsgroepen zijn gedefragmenteerd.
Gemiddeld aantal vrijgegeven verwerkingen in toewijzingsgroepen die in aanmerking komen: 585.

Soms werkt het niet :

[F:\DESKTOP]defragfs n:
Defragmenting drive n:.  Please wait.

SYS1808:
The process has stopped.  The software diagnostic code (exception code) is  0005.

Dit station N: was via NFS als /home onder Linux gemount. Maar een tweede poging lukt vaak wel.

Let op: De auteur van "JRescuer for JFS", Pavel Shtemenko beschouwt het defragmenteren van JFS gevaarlijk.

Het aanhouden van voldoende vrije ruimte op de schijf (15%) biedt waarschijnlijk de beste garantie tegen fragmentatie.

JFS en het Unicode systeem

> Top <

Bestanden, bestandsnamen en mappen bevatten tekens. De beschikbare tekens (characters) worden door uw tekenset (codepage) bepaald. Op het scherm worden de tekens door fonts weergegeven. Maar de tekens worden door de computer als reeksen van nullen en enen verwerkt en opgeslagen. De computer werkt immers digitaal. De gehanteerde versleutelings en decodeertechniek is dus van groot belang. Hoe zit dat?

Ieder bestandssysteem kan bestanden bevatten die onder verschillende talen (tekensets) zijn aangemaakt. Daarnaast kunt u verschillende tekensets voor dezelfde taal gebruiken. Zo maakt het uit als uw brief onder DOS en OS/2's CP850 of onder Windows ANSI wordt versleuteld en opgeslagen. Daarom is het handig als uw bestandssysteem hier rekening mee houdt. Want via het netwerk en of via een multiboot PC kunt kunt uw bestanden met vele tekensets benaderen.



Het de vele tekensets integrerende UNICODE.SYS stuurbestand moet daarom voor de JFS.IFS, UDF.IFS en andere installeerbare stuurbestanden staan.

DEVICE=F:\OS2\BOOT\UNICODE.SYS
IFS=F:\OS2\JFS.IFS /LW:5,20,4 /AUTOCHECK:* /CACHE:128000

De Unicode support driver van de WSEB kernel verzorgt de codepage vertaling van de kernel (FAT) en installeerbare stuurbestanden (HPFS, JFS, NTFS, FAT32).

Clustergrootte

> Top <

De meeste bestandssystemen verdelen de schijf in clusters. IBM spreekt van blocksize. Deze wordt er tijdens het formatteren ingebracht (type: help format):

FORMAT [drive]: /FS:JFS /BS:blocksize

Onder OS/2 zijn blokgroottes van 512, 1024, 2048 or 4096 bytes toegestaan. 512 bytes is tevens de kleinste eenheid van de vaste schijf (sectorgrootte) Als de /BS parameter weggelaten wordt gaat FORMAT uit van een blokgrootte van 4096 bytes. Ten tijde van dit schrijven werd alleen de blokgrootte van 4096 bytes door JFS voor Linux ondersteund.

Het lezen, schijven en bijhouden van de bestanden op het bestandssysteem gaat sneller als er minder blokken hoeven te worden benaderd. Maar te grote blokken (clusters) leveren verspilling van vaste schijfruimte op. Dit speelt vooral op FAT met clusters tot 32 kB (cluster). Bij een clustergroote van 4 kb (FAT32, JFS voor Linux) neemt ieder bestand minimaal 4096 bytes in beslag. Gemiddeld worden er 2048 bytes per bestand verspilt. Dat is 8 maal zo veel als bij HPFS dat met 512 bytes uitkomt. Houdt hier rekening meer als u partities met veel kleine bestanden (mail, caches) naar JFS omzet. En bedenk ook dat HPFS veel zuiniger met uitgebreide attributen omspringt dan JFS.

Hoeveel een kleine blokgrootte u oplevert kunt u op het FAT bestandssysteem aan de hand van het aantal bestanden berekenen. De slack is de helft van blokgrootte maal het aantal bestanden. Maar voor JFS gaat deze vlieger niet op. Het is een heel ander bestandssysteem.

Informatie over het bestandssysteem krijgt u met CHKDSK [volume:]

J:\>chkdsk
The current hard disk drive is: J:
The type of file system for the disk is JFS.
The JFS file system program has been started.
CHKDSK  File system is currently mounted.
JFS0138: CHKDSK  Checking a mounted file system does not produce dependable results.

CHKDSK  Block size in bytes:  4096
CHKDSK  File system size in blocks:  1022127
CHKDSK *Phase 1 - Check Blocks, Files/Directories, and Directory Entries
CHKDSK *Phase 2 - Count Links
CHKDSK *Phase 3 - Rescan for Duplicate Blocks and Verify Directory Tree
CHKDSK *Phase 4 - Report Problems
CHKDSK *Phase 7 - Verify File/Directory Allocation Maps
CHKDSK *Phase 8 - Verify Disk Allocation Maps
CHKDSK  Incorrect data detected in disk allocation structures.
  4088508 kilobytes total disk space.
     4065 kilobytes are in 1666 directories.
  2834552 kilobytes are in 38640 user files.
   116608 kilobytes are in extended attributes.
    26701 kilobytes are reserved for system use.
  1108052 kilobytes are available for use.
JFS0138: CHKDSK  Checking a mounted file system does not produce dependable
results.

CHKDSK  File system is dirty.
CHKDSK  File system is dirty but is marked clean.  In its present state, the results of accessing J: (except by this utility) are undefined.
    ..|......
J:\>

Hier gaat het om 38640 bestanden in 1666 directories. Aangezien ook mappen bestanden vertegenwoordigen tel ik 38640 en 1666 bij elkaar op (40306). De gemiddelde slack is dus 40306 maal 2 kb (80612 kb).

Backup maken:

Y:\>xcopy j:\*.* y:\j\*.* /h/o/t/s/e/r/v

Met een blocksize van 1024 bytes formatteren.

Y:\>format j: /fs:jfs /bs:1024

Backup terugzetten:

Y:\>xcopy y:\j\*.* j:\*.* /h/o/t/s/e/r/v
.....
38640 file(s) copied.

Wat levert het op?

Y:\>chkdsk j:
The current hard disk drive is: J:
The type of file system for the disk is JFS.
The JFS file system program has been started.
CHKDSK  File system is currently mounted.
JFS0138: CHKDSK  Checking a mounted file system does not produce dependable results.

CHKDSK  Block size in bytes:  1024
CHKDSK  File system size in blocks:  4088511
CHKDSK *Phase 1 - Check Blocks, Files/Directories, and Directory Entries
CHKDSK *Phase 2 - Count Links
CHKDSK *Phase 3 - Rescan for Duplicate Blocks and Verify Directory Tree
CHKDSK *Phase 4 - Report Problems
CHKDSK *Phase 7 - Verify File/Directory Allocation Maps
CHKDSK *Phase 8 - Verify Disk Allocation Maps
CHKDSK  Incorrect data detected in disk allocation structures.
  4088511 kilobytes total disk space.
     2782 kilobytes are in 1666 directories.
  2778148 kilobytes are in 38640 user files.
    41989 kilobytes are in extended attributes.
    25349 kilobytes are reserved for system use.
  1245807 kilobytes are available for use.
JFS0138: CHKDSK  Checking a mounted file system does not produce dependable results.

CHKDSK  File system is dirty.
CHKDSK  File system is dirty but is marked clean.  In its present state, the results of accessing j: (except by this utility) are undefined.
    .......|.

Wat levert het aan vrije ruimte op? 1245807 minus 1108052 = 137755 kilobytes. Dat is dus meer dan berekend.

Het verschil zit hem in de uitgebreide attributen, die net als mappen als afzonderlijke bestanden worden opgeslagen. Daarom is x in "x kilobytes are in extended attributes" ook steeds een meervoud (bijv. hier vierfout) van de blokgrootte.

  4080476 kilobytes total disk space.
     9276 kilobytes are in 3905 directories.
  2630439 kilobytes are in 73439 user files.
    12692 kilobytes are in extended attributes.
    39133 kilobytes are reserved for system use.
  1407488 kilobytes are available for use.

Nog een test. De bestanden van J (JFS met blokgrootte van 512 bytes) worden met dsync naar D (HPFS) overgebracht. Dsync zorgt vor een identieke synchronisatie.

Wat geeft een chkdsk J (JFS)?

[F:\]chkdsk j: /f
Het actieve station met vaste schijf is: J:
Het type bestandssysteem voor de schijf is JFS.
Bestandssysteem JFS is gestart.
CHKDSK - Blokgrootte in bytes: 512
....
  4088511 kilobyte totale schijfruimte
     2673 kilobyte in 1782 directory's.
  3306703 kilobyte in 25917 gebruikersbestanden.
    25940 kilobyte voor uitgebreide kenmerken.
   273255 kilobyte voor gebruik door het systeem.
   485286 kilobyte beschikbaar voor gebruik.
...
CHKDSK - LVM meldt 0 beschadigde blokken. Hiervan zijn er 0
overgebracht naar de JFS-lijst van beschadigde blokken.

Wat geeft een chkdsk D (HPFS)?

[F:\]chkdsk d: /f
Het actieve station met vaste schijf is: D:
Het type bestandssysteem voor de schijf is HPFS.
Bestandssysteem HPFS is gestart.
CHKDSK is searching for lost data.
CHKDSK has searched 100% of the disk.
   4096542 kilobytes total disk space.
      5995 kilobytes are in 1782 directories.
   3306663 kilobytes are in 25917 user files.
     22957 kilobytes are in extended attributes.
      6062 kilobytes are reserved for system use.
    754865 kilobytes are available for use.

HPFS springt wat zuiniger met de data om: na een dsync operatie bevatten de beide partities evenveel bestanden, maar JFS heeft 4088511 - 485286= 3603225 kilobytes gebruikt en HPFS 4096542 - 754865= 3341677 kilobytes. Dat is (3603225/ 3341677= 1,08=) 8% zoveel als HPFS. Dit komt deels door het minder efficiënt opslaan van de uitgebreide attributen in aparte bestanden door JFS. Daarnaast gebruikt een 4GB HPFS schijf minder systeem overhead (6062/4096542= 0,148%) dan een 4GB JFS systeem ( 27325/4088511 = 0,67%). Maar dit is te verwachten bij een alle recente transacties loggend bestandssysteem.

Conclusie: kleine databestanden met uitgebreide attributen kon u op HPFS goed kwijt. Met een blokgrootte van 512 bytes worden uitgebreide attributen ook efficiënt door JFS opgeslagen. Maar het nadeel van de 512 bytes blokgrootte is dat u de JFS partitie niet meer vanuit Linux benaderen kunt. Dat kan alleen met een blokgrootte van 4 kb waarin een WPS URL object van 40 bytes in 8 kiloBytes (4 kB voor de data en 4 kB voor de EA's) wordt opgeslagen.

HPFS onder Linux

> Top <

Ook HPFS is onder Linux te benaderen. De HPFS r/w driver van Mikulas Patocka maakt deel uit van de bij SuSE 8.2 geleverde 2.4.20 kernel. De driver kan de bestandspermissies in de uitgebreide attributen opslaan. Maar het is doorgaans gemakkelijker om de HPFS schijf meteen als gebruiker te benaderen. Dit werkt trouwens ook met FAT, vFAT en FAT32.

/dev/hda7       /mnt/ecs1       hpfs    user,gid=100,uid=500,umask=022 1 2
/dev/hda8       /mnt/ecs2       hpfs    user,gid=100,uid=500,umask=022 1 2

Uw id is op te vragen met:

sjoerd@suse8:~> id sjoerd
uid=500(sjoerd) gid=100(users) groepen=100(users),14(uucp),16(dialout),17(audio),33(video)

Het is wel nuttig om deze consequent toe te kennen, want ook NFS werkt ermee.

Bovenstaande fstab geldt voor user sjoerd (id 500):

suse8:/mnt/ecs1/os2 # ls -ila
totaal 10906
442232 drwxr-xr-x 19 sjoerd users 22528 2003-09-11 17:07 .
2113244 drwxr-xr-x 38 sjoerd users 6144 2003-09-11 00:39 ..
1504061 -rw-r--r-- 1 sjoerd users 6494 2000-05-01 17:48 8514.RC
1504075 -rw-r--r-- 1 sjoerd users 6497 2000-05-01 17:48 8514M.RC
1504089 -rw-r--r-- 1 sjoerd users 5139 2002-03-11 09:04 ANSI.EXE

Let op: de Linux HPFS driver werkt niet altijd goed samen met HPFS386!



Meer lezen



> Top <

[Jfs-discussion]

Linux LVM-HOWTO

JFS Cookbook: Toen dit geschreven werd (16 October 2001) waren er nog allerlei JFS problemen.

Maar Installing eComStation on a JFS Volume is nu een reële optie.

> Top <