Làm thế nào chúng ta có được hệ thống tập tin (phân cấp) như cấu trúc dữ liệu cơ bản?

Tôi tự học và tôi không có bằng CS. Càng tìm hiểu về cấu trúc dữ liệu, tôi càng tự hỏi, trong thời đại ngày nay, làm thế nào chúng ta vẫn yên tâm với hệ thống tệp, với các thư mục và tệp, như cấu trúc lưu trữ dữ liệu cơ bản trên HĐH?

Tôi hiểu sự đơn giản của nó, nhưng dường như ngày nay có thể có nhiều lựa chọn hơn về mặt nguyên bản. Theo như tôi biết, dự án duy nhất để cải thiện chức năng cơ bản của hệ thống tệp là ReiserFS, nơi bạn có thể cho biết dòng nào của tệp đã được thay đổi bởi ai và khi nào.

Ví dụ, nếu tôi có thể gắn thẻ riêng cho các tệp, nơi tôi có thể gắn thẻ hình ảnh, sơ đồ, tài liệu xử lý văn bản, toàn bộ kho lưu trữ mã, tất cả đều thuộc về một dự án, điều đó thực sự hữu ích với tôi. Vì tôi bị mắc kẹt trong mô hình hệ thống tập tin, tôi biết rằng tôi có thể đặt tất cả những thứ đó vào một thư mục / thư mục duy nhất, nhưng nếu chúng đã tồn tại trong các thư mục khác nhau, và chúng cần ở lại thì sao? Tôi biết có những chương trình ngoài kia có thể làm điều này, nhưng tại sao chúng không có trên hệ thống tập tin?

Một cái gì đó sẽ rất hay khi có một loại tính năng quan hệ trong hệ thống tệp, giống như bạn có với RDBMSes. Tôi hiểu rằng đó được cho là một phần của Vista / 7, nhưng nó cũng nằm trong danh sách tính năng.

Chắc chắn, bất kỳ chương trình nào cũng có thể lưu trữ tệp nhị phân và có bất kỳ cấu trúc dữ liệu nào mà nó muốn trong đó, tại sao HĐH không thể cung cấp các cách lưu trữ dữ liệu phức tạp hơn, ngoài hệ thống thừa kế đơn giản của hệ thống tệp?

Bắt đầu với điều này: http://en.wikipedia.org/wiki/Unix_File_System

Đọc này: http://www.unix.org/what_is_unix/history_timeline.html

Sau đó đọc nó: http://www.amazon.com/UNIX-Filesystems-Evolution-Design-Imcellenceation/dp/0471164836

Có một câu trả lời đơn giản cho "tại sao HĐH không thể cung cấp các cách lưu trữ dữ liệu phức tạp hơn, ngoài khả năng thừa kế đơn giản của hệ thống tệp?"

Bởi vì nó quá nhiều cho hệ điều hành.

Đó là những gì thư viện và gói ứng dụng dành cho.

Ví dụ, Oracle sẽ bán cho bạn một bộ tính năng giống như hệ thống tệp mà bạn quản lý bằng bộ công cụ Oracle.

Python sử dụng thư viện DBM để tạo các cấu trúc lưu trữ trên đĩa rất tinh vi.

CouchDB và Mongo (và những người khác) là các cấu trúc lưu trữ rất tinh vi cung cấp một số tính năng giống như cơ sở dữ liệu.

Vấn đề là hệ điều hành nên làm tối thiểu và mọi thứ đều là một tiện ích bổ sung.

Câu trả lời ngắn gọn là: Hàng ngày mọi người hiểu hệ thống tập tin. Nó nhắc nhở họ về một tủ hồ sơ. Hãy nghĩ về các trang web và thậm chí các ứng dụng Fat, tại sao bạn nghĩ Tabslà rất phổ biến? Mọi người có thể xác định với họ, và hiểu họ một cách nhanh chóng.

Hình ảnh cố gắng dạy Bà tìm kiếm DB cho Tệp dựa trên thẻ thuộc tính .. Với hệ thống tệp, Bà biết tệp chỉ đơn giản là nơi bà đặt nó .

Ngay cả với WinFS tôi cũng không nghĩ MS sẽ thoát khỏi giao diện hệ thống tệp.

Có một sự thật nhỏ trong mỗi câu trả lời ở đây nhưng tôi không nghĩ đó là toàn bộ sự thật.

Những gì bạn liệt kê hầu hết là các tính năng bị bỏ lỡ hàng ngày bởi người dùng và nhà phát triển.

Mọi người không hiểu hệ thống tệp dựa trên cây nhiều hơn họ sẽ hiểu hệ thống tệp dựa trên DAG.

Và hoàn toàn không có lý do gì cho các phần phụ thảm hại của tên tệp được gọi là phần mở rộng. Chúng không chỉ hoàn toàn không phù hợp với mục đích của chúng (xác định loại tệp) mà còn là nguồn gây phiền toái vô tận cho người dùng.

Lý do chúng tôi vẫn đang sử dụng chúng là sự pha trộn giữa thái độ "sẽ làm" và nhu cầu thực sự để duy trì khả năng tương thích với mã cũ hơn. Một cách tiếp cận mới để lưu trữ tệp có nghĩa là thay đổi căn bản trong API I / O của tệp cơ bản, khiến hầu hết các mã hiện có trở nên vô dụng. Hoặc là hoặc bạn phải nhón chân xung quanh họ, duy trì API kế thừa. Hãy nhớ PROGRA ~ 1.

Tôi nghĩ vì những lý do trên, mặc dù tương lai có thể chứa nhiều hệ thống tệp chuyên biệt hơn cho các ứng dụng đặc biệt, nhưng trong khi kiến ​​trúc máy tính để bàn và máy tính xách tay hiện tại vẫn tồn tại, chúng tôi bị mắc kẹt với hệ thống tệp chủ yếu dựa trên cây với sự thiếu siêu dữ liệu và phần mở rộng nhỏ khủng khiếp của nó.

Bây giờ tôi sẽ đổi bên.

Bởi vì nó ở xung quanh chúng ta, chúng ta không bao giờ thực sự đánh giá cao sự ẩn dụ của cây mạnh mẽ đến mức nào. Trên ổ cứng của tôi, tôi có vài trăm nghìn tệp. Nếu tôi phải tìm một cái, nó hiếm khi mất hơn một phút, ngay cả khi tôi biết rất ít về tệp. Bây giờ hãy tưởng tượng cùng một nhiệm vụ mà không có bất kỳ cấu trúc nào, chỉ là một danh sách phẳng các tên, cuộn vô tận.

Tuy nhiên, tất cả các hoạt động đều đơn giản, không có hành động ma quái ở khoảng cách xa, không có gì có thể khiến tôi đi wtf.

Trên thực tế, tôi đã thực hiện một kho lưu trữ tài liệu với siêu dữ liệu phong phú và hệ thống phân cấp dựa trên DAG một lần. (Nó thậm chí không phải là DAG dạng tự do, nó hoàn toàn là cơ sở hạ tầng hai cấp và các tài liệu, có thể là con của bộ sưu tập cấp 1 hoặc cấp 2. Vì vậy, nó thực sự đơn giản.)

Rõ ràng, yêu cầu tên tài liệu phải là duy nhất trong một bộ sưu tập phải ở lại.

Và sau đó các vấn đề bắt đầu chảy. Điều gì sẽ xảy ra nếu bạn mở một bộ sưu tập và thay đổi tên của tài liệu thành thứ gì đó đụng độ trong một bộ sưu tập khác mà tài liệu cũng thuộc về? Chúng tôi đã hiển thị một thông báo lỗi nhưng người dùng đã hoàn toàn gặp khó khăn. (Đây là những người dùng rất giống nhau đã yêu cầu yêu cầu này.)

Họ đã cố xóa một tài liệu, nhưng tất cả những gì đã làm là xóa nó khỏi bộ sưu tập. Vì vậy, nó vẫn hiển thị trong kết quả tìm kiếm. Chúng tôi cũng đã thử cách khác, nhưng sau đó họ phàn nàn rằng họ đã xóa một tài liệu khỏi bộ sưu tập A và nó biến mất một cách kỳ diệu khỏi bộ sưu tập B. Vì vậy, chúng tôi cần cả "hủy liên kết" và thao tác xóa cứng.

Cuối cùng, chúng tôi thừa nhận thất bại, may mắn là vẫn còn kịp.

Các khía cạnh tìm kiếm bổ sung mà siêu dữ liệu có thể thực hiện được một điều trị tuyệt đối.

Thành thật mà nói, tôi hầu như không chạm vào siêu dữ liệu trên các tệp của mình trên máy Mac. Tôi nghĩ rằng trong 5 năm qua sử dụng OSX (hỗ trợ bình luận và vv), tôi đã sử dụng siêu dữ liệu trên có thể 2 tệp. Không nói đó là một ý tưởng tồi.

Tôi chỉ không chắc làm thế nào chi phí cho việc gắn thẻ là thực dụng đối với tôi.

Tôi nghĩ rằng tính năng hệ thống tập tin đẹp nhất mà tôi biết sẽ là một hệ thống phiên bản cấp hệ thống tập tin ... hoạt động phân vùng chéo. Nó đã được thực hiện trên VAXen vào những năm 70 và đầu thập niên 80, không hiểu tại sao nó không bắt kịp với Unix và NTFS / Windows.

Tôi đã làm việc với các hệ thống tệp không phân cấp trên các minis cũ như HP3000 và Encore / Gould. Bạn đã không có thư mục; bạn đã có một nhóm và một tài khoản, và các tập tin được đặt tên là " nhóm . tài khoản . tập tin ", như "users.jbode.myfile1", "dev.jbode.main", vv

Bây giờ, đây là những hệ thống cũ , trong đó hạn ngạch không gian đĩa riêng lẻ chỉ trong một megabyte, do đó, không giống như bạn cần quá nhiều cấp độ để sắp xếp công cụ của mình, nhưng từ hệ thống phân cấp phối cảnh của người dùng và lập trình viên sẽ đẹp hơn nhiều .

Tôi không thấy nơi (ít nhất là một số) hệ thống tệp hiện tại thực sự cần phải làm nhiều [Chỉnh sửa: bất cứ điều gì, thành thật] để hỗ trợ các thẻ. Khi bạn truy cập vào nó, các thẻ hỗ trợ có nghĩa ít hơn một số dữ liệu bổ sung được liên kết với một tệp, nhưng không được ghi vào luồng byte cho tệp đó.

NTFS (để chọn một ví dụ được sử dụng rộng rãi ) có thể làm tốt điều đó: theo như NTFS quan tâm, một tệp không nhất thiết phải là một luồng byte. Trên NTFS, bạn có thể liên kết một số luồng dữ liệu tùy ý với một tên tệp. Mỗi tệp có một "luồng chính" (có thể trống) không có tên. Tuy nhiên, nó cũng có thể có một số lượng các luồng khác tùy ý, mỗi luồng phải có một tên. Sử dụng điều này, sẽ thật sự tầm thường khi thêm một luồng có tên (ví dụ) "thẻ" vào một tệp hiện có và (rõ ràng là đủ) viết các thẻ của bạn vào luồng đó.

Sau đó, phần khó khăn hơn: sử dụng các công cụ của bạn để sử dụng các thẻ bạn đặt ở đó. Lý tưởng nhất là bạn có thể muốn lập chỉ mục cho chúng để tìm kiếm nhanh, vì vậy bạn có thể thực hiện những việc như tạo một "thư mục ảo" của tất cả các tệp bằng một thẻ cụ thể.

Ít nhất theo quan điểm của tôi, hệ thống tập tin đã có sẵn những gì cần thiết - nó có nghĩa là lưu trữ và truy xuất dữ liệu và nó có thể làm điều đó hoàn toàn tốt ngay bây giờ. Sử dụng dữ liệu đó là công việc của các công cụ khác. Những công cụ đó hiện không tồn tại, nhưng cơ sở hạ tầng hệ thống tệp để hỗ trợ chúng.

Nếu tôi được phép hoài nghi một lúc, tôi sẽ nói rằng không thể tránh khỏi tính năng này của NTFS sẽ gần như hoàn toàn bị bỏ qua và không biết. Rốt cuộc, nó đơn giản để sử dụng và không yêu cầu bất kỳ API đặc biệt hay bất cứ thứ gì khác. Bạn có thể sử dụng nó khá độc đáo trong C, C ++ hoàn toàn di động hoặc bất cứ thứ gì khác sẽ cho phép bạn chỉ định một tên tệp tùy ý. Đây là một đoạn mã nhanh để chứng minh việc tạo một tệp có 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;
}

Và, đây là một số mã để đọc và hiển thị các thẻ:

#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;
}

Tất cả đều rất đơn giản và dễ dàng. Lưu ý rằng mặc dù tôi chỉ viết một chút dữ liệu tầm thường ở đó, bạn có thể coi AFS giống như bất kỳ tệp nào khác - tất cả các "công cụ" thông thường đều hoạt động giống như mọi thứ khác. Trong màn hình thư mục bình thường, tất cả những gì sẽ hiển thị là luồng chính (ví dụ: kích thước hiển thị cho tệp sẽ là kích thước của luồng chính), nhưng nếu bạn muốn xem nó, dir cũng có thể hiển thị thông tin về các luồng thay thế với /Rcờ. Ví dụ: một danh sách cho tệp được tạo ở trên trông như thế này:

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