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

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?

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.

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.

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.

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.

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.

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