Minggu, 12 Agustus 2012

file manager


1.File Management

1.1 Pengaturan file

AAktori tidak mempunyai tipe, sedangkan berkas mempunyai banyak tipe.
Direktori pada Unix
Struktur direktori yang digunakan dalam Unix adalah struktur direktori
tradisional. Seperti yang terdapat dalam gambar direktori entri dalam Unix,
setiap entri berisi nama berkas dan nomor inode yang bersangkutan. Semua
informasi dari jenis, kapasitas, waktu dan kepemilikan, serta block disk yang
berisi inode. Sistem Unix terkadang mempunyai penampakan yang berbe-
da,tetapi pada beberapa kasus, direktori entri biasanya hanya string ASCII
dan nomor inode.
_
Gambar 2.3: Direktori Unix
Saat berkas dibuka, sistem berkas harus mengambil nama berkas dan men-
galokasikan block disk yang bersangkutan, sebagai contoh, nama path /usr/ast/
mbox dicari, dan kita menggunakan Unix sebagai contoh, tetapi algoritma
yang digunakan secara dasar sama dengan semua hirarki sistem direktori sis-
tem.
Pertama, sistem berkas mengalokasikan direktori root. Dalam Unix inode
yang bersangkutan ditempatkan dalam tempat yang sudah tertentu dalam
disk. Kemudian, Unix melihat komponen pertama dari path, usr dalam direk-
tori root menemukan nomor inode dari direktori /usr. Mengalokasikan sebuah
nomor inode adalah secara straight-forward, sejak setiap inode mempunyai
lokasi yang tetap dalam disk. Dari inode ini, sistem mengalokasikan direk-
tori untuk /usr dan melihat komponen berikutnya, dst. Saat dia menemukan
entri untuk ast, dia sudah mempunyai inode untuk direktori /ust/ast. Dari
inode ini, dia dapat menemukan direktorinya dan melihat mbox. Inode un-
tuk berkas ini kemudian dibaca ke dalam memori dan disimpan disana sampai
berkas tersebut ditutup.
Nama path dilihat dengan cara yang relatif sama dengan yang absolut.
Dimulai dari direktori yang bekerja sebagai pengganti root directory. Seti-
ap direktori mempunyai entri untuk. dan ”..” yang dimasukkan ke dalam
saat direktori dibuat. Entri ”.” mempunyai nomor inode yang menunjuk ke
direktori di atasnya/orangtua (parent), ”.” kemudian melihat ../dick/prog.c
hanya melihat tanda ”..” dalam direktori yang bekerja, dengan menemukan
nomor inode dalam direktori di atasnya/parent dan mencari direktori disk.
Tidak ada mekanisme spesial yang dibutukan untuk mengatasi masalah nama
ini. Sejauh masih di dalam sistem direktori, mereka hanya merupakan ASCII
string yang biasa. Dari nomor inode ini kita memperoleh inode yang meru-
pakan suatu struktur data yang menyimpan informasi berkas. Penghapusan
berkas dilakukan dengan cara melepas inode. Inode ini berisi informasi tentang
:
• tipe
• ukuran
• waktu
• owner
• blok-blok disk
_
Gambar 2.4: Bagaimana file di UNIX ditampilkan

2.Konsep Mounting

 2.1 Mounting


Mounting adalah proses mengkaitkan sebuah sistem berkas yang baru dite-
mukan pada sebuah piranti ke struktur direktori utama yang sedang dipakai.
Piranti-piranti yang akan di-mount dapat berupa cd-rom, disket atau sebuah
zip-drive. Tiap-tiap sistem berkas yang akan di-mount akan diberikan sebuah
mount point, atau sebuah direktori dalam pohon direktori sistem Anda, yang
sedang diakses. Sistem berkas yang dideskripsikan di /etc/fstab(fstab adalah
singkatan dari filesystem tables) biasanya akan di-mount saat komputer baru
dimulai dinyalakan, tapi dapat juga me-mount sistem berkas tambahan dengan
menggunakan perintah:
mount[nama_piranti]

Atau dapat juga dengan menambahkan secara manual mount point ke
berkas /etc/fstab. Daftar sistem berkas yang di-mount dapat dilihat kapan
saja dengan menggunakan perintah mount. Karena izinnya hanya diatur read-
only di berkas fstab, maka tidak perlu khwatir pengguna lain kana menco-
ba mengubah dan menulis mount point yang baru. Seperti biasa saat ingin
mengutak-atik berkas konfigurasi seperti mengubah isi berkas fstab, pastikan
untuk membuat berkas cadangan untuk mencegah terjadinya kesalahan teknis
yang dapat menyebabkan suatu kekacauan. Kita dapat melakukannya dengan
cara menyediakan sebuah disket atau recovery-disk dan mem-back-up berkas
fstab tersebt sebelum membukanya di editor teks untuk diutak-atik. Pada
linux, isi sebuah berkas dibuat nyata tersedia dengan mengabungkan sistem
berkas ke dalam sebuah sistem direktori melalui sebuah proses yang disebut
mounting.

2.2 Mounting Overview


Mounting membuat sistem berkas, direktori, piranti dan berkas lainnya
menjadi dapat digunakan digunakan di lokasi-lokasi tertentu, sehingga memu-
ngkinkan direktori itu menjadi dapat diakses. Perintah mount mengintruk-
sikan sistem operasi untuk mengkaitkan sebuah sistem berkas ke sebuah direk-
tori khusus.

2.3 Mounting point


Mount point adalah sebuah direktori dimana berkas baru menjadi da-
pat diakses. Untuk me-mount suatu berkas atau direktori, titik mountnya
harus berupa direktori,dan untuk me-mount sebuah berkas,mount pointnya
juga harus berupa berkas.
Ada dua jenis mounting, yaitu remote mounting dan mounting lokal. Re-
mote mounting dilakukan dengan sistem remote dimana data dikirimkan melalui
jalur komunikasi. Network sistem berkas seperti Network File System (NFS),
menharuskan agar file diekspor dulu sebelum dimount. Mounting lokal di-
lakukan di sistem lokal.
Biasanya, sebuah sistem berkas, direktori, atau sebuah berkas di-mount ke
sebuah mount point yang kosong, tapi biasanya hal tersebut tidak diperlukan.
Jika sebuah berkas atau direktori yang akan menjadi mount point berisi da-
ta, data tersebut tidak akan dapat diakses selama direktori/berkas tersebut
sedang dijadikan mount point oleh berkas atau direktori lain. Sebagai ak-
ibatnya, berkas yang di-mount akan menimpa apa yang sebelumnya ada di
direktori/berkas tersebut. Data asli dari direktori itu dapat diakses kembali
bila proses mounting sudah selesai.
Saat sebuah sistem berkas di-mount ke sebuah direktori, izin direktori root
dari berkas yang di-mount akan mengambil alih izin dari mount point. Penge-
cualiannya adalah pada direktori induk akan memiliki atribut .. (double dot).
Agar sistem operasi dapat mengakses sistem berkas yang baru, direktori induk
dari mount point harus tersedia.

2.4 Mounting Sistem Berkas, Direktori, dan Berkas


Ada dua jenis mounting: remote mounting dan mounting lokal. Remote
mounting dilakukan dengan sistem remote dimana data dikirimkan melalui
jalur telekomunikasi. Remote sistem berkas seperti Network File Systems
(NFS), mengharuskan agar file diekspor dulu sebelum di-mount. mounting
lokal dilakukan di sistem lokal.
Tiap-tiap sistem berkas berhubungan dengan piranti yang berbeda. Se-
belum kita menggunakan sebuah sistem berkas, sistem berkas tersebut harus
dihubungkan dengan struktur direktori yang ada (dapat root atau berkas yang
lain yang sudah tersambung). Sebagai contoh, kita dapat me-mount dari
/home/server/database ke mount point yang dispesifikasikan sebagai /home/user1,
/home/user2, and /home/user3 :
• /home/server/database /home/user1
• /home/server/database /home/user2
• /home/server/database /home/user3

3. Sistem File Linux

3.1 Sistem File EXT2


1. Keterangan
      EXT2 adalah file sistem yang ampuh di linux. EXT2 juga merupakan
salah satu file sistem yang paling ampuh dan menjadi dasar dari segala
distribusi linux. Pada EXT2 file sistem, file data disimpan sebagai da-
ta blok. Data blok ini mempunyai panjang yang sama dan meski pun
panjangnya bervariasi diantara EXT2 file sistem, besar blok tersebut di-
tentukan pada saat file sistem dibuat dengan perintah mk2fs. Jika besar
blok adalah 1024 bytes, maka file dengan besar 1025 bytes akan memakai
2 blok. Ini berarti kita membuang setengah blok per file.
EXT2 mendefinisikan topologi file sistem dengan memberikan arti bah-
wa setiap file pada sistem diasosiasiakan dengan struktur data inode.
Sebuah inode menunjukkan blok mana dalam suatu file tentang hak ak-
ses setiap file, waktu modifikasi file, dan tipe file. Setiap file dalam
EXT2 file sistem terdiri dari inode tunggal dan setiap inode mempunyai
nomor identifikasi yang unik. Inode-inode file sistem disimpan dalam
tabel inode. Direktori dalam EXT2 file sistem adalah file khusus yang
mengandung pointer ke inode masing-masing isi direktori tersebut.

2. Inode dalam EXT2
     Inode adalah kerangka dasar yang membangun EXT2. Inode dari
setiap kumpulan blok disimpan dalam tabel inode bersama dengan peta
bit yang menyebabkan sistem dapat mengetahui inode mana yang telah
teralokasi dana inode mana yang belum. MODE: mengandung dia infor-
masi, inode apa dan izin akses yang dimiliki user. OWNER INFO: user
atau grop yang memiliki file atau direktori SIZE: besar file dalam bytes
TIMESTAMPS: kapan waktu pembuatan inode dan waktu terakhir di-
modifikasi. DATABLOKS: pointer ke blok yang mengandung data.
EXT2 inode juga dapat menunjuk pada device khusus, yang mana device
khusus ini bukan merupakan file, tatapi dapat menangani program se-
hingga program dapat mengakses ke device. Semua file device di dalam
drektori /dev dapat membantu program mengakses device.

 

3.2 Sistem File EXT3


EXT3 adalah peningkatan dari EXT2 file sistem. Peningkatan ini memi-
liki beberapa keuntungan, diantaranya:

• Setelah kegagalan sumber daya, ”unclean shutdown”, atau kerusakan
sistem, EXT2 file sistem harus melalui proses pengecekan dengan
program e2fsck. Proses ini dapat membuang waktu sehingga pros-
es booting menjadi sangat lama, khususnya untuk disk besar yang
mengandung banyak sekali data. Dalam proses ini, semua data
tidak dapat diakses.
yang disediakan oleh EXT3 menyebabkan tidak perlu lagi dilakukan
pengecekan data setelah kegagalan sistem. EXT3 hanya dicek bila
ada kerusakan hardware seperti kerusakan hard disk, tetapi keja-
dian ini sangat jarang. Waktu yang diperlukan EXT3 file sistem
setelah terjadi ”unclean shutdown” tidak tergantung dari ukuran
file sistem atau banyaknya file, tetapi tergantung dari besarnya ju-
rnal yang digunakan untuk menjaga konsistensi. Besar jurnal de-
fault memerlukan waktu kira-kira sedetik untuk pulih, tergantung
kecepatan hardware.
• Integritas data
EXT3 menjamin adanya integritas data setelah terjadi kerusakan
atau ”unclean shutdown”. EXT3 memungkinkan kita memilih jenis
dan tipe proteksi dari data.
• Kecepatan
Daripada menulis data lebih dari sekali, EXT3 mempunyai through-
put yang lebih besar daripada EXT2 karena EXT3 memaksimalkan
pergerakan head hard disk. Kita bisa memilih tiga jurnal mode
untuk memaksimalkan kecepatan, tetapi integritas data tidak ter-
jamin.
• Mudah dilakukan migrasi
Kita dapat berpindah dari EXT2 ke sistem EXT3 tanpa melakukan
format ulang.

3.3 Perbandingan ext2 dengan ext3


• Secara umum prinsip-prinsip dalam EXT2 sama dengan EXT3.
Metode pengaksesan file, keamanan data, dan penggunaan disk
space antara kedua file system ini hampir sama.
• Perbedaan mendasar antara kedua file system ini adalah konsep

journaling file system yang digunakan pada EXT3.
• Konsep journaling ini menyebabkan ext2 dan ext3 memiliki Perbe-
daan perbedaan dalam hal daya tahan dan pemulihan data dari
kerusakan.
• Konsep journaling ini menyebabkan EXT3 jauh lebih cepat dari-
pada EXT2 dalam melakukan pemulihan data akibat terjadinya
kerusakan.

3.4 Sistem File Reiser


Reiser file sistem memiliki jurnal yang cepat. Ciri-cirinya mirip
EXT3 file sistem. Reiser file sistem dibuat berdasarkan balance tree
yang cepat. Balance tree unggul dalam hal kinerja, dengan algoritma
yang lebih rumit tentunya.
Reiser file sistem lebih efisien dalam pemenfaatan ruang disk. Jika
kita menulis file 100 bytes, hanya ditempatkan dalam satu blok. File
sistem lain menempatkannya dalam 100 blok. Reiser file sistem tidak
memiliki pengalokasian yang tetap untuk inode. Resier file sistem dapat
menghemat disk sampai dengan 6 persen.

3.5 NILFS


Linux dalam perkembangannya untuk meningkatkan kemampuan-
nya dari filesystem yang telah ada, diciptakan filesystem baru yang sta-
bil dan menawarkan performa lebih baik dari filesystem UFS milik so-
laris. Filesystem yang benama NILFS 1.0 (New Implementation Of a
Log-Structured File system) ini sudah sediakan oleh NTT Labs (Nippon
Telegraph and Telephone’s Cyber Space Laboratories).
Maksud dari log-structured adalah menuliskan semua data dalam
format mirip log yang ditulis berkelanjutan, dan dalam penulisannya
hanya menambahkan baris-baris yang baru ditulis, bukan untuk ditulis
ulang dari awal secara keseluruhan. Pendekatan ini dikatakan dapat
1Artikel infolinux edisi November 2005

mengurangi waktu pencarian data selain itu dapat pula meminimal-
isasi seperti halnya kehilangan data yang sering terjadi pada filesytem-
filesytem yang konvensional Selain itu NILFS dapat juga membuat dan
menyimpan file yang berukuran raksasan.

4. File system Hierarchy Standard


4.1 Sistem File Root


Linux memetakan file system dalam satu hierarki yang disebut root
( / ). Partisi lainnya akan dipetakan (mount) sebagai directory di bawah
root. Hal ini menguntungkan karena file system yang dapat dimount
menjadi tidak terbatas. Windows melakukan pemetaan dalam drive yang
terbagi menjadi A: dan B: untuk floppy drive, dan C: hingga Z: untuk
partisi disk baik lokal maupun hasil mapping network.
Isi dari sistem berkas root harus memadai untuk melakukan op-
erasi boot, restore, recover, dan atau perbaikan pada sistem. Untuk
melakukan operasi boot pada sistem, perlu dilakukan hal-hal untuk mount-
ing sistem berkas lain. Hal ini meliputi konfigurasi data, informasi boot
loader dan keperluan-keperluan lain yang mengatur start-up data. untuk
melakukan recovery dan perbaikan dari sistem, hal-hal yang dibutuhkan
untuk mendiagnosa dan memulihkan sistem yang rusak harus dilakukan
dalam sistem berkas root.
Untuk restore suatu sistem, hal-hal yang dibutuhkan untuk back-
up sistem, seperti floopy disk, tape, dsb harus berada dalam sistem
berkas root. Aplikasi pada komputer tidak diperbolehkan untuk mem-
buat berkas atau subdirektori di dalam direktori root, karena untuk
meningkatkan kemampuan dan keamanan, partisi root sebaiknya dibuat
seminimum mungkin. Selain itu, lokasi-lokasi lain dalam FHS menyedi-
akan fleksibelitas yang lebih dari cukup untuk package manapun.
Direktori root Linux memiliki beberapa direktori yang merupakan
standar direktori pada banyak distro Linux.

4.2 Hirarki /usr


”/usr” adalah bagian utama yang kedua dari sistem berkas. ”/usr”
bersifat shareable dan read-only. Hal ini berarti ”/usr” bersifat shareable
diantara bermacam-macam host FHS-compliant, dan tidak boleh
di-write. Package perangkat lunak yang besar tidak boleh membuat sub-
direktori langsung di bawah hirarki ”/usr” ini.

4.2.1 Pilihan spesifik


Direktori Keterangan
X11R6 Sistem X Window, Versi 11 Release 6
games Games dan educational biner
lib Pustaka
lib (qual) Format pustaka alternatif
src Kode source
Tabel 4.3: Direktori/link yang merupakan pilihan dalam ”/usr”

Penjelasan
• ”/usr/X11R6”: Sistem X Window, Versi 11 Release 6
Hirarki ini disediakan untuk Sistem X Window, Versi 11 Release
6 dan berkas-berkas yang berhubungan. Untuk menyederhanakan
persoalan dan membuat XFree86 lebih kompatibel dengan Sistem X
Window, link simbolik di bawah ini harus ada jika terdapat direktori
”/usr/X11R6”:
– /usr/bin/X11 ! /usr/X11R6/bin
– usr/lib/X11 ! /usr/X11R6/lib/X11
– usr/include/X11 ! /usr/X11R6/include/X11
Link-link di atas dikhususkan untuk kebutuhan dari pengguna saja,
dan perangkat lunak tidak boleh di-install atau diatur melalui link-
link tersebut.
• ”/usr/bin”: Sebagian perintah pengguna
Direktori ini adalah direktori primer untuk perintah- perintah exe-
cutable dalam sistem.
• ”/usr/include”: Direktori untuk include-files standar
Direktori ini berisi penggunaan umum berkas include oleh sistem,
yang digunakan untuk bahasa pemrograman C.
• ”/usr/lib”: Pustaka untuk pemrograman dan package
”/usr/lib” meliputi berkas obyek, pustaka dan biner internal yang
tidak dibuat untuk dieksekusi secara langsung melalui pengguna
atau shell script. Aplikasi-aplikasi dapat menggunakan subdirek-
tori tunggal di bawah ”/usr/lib”. Jika aplikasi tersebut menggu-
nakan subdirektori, semua data yang arsitektur-dependent yang di-
gunakan oleh aplikasi tersebut, harus diletakkan dalam subdirektori
tersebut juga.
Untuk alasan historis, ”/usr/lib/sendmail” harus merupakan link
simbolik ke ”/usr/sbin/sendmail”. Demikian juga, jika ”/lib/X11”
ada, maka ”/usr/lib/X11” harus merupakan link simbolik ke ”/lib/X11”,
atau ke mana pun yang dituju oleh link simbolik ”/lib/X11”.
• ”/usr/lib (qual)”: Format pustaka alternatif
”/usr/lib(qual)” melakukan peranan yang sama seperti ”/usr/lib”
untuk format biner alternatif, namun tidak lagi membutuhkan link
simbolik seperti ”/usr/lib(qual)/sendmail” dan ”/usr/lib(qual)/X11”.

• ”/usr/local/share”
Direktori ini sama dengan ”/usr/share”. Satu-satunya pembat-
as tambahan adalah bahwa direktori ’/usr/local/share/man’ dan
’/usr/local/man’ harus synonomous (biasanya ini berarti salah sat-
unya harus merupakan link simbolik).
• ”/usr/sbin”: Sistem biner standar yang non-vital
Direktori ini berisi biner non-vital mana pun yang digunakan se-
cara eksklusif oleh administrator sistem. Program administrator
sistem yang diperlukan untuk perbaikan sistem, mounting ”/usr”
atau kegunaan penting lainnya harus diletakkan di ”/sbin”.
• ”/usr/share”: Data arsitektur independen
Hirarki ”/usr/share” hanya untuk data-data arsitektur independen
yang read-only. Hirarki ini ditujukan untuk dapat di-share diantara
semua arsitektur platform dari sistem operasi; sebagai contoh: se-
buah site dengan platform i386, Alpha dan PPC dapat me-maintain
sebuah direktori /usr/share yang di-mount secara sentral.
Program atau paket mana pun yang berisi dan memerlukan da-
ta yang tidak perlu dimodifikasi harus menyimpan data tersebut
di ”/usr/share” (atau ”/usr/local/share”, apabila di- install secara
lokal). Sangat direkomendasikan bahwa sebuah subdirektori digu-
nakan dalam /usr/share untuk tujuan ini.
• ”/usr/src”: Kode source
Dalam direktori ini, dapat diletakkan kode-kode source, yang digu-
nakan untuk tujuan referensi.

4.3 Hirarki ”/var”


”/var” berisi berkas data variabel, meliputi berkas dan direktori
spool, data administratif dan logging, serta berkas transient dan tempor-
er. Beberapa bagian dari ”/var” tidak shareable diantara sistem yang
berbeda, antara lain: ”/var/log”, ”/var/lock” dan ”/var/run”. Sedan-
gkan, ”/var/mail”, ”/var/cache/man”, ”/var/cache/fonts” dan ”/var/
spool/news” dapat di-share antar sistem yang berbeda.
”/var” ditetapkan di ini untuk memungkinkan operasi mount ”/usr”
read-only. Segala sesuatu yang melewati ”/usr”, yang telah ditulis se-

lama operasi sistem, harus berada di ”/var”. Jika ”/var” tidak dapat
dibuatkan partisi yang terpisah, biasanya ”/var” dipindahkan ke luar
dari partisi root dan dimasukkan ke dalam partisi ”/usr”.
Bagaimana pun, ”/var” tidak boleh di-link ke ”/usr”, karena hal ini
membuat pemisahan antara ”/usr” dan ”/var” semakin sulit dan biasa
menciptakan konflik dalam penamaan. Sebaliknya, buat link ”/var” ke
”/usr/var”.
_

Penjelasan
• ”/var/cache”: Aplikasi data cache
”/var/cache” ditujukan untuk data cache dari aplikasi. Data terse-
but diciptakan secara lokal sebagai time-consumingM/K atau kalku-
lasi. Aplikasi ini harus dapat menciptakan atau mengembalikan da-
ta. Tidak seperti ”/var/spool”, berkas cache dapat dihapus tanpa
kehilangan data. Berkas yang ditempatkan di bawah ”/var/cache”
dapat expired oleh karena suatu sifat spesifik dalam aplikasi, oleh
administrator sistem, atau keduanya, maka aplikasi ini harus dapat
recover dari penghapusan berkas secara manual.
• ”/var/lib”: Informasi status variabel
Hirarki ini berisi informasi status suatu aplikasi dari sistem. Yang
dimaksud dengan informasi status adalah data yang dimodifikasi
program saat program sedang berjalan. Pengguna tidak diper-
bolehkan untuk memodifikasi berkas di ”/var/lib” untuk mengkon-
figurasi operasi package. Informasi status ini digunakan untuk me-
mantau kondisi dari aplikasi, dan harus tetap valid setelah reboot,

tidak berupa output logging atau pun data spool. Sebuah aplikasi
harus menggunakan subdirektory ”/var/lib” untuk data-datanya.
Terdapat satu subdirektori yang dibutuhkan lagi, yaitu ”/var/lib/
misc”, yang digunakan untuk berkas-berkas status yang tidak mem-
butuhkan subdirektori.
• ”/var/lock”: Lock berkas
Lock berkas harus disimpan dalam struktur direktori /var/lock.
Lock berkas untuk peranti dan sumber lain yang di-share oleh banyak
aplikasi, seperti lock berkas pada serial peranti yang ditemukan
dalam ”/usr/spool/locks” atau ”/usr/spool/uucp”, sekarang dis-
impan di dalam ”/var/lock”. Format yang digunakan untuk isi
dari lock berkas ini harus berupa format lock berkas HDB UUCP.
Format HDB ini adalah untuk menyimpan pengidentifikasi proses
(Process Identifier - PID) sebagai 10 byte angka desimal ASCII,
ditutup dengan baris baru. Sebagai contoh, apabila proses 1230
memegang lock berkas, maka HDO formatnya akan berisi 11 karak-
ter: spasi, spasi, spasi, spasi, spasi, spasi, satu, dua, tiga, nol dan
baris baru.
• ”/var/log”: Berkas dan direktori log
Direktori ini berisi bermacam-macam berkas log. Sebagian besar log
harus ditulis ke dalam direktori ini atau subdirektori yang tepat.
• ”/var/opt”: Data variabel untuk ”/opt”
Data variabel untuk paket di dalam ”/opt” harus di-install dalam
”/var/opt/¡subdir¿”, di mana ¡subdir¿ adalah nama dari subtree
dalam ”/opt” tempat penyimpanan data statik dari package tam-
bahan perangkat lunak.
• ”/var/run”: Data variabel run-time
Direktori ini berisi data informasi sistem yang mendeskripsikan sis-
tem sejak di boot. Berkas di dalam direktori ini harus dihapus dulu
saat pertama memulai proses boot. Berkas pengidentifikasi proses
(PID), yang sebelumnya diletakkan di ”/etc”, sekarang diletakkan
di ”/var/run”. Program yang membaca berkas-berkas PID harus
fleksibel terhadap berkas yang diterima, sebagai contoh: program
tersebut harus dapat mengabaikan ekstra spasi, baris-baris tamba-
han, angka nol yang diletakkan di depan, dll.
• ”/var/spool”: Aplikasi data spool

”/var/spool” berisi data yang sedang menunggu suatu proses. Da-
ta di dalam ”/var/spool” merepresentasikan pekerjaan yang harus
diselesaikan dalam waktu depan (oleh program, pengguna atau ad-
ministrator); biasanya data dihapus sesudah selesai diproses.
• ”/var/tmp”: Berkas temporer ang diletakkan di dalam reboot sis-
tem
Direktori ”/var/tmp” tersedia untuk program yang membutuhkan
berkas temporer atau direktori yang diletakkan dalam reboot sis-
tem. Karena itu, data yang disimpan di ”/var/tmp” lebih berta-
han daripada data di dalam ”/tmp”. Berkas dan direktori yang
berada dalam ”/var/tmp” tidak boleh dihapus saat sistem di-boot.
Walaupun data-data ini secara khusus dihapus dalam site-specific
manner, tetap direkomendasikan bahwa penghapusan dilakukan tidak
sesering penghapusan di ”/tmp”.

5. Implementasi Sistem Berkas


Untuk mengimplementasikan suatu sistem berkas biasanya digu-
nakan beberapa struktur on-disk dan in-memory. Struktur ini bervari-
asi tergantung pada sistem operasi dan sistem berkas, tetapi bebera-
pa prinsip dasar harus tetap diterapkan. Pada struktur on-disk, sistem
berkas mengandung informasi tentang bagaimana mem-boot sistem op-
erasi yang disimpan, jumlah blok, jumlah dan lokasi blok yang masih
kosong, struktur direktori, dan berkas individu.
Setelah berkas selesai dibuat, mula-mula harus dibuka terlebih dahu-
lu. Perintah open mengirim nama berkas ke sistem berkas. Ketika se-
buah berkas dibuka, struktur direktori mencari nama berkas yang di-
inginkan. Ketika berkas ditemukan, FCB (File Control Block) disalin ke
ke tabel system-wide open-file pada memori. Tabel ini juga mempunyai
entri untuk jumlah proses yang membuka berkas tersebut.

5.1 Partisi dan mounting


Informasi boot dapat disimpan di partisi yang berbeda. Semuanya
mempunyai formatnya masing-masing karena pada saat boot, sistem
tidak punya sistem berkas dari perangkat keras dan tidak dapat mema-
hami sistem berkas.
Root partition yang mengandung kernel sistem operasi dan sistem
berkas yang lain, di-mount saat boot. Partisi yang lain di-mount secara
otomatis atau manual (tergantung sistem operasi). Sistem operasi meny-
impan dalam struktur tabel mount dimana sistem berkas di-mount dan
jenis dari sistem berkas.
Pada Unix, sistem berkas dapat di-mount di direktori mana pun.
Ini diimplementasikan dengan mengatur flag di salinan in-memory dari

jenis direktori itu. Flag itu mengindikasikan bahwa direktori adalah
lokasi mount.

5.2 Sistem file virtual


Sistem operasi Unix menggunakan teknik berorientasi obyek untuk
menyederhakan, mengorganisir dan mengelompokkannya sesuai dengan
implementasinya. Penggunaan metode ini memungkinkan berkas-berkas
yang berbeda jenisnya diimplementasikan dalam struktur yang sama.
Implementasi spesifiknya menggunakan struktur data dan prosedur un-
tuk mengisolasi fungsi dasar dari system call.
Virtual File System (VFS) memiliki fungsi yang penting yaitu :
• Memisahkan operasi berkas generic dari implementasinya dengan
mendefinisikan VFS antar muka yang masih baru.
• VFS didasarkan pada struktur file-representation yang dinamakan
vnode, yang terdiri dari designator numerik untuk berkas unik network-
wide.
• Sistem berkas lokal dan sistem berkas remote untuk jaringan.


Kesimpulan


Di dalam sebuah sistem operasi, salah satu hal yang paling pent-
ing adalah sistem berkas. Sistem berkas ini muncul karena ada tiga
masalah utama yang cukup signifikan: kebutuhan untuk menyimpan da-
ta dalam jumlah yang besar, kebutuhan agar data tidak mudah hilang
(non-volatile), dan informasi harus berdiri sendiri tidak bergantung pada
proses. Pada sistem berkas ini, diatur segala rupa macam yang berkaitan
dengan sebuah berkas mulai dari atribut, tipe, operasi, sampai metoda
akses berkas. Banyak sekali berkas-berkas yang disimpan dalam suatu
disk, karena itu diperlukan suatu struktur untuk pengorganisasian berkas
tersebut.
Setiap sistem file di Linux mempunyai kelebihan dan kekurangan.
Pada penjelasan bab tentang sistem file mengindikasikan makin berkem-
bangkannya sistem file maka ada suatu perbaikan seperti sistem file se-
belumnya seperti sistem file EXT3 lebih berkembang dibandingkan sis-
tem file EXT2. Reiser lebih unggul dari EXT3. Itu semua dilihat dari
perkembangna zaman teknologi waktu itu
Standar Hirarki Sistem Berkas (File Hierarchy Standard) adalah
rekomendasi penulisan direktori dan berkas-berkas yang diletakkan di
dalamnya. FHS ini digunakan oleh perangkat lunak dan user untuk
menentukan lokasi dari berkas dan direktori.
















Daftar pustaka


http://www.linuxlinks.com/article/2008/FileManagers.html
http://syntaxerror.web.id/komputer/perintah-dasar-linux.htm
http://alvinjunizar.blogspot.com/2011/01/konsep-mounting.html

Share this

0 Comment to "file manager"

Posting Komentar