Bagaimana kita dibebani dengan sistem file (hierarkis) sebagai struktur data dasar?


19

Saya belajar sendiri dan saya tidak memiliki gelar CS. Semakin saya belajar tentang struktur data, semakin saya bertanya-tanya, di zaman sekarang ini, bagaimana kita masih dibebani dengan sistem file, dengan direktori dan file, sebagai struktur penyimpanan data dasar pada OS?

Saya mengerti kesederhanaannya, tetapi sekarang tampaknya ada lebih banyak pilihan yang tersedia secara asli. Sejauh yang saya ketahui, satu-satunya proyek untuk meningkatkan fungsionalitas dasar sistem file adalah ReiserFS, di mana Anda dapat mengetahui baris file yang diubah oleh siapa, dan kapan.

Sebagai contoh, jika saya dapat memiliki penandaan asli untuk file, di mana saya dapat menandai gambar, diagram, dokumen pengolah kata, seluruh repositori kode, semua milik proyek tunggal, itu akan sangat membantu saya. Karena saya terjebak dalam paradigma filesystem, saya tahu bahwa saya bisa memasukkan semua itu ke dalam satu folder / direktori, tetapi bagaimana jika mereka sudah ada di direktori yang berbeda, dan mereka harus tetap di sana? Saya tahu ada program di luar sana yang bisa melakukan ini, tetapi mengapa mereka tidak di sistem file?

Sesuatu yang menyenangkan untuk dimiliki adalah semacam fitur relasional dalam sistem berkas, seperti yang Anda dapatkan dengan RDBMSes. Saya mengerti bahwa itu seharusnya menjadi bagian dari Vista / 7, tetapi itu jatuh dari daftar fitur juga.

Tentu saja, program apa pun dapat menyimpan file biner dan memiliki struktur data yang diinginkan di dalamnya, mengapa OS tidak dapat menawarkan cara yang lebih kompleks untuk menyimpan data, di luar hirarki sederhana dari sistem file?


2
Inti dari itu harus sederhana. Mengasapi opsional yang Anda sebutkan harus pergi di atas inti sederhana. Atau, tunggu dua dekade dan seseorang akan menemukan kembali gagasan sistem file.
Pekerjaan

3
"Bagaimana jika mereka sudah ada di direktori yang berbeda, dan mereka perlu tinggal di sana?" Kadang-kadang Anda dapat menggunakan tautan keras untuk mengatasi masalah ini ...
FrustratedWithFormsDesigner

1
Juga, beberapa bacaan menarik tentang topik: c2.com/cgi/wiki?FileSystemAlternatives
FrustratedWithFormsDesigner

3
Tidak benar-benar solusi di Windows 7 tetapi Perpustakaan baru dapat memberi Anda beberapa fungsionalitas yang tampaknya Anda minati: lifehacker.com/#!5464350/…
DKnight

1
Jika saya ingin meletakkan file ke dua folder yang berbeda sekaligus, saya menaruh shortcut ke file itu dalam satu folder. Kerugiannya adalah jika Anda memindahkan folder / file itu, pintasannya tidak valid.
Mateen Ulhaq

Jawaban:


17

Mulailah dengan ini: http://en.wikipedia.org/wiki/Unix_File_System

Baca ini: http://www.unix.org/what_is_unix/history_timeline.html

Kemudian baca ini: http://www.amazon.com/UNIX-Filesystems-Evolution-Design-Implementation/dp/0471164836

Ada jawaban sederhana untuk "mengapa OS tidak bisa menawarkan cara yang lebih kompleks untuk menyimpan data, di luar hirarki sederhana dari sistem file?"

Karena terlalu banyak untuk dilakukan oleh OS.

Untuk itulah perpustakaan dan paket aplikasi diperuntukkan.

Oracle, misalnya, akan menjual seperangkat fitur mirip sistem file yang Anda kelola dengan toolset Oracle.

Python menggunakan perpustakaan DBM untuk membuat struktur penyimpanan pada disk yang sangat canggih.

CouchDB dan Mongo (dan lainnya) adalah struktur penyimpanan yang sangat canggih yang menawarkan beberapa fitur seperti basis data.

Intinya adalah bahwa OS harus melakukan yang minimum dan semuanya adalah tambahan.


4
Cukup setuju. Sebenarnya, banyak dari apa yang diminta OP ada dalam proyek WinFS yang mati atau sekarat: en.wikipedia.org/wiki/WinFS . Sama seperti geek di mengatakan, 'Rapi!' pengguna yang berpengalaman dan insinyur perangkat lunak dalam diriku berkata, "Berusaha terlalu keras!"
Adam Crossland

6
"Intinya adalah bahwa OS harus melakukan yang minimum dan semuanya adalah tambahan." Pernyataan yang cukup berani di zaman di mana beberapa sistem operasi berisi sistem windowing bawaan, layanan pengindeksan file, pemutar media, desktop jarak jauh, firewall atau Netris.
biziclop

1
@biziclop: Setuju. Windows telah menyimpang dari sudut pandang Linux. Tidak ada yang mengejutkan di sana.
S.Lott

1
@ S.Lott Jangan salah paham, saya setuju dengan pendekatan Anda, tetapi Windows dibebani dengan begitu banyak sampah yang tidak berguna, satu fitur tambahan tidak akan membuat perbedaan. :)
biziclop

4
Itulah filosofi Unix. Itu belum tentu benar. Itu (dan kompiler C) membuat Unix mudah untuk port ke perangkat keras. Ini juga membuatnya cukup sederhana bagi orang untuk mengkloning Unix ke dalam rasa -ix seperti yang kita temukan saat ini. Jika suatu fitur berguna, dan semua program membutuhkannya, seperti misalnya, mengeja bidang input yang diperiksa, maka ada nilai dalam memiliki lingkungan runtime menyediakannya. Kami tidak memerlukan 400 versi pita pita independen.
Tim Williscroft

8

Jawaban singkatnya adalah: Setiap hari orang memahami sistem file. Ini mengingatkan mereka pada file Cabinet. Pikirkan tentang halaman web dan bahkan aplikasi Fat, mengapa menurut Anda Tabssangat populer? Orang dapat mengidentifikasi diri dengan mereka, dan memahaminya dengan cepat.

Pencitraan mencoba mengajarkan Nenek untuk mencari DB untuk File berdasarkan tag properti .. Dengan sistem file, Nenek tahu file itu hanya di mana ia meletakkannya .

Bahkan dengan WinFS saya tidak berpikir MS akan menyingkirkan tampilan dan nuansa sistem file.


9
Saya harus tidak setuju dengan ini. Kebanyakan orang yang tidak dipaksa untuk menavigasi sistem file tidak melakukannya. Mereka membuka pengolah kata dan mengklik dokumen terbaru mereka, atau mencari di menu mulai Windows 7, dll. Dan banyak orang kehilangan jejak di mana mereka meletakkan file mereka. Akan jauh lebih mudah bagi Nenek untuk mencari "resep kue" atau "foto cucu" atau apa pun selain mempertahankan hierarki folder.
Matius Baca

16
Ini mungkin mengejutkan bagi Anda: orang biasa tidak memahami sistem file. Mereka tidak punya ide yang sedikit pun. Dan saya tidak bermaksud gaya Unix FS dengan titik mount, symlink dan hardlink, tetapi struktur direktori standar rawa dengan file di dalamnya.
biziclop

2
@Mon, nenek saya tidak pernah tahu di mana dia meletakkan barang-barang. Gmail telah mengubah paradigma yang saya inginkan ke sistem penandaan, terutama dengan filter untuk secara otomatis menandai sesuatu. Saya pikir paradigma filesystem diimplementasikan sebagian besar karena kesederhanaan struktur pohon pemrograman. Ini juga membuat pengalamatan lebih mudah dari perspektif pemrograman. Bagaimana Anda menentukan lokasi dokumen dalam sistem berbasis tag? Tidak mengatakan itu tidak bisa dilakukan, tetapi detailnya perlu disetrika.
zzzzBov

3
Apakah Anda membeli lemari arsip Anda penuh dengan ribuan folder dan dokumen yang diperlukan untuk pengoperasian kabinet itu sendiri, yang harus Anda navigasikan melalui dan di sekitarnya tetapi hati-hati untuk tidak menyentuh? Apakah lemari arsip Anda tampaknya terbuka ke lokasi yang berbeda setiap kali Anda mengeluarkan laci? Dll. Saya setuju dengan Matthew dan biziclop - "Everyday" orang tidak mengerti.
Nicole

2
Saya memiliki gelar CS. Tapi saya tidak tahu ke folder mana Windows meletakkan file apa. Terutama Desktop, StartMenu, QuickLaunch, dan semua folder default spesifik pengguna / sistem lainnya. (Sistem M $ -Bantuan itu tidak membantu menjelaskan kepada saya cara menekan tombol.) Saya perlu menginstal CygWin untuk dapat mencari file saya sendiri, karena fitur pencarian M $ yang lebih baru tidak lagi menemukan file sederhana yang sudah ada seperti pada win2k. Menonaktifkan kesalahan fungsi seperti sembunyikan-sistem-file, sembunyikan-file-ekstensi tidak lagi menyelesaikan sebagian besar masalah. Saya menyerah Windows, ketika saya dipaksa untuk bekerja pada WinXP (baru).
comonad

6

Ada sedikit kebenaran dalam setiap jawaban di sini, tapi saya rasa itu bukan kebenaran keseluruhan.

Apa yang Anda daftarkan sebagian besar fitur yang sangat dirindukan setiap hari oleh pengguna dan pengembang.

Orang-orang tidak memahami sistem file berbasis pohon lebih dari mereka akan mengerti yang berbasis DAG.

Dan sama sekali tidak ada alasan untuk pelengkap menyedihkan dari nama file yang disebut ekstensi. Mereka tidak hanya sepenuhnya tidak sesuai untuk tujuan mereka (mengidentifikasi jenis file) tetapi juga sumber gangguan bagi pengguna yang tak ada habisnya.

Alasan kami masih menggunakannya adalah campuran dari sikap "yang akan melakukan" dan kebutuhan nyata untuk menjaga kompatibilitas dengan kode yang lebih lama. Pendekatan baru untuk menyimpan file akan berarti perubahan radikal pada file dasar I / O API, membuat sebagian besar kode yang ada tidak berguna. Entah itu atau Anda harus berjinjit di sekitar mereka, mempertahankan API warisan. Ingat PROGRA ~ 1.

Saya pikir untuk alasan di atas, meskipun masa depan dapat memiliki sistem file yang lebih khusus untuk aplikasi khusus, tetapi sementara arsitektur PC desktop dan laptop saat ini bertahan, kita terjebak dengan sistem file berbasis pohon dengan kekurangan metadata dan ekstensi kecil yang mengerikan.


Sekarang saya akan beralih sisi.

Karena itu ada di sekitar kita, kita tidak pernah benar-benar menghargai betapa kuatnya metafora pohon itu. Di hard drive saya, saya punya beberapa ratus ribu file. Jika saya harus menemukan satu, jarang dibutuhkan lebih dari satu menit, bahkan jika saya tahu sedikit tentang file tersebut. Sekarang bayangkan tugas yang sama tanpa struktur apa pun, hanya daftar nama yang datar, bergulir tanpa henti.

Namun semua operasi itu langsung, tidak ada tindakan seram di kejauhan, tidak ada yang akan membuat saya pergi.

Sebenarnya, saya mengimplementasikan toko dokumen dengan metadata yang kaya dan hierarki berbasis DAG. (Itu bahkan bukan DAG bentuk bebas, itu benar-benar metastruktur dua tingkat dan dokumen, yang bisa menjadi anak-anak dari koleksi level 1 atau level 2. Jadi itu benar-benar sederhana.)

Jelas, persyaratan bahwa nama dokumen harus unik dalam koleksi harus tetap berlaku.

Dan kemudian masalah mulai mengalir. Bagaimana jika Anda membuka koleksi dan mengubah nama dokumen menjadi sesuatu yang berselisih dalam koleksi yang berbeda milik dokumen itu? Kami menampilkan pesan kesalahan tetapi pengguna benar-benar bingung. (Ini adalah pengguna yang sama yang meminta persyaratan ini.)

Mereka mencoba menghapus dokumen, tetapi yang dilakukan hanyalah menghapusnya dari koleksi. Jadi masih muncul di hasil pencarian. Kami mencobanya sebaliknya juga, tetapi kemudian mereka mengeluh bahwa mereka menghapus dokumen dari koleksi A dan secara ajaib menghilang dari koleksi B. Jadi kami membutuhkan "tautan" dan operasi penghapusan yang sulit.

Akhirnya kami mengakui kekalahan, untungnya masih tepat waktu.

Aspek pencarian tambahan yang dimungkinkan metadata bekerja dengan sangat baik.


Rememebr CP / M pada hard drive 5 MB? Ratusan dan ratusan file bergerak melewati. MENGERIKAN!
cepat

@quickly_now Ah, CP tua yang baik. :)
biziclop

3

Sejujurnya, saya hampir tidak menyentuh metadata pada file saya di Mac. Saya pikir dalam 5 tahun terakhir menggunakan OSX (yang mendukung komentar dan sebagainya), saya telah menggunakan metadata pada mungkin 2 file. Tidak mengatakan itu ide yang buruk.

Saya hanya tidak yakin bagaimana overhead dari penandaan pragmatis bagi saya.

Saya pikir fitur filesystem terbaik yang saya tahu akan menjadi sistem versi level filesystem ... yang bekerja lintas partisi. Itu dilakukan pada VAXen di tahun 70-an dan awal 80-an, tidak yakin mengapa itu tidak cocok dengan Unix dan NTFS / Windows.


Versi modern NTFS / Windows memang menawarkan versi. Ini tidak persis di wajah Anda, tetapi itu memang ada. Tidak bisa mengatakan perbandingannya dengan VMS.
Shog9

2

Saya telah bekerja dengan sistem file non-hierarkis pada mini yang lebih lama seperti HP3000 dan Encore / Gould. Anda tidak memiliki direktori; Anda memiliki grup dan akun, dan file diberi nama " grup . akun . file ", seperti "users.jbode.myfile1", "dev.jbode.main", dll.

Sekarang, ini adalah sistem lama , di mana kuota ruang disk individu berada dalam megabita tunggal, jadi Anda tidak perlu terlalu banyak level untuk mengatur barang-barang Anda, tetapi dari perspektif pengguna dan pemrogram, sistem hierarkis jauh lebih baik.


1

Saya tidak melihat di mana (setidaknya beberapa) sistem file saat ini benar-benar perlu melakukan banyak [Edit: apa pun, jujur] untuk mendukung tag. Ketika Anda mulai melakukannya, tag pendukung berarti sedikit lebih dari beberapa data tambahan yang terkait dengan file, tetapi tidak ditulis ke dalam aliran byte untuk file itu.

NTFS (untuk memilih satu contoh yang digunakan secara luas ) dapat melakukannya dengan baik: sejauh menyangkut NTFS, sebuah file tidak harus berupa satu aliran byte. Pada NTFS Anda dapat mengaitkan sejumlah aliran data yang sewenang-wenang dengan satu nama file. Setiap file memiliki (mungkin kosong) "aliran primer" yang tidak memiliki nama. Namun, ia juga dapat memiliki sejumlah aliran lain yang sewenang-wenang, yang masing-masing harus memiliki nama. Dengan menggunakan ini, akan sangat sepele untuk menambahkan aliran bernama (hanya misalnya) "tag" ke file yang ada, dan (cukup jelas) menulis tag Anda ke aliran itu.

Setelah itu muncul bagian yang agak lebih sulit: menggunakan alat untuk memanfaatkan tag yang Anda pasang di sana. Idealnya, Anda mungkin ingin mengindeksnya untuk pencarian cepat, sehingga Anda dapat melakukan hal-hal seperti membuat "direktori virtual" dari semua file dengan tag tertentu.

Setidaknya dari sudut pandang saya, sistem file sudah memiliki apa yang dibutuhkan - seharusnya menyimpan dan mengambil data, dan itu dapat melakukannya dengan sangat baik sekarang. Memanfaatkan data itu adalah pekerjaan alat lain. Alat-alat itu saat ini tidak ada, tetapi infrastruktur sistem file untuk mendukungnya tidak.

Jika saya dibiarkan bersikap sinis sesaat, saya akan mengatakan bahwa tidak dapat dihindari bahwa fitur NTFS ini akan tetap hampir sepenuhnya diabaikan dan tidak diketahui. Bagaimanapun, mudah digunakan dan tidak memerlukan API khusus atau apa pun. Anda dapat menggunakannya dengan cukup baik di C, C ++, atau yang sepenuhnya portabel, atau apa pun yang memungkinkan Anda menentukan nama file yang sewenang-wenang. Berikut ini sedikit kode untuk menunjukkan pembuatan file dengan AFS:

#include <fstream>

int main() {
    std::ofstream out("test.txt");
    std::ofstream tag("test.txt:tags");

    out << "This is the output file";
    tag << "tag1 tag2";

    return 0;
}

Dan, inilah beberapa kode untuk membaca dan menampilkan tag:

#include <fstream>
#include <iterator>
#include <iostream>
#include <string>

int main() { 
    std::ifstream tags("test.txt:tags");

    std::copy(std::istream_iterator<std::string>(tags),
          std::istream_iterator<std::string>(),
          std::ostream_iterator<std::string>(std::cout, " "));
    return 0;
}

Semua sangat sederhana dan mudah. Perhatikan bahwa meskipun saya hanya menulis sedikit data sepele di sana, Anda dapat memperlakukan AFS seperti file lainnya - semua "barang" yang biasa bekerja sama seperti yang lainnya. Dalam tampilan direktori normal, semua yang akan muncul adalah aliran primer (misalnya, ukuran yang ditunjukkan untuk file akan menjadi ukuran aliran primer), tetapi jika Anda ingin melihatnya, dir dapat menampilkan informasi tentang aliran alternatif juga dengan /Rbendera. Misalnya, daftar untuk file yang dibuat di atas terlihat seperti ini:

03/16/2011  08:22 PM                23 test.txt
                                     9 test.txt:tags:$DATA
               1 File(s)             23 bytes

1
DIR mungkin dapat menunjukkannya, tetapi cadangan file dengan aliran alternatif sangat sulit , terutama untuk beberapa sistem lain. Misalnya sebagian besar drive NAS saat ini menggunakan Linux, dan sistem file di sana tidak menangani stream alternatif sama sekali. Salin file di atas ... dan semua hal alt hilang begitu saja.
cepat_now

Ya, saya perhatikan bahwa sebagian besar sistem NAS agak ... tertantang (dan ini juga bukan satu-satunya cara). Untuk pencadangan dan pengembalian yang sebenarnya, tidak menimbulkan masalah (setidaknya jika perangkat lunak yang bersangkutan ditulis dengan kompeten): BackupReadakan membuat serial semua aliran, dan BackupWriteakan menyusun kembali file (dengan aliran alternatif) dari format serial.
Jerry Coffin

Tergantung jika Anda ingin file yang dicadangkan langsung dapat dibaca di NAS. Jika Anda melakukannya (dan menghindari perlunya program pemulihan khusus) maka Anda terjebak dengan file-file biasa.
cepat
Dengan menggunakan situs kami, Anda mengakui telah membaca dan memahami Kebijakan Cookie dan Kebijakan Privasi kami.
Licensed under cc by-sa 3.0 with attribution required.