เราได้รับอานม้าด้วยระบบแฟ้ม (ลำดับชั้น) เป็นโครงสร้างข้อมูลพื้นฐานได้อย่างไร

ฉันเรียนด้วยตัวเองและฉันไม่มีวุฒิปริญญาตรี ยิ่งฉันได้เรียนรู้เกี่ยวกับโครงสร้างข้อมูลมากเท่าไหร่ฉันก็ยิ่งสงสัยว่าในยุคนี้เราจะยังคงผูกมัดกับระบบไฟล์ด้วยไดเรคทอรีและไฟล์เป็นโครงสร้างการจัดเก็บข้อมูลพื้นฐานบนระบบปฏิบัติการได้อย่างไร

ฉันเข้าใจความเรียบง่ายของมัน แต่ดูเหมือนทุกวันนี้อาจมีตัวเลือกเพิ่มเติมให้ใช้ เท่าที่ฉันทราบโครงการเดียวที่จะปรับปรุงการทำงานพื้นฐานของระบบไฟล์คือ ReiserFS ซึ่งคุณสามารถบอกได้ว่าบรรทัดใดของไฟล์ที่ถูกเปลี่ยนแปลงโดยใครและเมื่อใด

ตัวอย่างเช่นถ้าฉันสามารถมีการติดแท็กเนทีฟสำหรับไฟล์ซึ่งฉันสามารถแท็กรูปภาพไดอะแกรมเอกสารประมวลผลคำพื้นที่เก็บข้อมูลรหัสทั้งหมดทั้งหมดเป็นของโครงการเดียวซึ่งจะเป็นประโยชน์กับฉันจริงๆ เนื่องจากฉันติดอยู่ในกระบวนทัศน์ของระบบแฟ้มฉันรู้ว่าฉันสามารถใส่สิ่งเหล่านั้นลงในโฟลเดอร์ / ไดเรกทอรีเดียว แต่ถ้าพวกมันมีอยู่แล้วในไดเรกทอรีที่แตกต่างกันและพวกเขาจำเป็นต้องอยู่ที่นั่น? ฉันรู้ว่ามีโปรแกรมออกมีที่สามารถทำได้ แต่ทำไมพวกเขาไม่ได้อยู่ในระบบไฟล์?

สิ่งที่น่ายินดีที่มีก็คือคุณลักษณะเชิงสัมพันธ์บางอย่างในระบบไฟล์เช่นคุณได้รับจาก RDBMS ฉันเข้าใจว่าควรจะเป็นส่วนหนึ่งของ Vista / 7 แต่นั่นก็ลดลงจากรายการคุณสมบัติเช่นกัน

แน่นอนว่าโปรแกรมใด ๆ สามารถจัดเก็บไฟล์ไบนารีและมีโครงสร้างข้อมูลใด ๆ ที่มันต้องการเพราะเหตุใดระบบปฏิบัติการจึงไม่สามารถเสนอวิธีการที่ซับซ้อนกว่าในการจัดเก็บข้อมูลนอกเหนือจากการสืบทอดแบบง่าย ๆ ของระบบไฟล์?

เริ่มจากสิ่งนี้: http://en.wikipedia.org/wiki/Unix_File_System

อ่านสิ่งนี้: http://www.unix.org/what_is_unix/history_timeline.html

จากนั้นอ่านสิ่งนี้: http://www.amazon.com/UNIX-Filesystems-Evolution-Design-Implementation/dp/0471164836

มีคำตอบง่ายๆว่า "ทำไมระบบปฏิบัติการจึงไม่สามารถเสนอวิธีการจัดเก็บข้อมูลที่ซับซ้อนได้มากกว่าวิธีการสืบทอดแบบง่าย ๆ ของระบบไฟล์"

เพราะมันมากเกินไปสำหรับระบบปฏิบัติการที่จะทำ

นั่นคือสิ่งที่ไลบรารี่และแอพพลิเคชั่นใช้สำหรับ

ตัวอย่างเช่น Oracle จะขายชุดคุณสมบัติคล้ายกับระบบไฟล์ที่คุณจัดการด้วยชุดเครื่องมือ Oracle

Python ใช้ไลบรารี DBM เพื่อสร้างโครงสร้างหน่วยเก็บข้อมูลบนดิสก์ที่ซับซ้อน

CouchDB และ Mongo (และอื่น ๆ ) เป็นโครงสร้างสตอเรจที่ซับซ้อนมากซึ่งมีคุณสมบัติคล้ายฐานข้อมูล

ประเด็นก็คือระบบปฏิบัติการควรทำขั้นต่ำและทุกอย่างเป็นส่วนเสริม

คำตอบสั้น ๆ คือ: ทุก ๆ คนเข้าใจระบบไฟล์ มันเตือนพวกเขาจากตู้เก็บเอกสาร ลองคิดถึงหน้าเว็บและแม้กระทั่งแอพ Fat ทำไมคุณถึงคิดว่าTabsได้รับความนิยม? ผู้คนสามารถระบุกับพวกเขาและเข้าใจพวกเขาได้อย่างรวดเร็ว

การถ่ายภาพพยายามที่จะสอนคุณยายในการค้นหา DB สำหรับไฟล์ขึ้นอยู่กับแท็กสถานที่ให้บริการ .. ด้วยระบบไฟล์ ยายรู้ว่าไฟล์เป็นเพียงที่เธอวางไว้

แม้ว่า WinFS ฉันไม่คิดว่า MS จะกำจัดรูปลักษณ์และความรู้สึกของระบบไฟล์

มีความจริงเล็กน้อยในทุกคำตอบที่นี่ แต่ฉันไม่คิดว่ามันเป็นความจริงทั้งหมด

สิ่งที่คุณแสดงส่วนใหญ่เป็นคุณสมบัติที่ผู้ใช้และนักพัฒนาพลาดทุกวัน

ผู้คนไม่เข้าใจระบบไฟล์แบบทรีมากกว่าที่พวกเขาจะเข้าใจระบบฐานแบบ DAG

และไม่มีข้อแก้ตัวใด ๆ สำหรับส่วนที่น่าสมเพชของชื่อไฟล์ที่เรียกว่าส่วนขยาย พวกเขาไม่เพียง แต่ไม่เหมาะสมอย่างสมบูรณ์สำหรับวัตถุประสงค์ของพวกเขา (ระบุประเภทของไฟล์) แต่ยังเป็นแหล่งที่ไม่มีที่สิ้นสุดของความรำคาญสำหรับผู้ใช้

เหตุผลที่เรายังคงใช้มันคือการผสมผสานระหว่างทัศนคติ "ที่จะทำ" และความต้องการที่แท้จริงในการรักษาความเข้ากันได้กับรหัสเก่า วิธีการใหม่ในการจัดเก็บไฟล์จะหมายถึงการเปลี่ยนแปลงที่รุนแรงในไฟล์พื้นฐาน I / O API แสดงผลรหัสที่มีอยู่ส่วนใหญ่ไร้ประโยชน์ ไม่ว่าคุณจะต้องเขยิบไปรอบ ๆ พวกเขาหรือไม่ก็คงไว้ซึ่ง API เดิม จำ PROGRA ~ 1

ฉันคิดว่าด้วยเหตุผลข้างต้นแม้ว่าในอนาคตจะมีระบบไฟล์พิเศษสำหรับแอพพลิเคชั่นพิเศษ แต่ในขณะที่สถาปัตยกรรมเดสก์ท็อปพีซีและแล็ปท็อปพีซีในปัจจุบันยังมีชีวิตอยู่เราติดอยู่กับระบบไฟล์แบบต้นไม้ มันเป็นส่วนขยายเล็ก ๆ ที่น่ากลัว

ตอนนี้ฉันจะสลับข้าง

เพราะมันอยู่รอบตัวเราเราไม่เคยซาบซึ้งจริง ๆ ว่าอุปมาของต้นไม้นั้นมีพลังอย่างเหลือเชื่อ บนฮาร์ดไดรฟ์ของฉันฉันมีไฟล์หลายแสนไฟล์ ถ้าฉันต้องหามันใช้เวลานานกว่าหนึ่งนาทีถึงแม้ว่าฉันจะรู้น้อยมากเกี่ยวกับไฟล์ ตอนนี้จินตนาการถึงภารกิจเดียวกันโดยไม่มีโครงสร้างใด ๆ เพียงแค่รายชื่อแบน ๆ เลื่อนไปเรื่อย ๆ

การดำเนินการทั้งหมดนั้นตรงไปตรงมาไม่มีการกระทำที่น่ากลัวในระยะไกลไม่มีอะไรที่จะทำให้ฉันไปได้

ที่จริงแล้วฉันใช้ที่เก็บเอกสารที่มีข้อมูลเมตามากมายและลำดับชั้นที่ใช้ DAG หนึ่งครั้ง (มันไม่ได้เป็น DAG แบบฟรีฟอร์มมันเป็น metastructure สองชั้นและเอกสารอย่างเคร่งครัดซึ่งอาจเป็นลูกของคอลเล็กชั่นระดับ 1 หรือระดับ 2 ดังนั้นมันจึงง่ายจริงๆ)

เห็นได้ชัดว่าความต้องการที่ชื่อเอกสารจะต้องไม่ซ้ำกันในคอลเลกชันต้องอยู่

แล้วปัญหาก็เริ่มไหล ถ้าคุณเปิดคอลเล็กชันและเปลี่ยนชื่อของเอกสารเป็นสิ่งที่ขัดแย้งกันในคอลเล็กชันอื่นเอกสารนั้นจะเป็นของใคร เราแสดงข้อความแสดงข้อผิดพลาด แต่ผู้ใช้งงงวยอย่างสมบูรณ์ (ผู้ใช้เหล่านี้เป็นผู้ใช้เดียวกันกับที่ถามข้อกำหนดนี้)

พวกเขาพยายามที่จะลบเอกสาร แต่ทั้งหมดที่ทำคือลบออกจากคอลเลกชัน ดังนั้นจึงยังปรากฏในผลการค้นหา เราลองใช้วิธีอื่นเช่นกัน แต่จากนั้นพวกเขาก็บ่นว่าพวกเขาลบเอกสารออกจากคอลเล็กชัน A และมันหายไปอย่างน่าอัศจรรย์จากคอลเล็กชัน B ดังนั้นเราจึงต้องการทั้ง "unlink" และการดำเนินการลบอย่างหนัก

ในที่สุดเรายอมรับความพ่ายแพ้โชคดีที่ยังอยู่ในเวลา

การค้นหาเพิ่มเติมทำให้ข้อมูลเมตาเป็นไปได้ว่าเป็นวิธีการรักษาที่แน่นอน

ตามจริงแล้วฉันแทบจะไม่ได้สัมผัสข้อมูลเมตาของไฟล์บน Mac ฉันคิดว่าใน 5 ปีที่ผ่านมาของการใช้ OSX (ซึ่งรองรับความคิดเห็นและอื่น ๆ ) ฉันใช้เมทาดาทาบนไฟล์ 2 ไฟล์ ไม่พูดว่าเป็นความคิดที่ไม่ดี

ฉันไม่แน่ใจว่าค่าใช้จ่ายในการติดแท็กนั้นเป็นประโยชน์สำหรับฉันอย่างไร

ฉันคิดว่าคุณสมบัติของระบบไฟล์ที่ดีที่สุดที่ฉันรู้ว่าเป็นระบบเวอร์ชันของระบบไฟล์ ... ซึ่งทำงานข้ามพาร์ติชัน มันทำใน VAXen ในยุค 70 และต้น 80 ไม่แน่ใจว่าทำไมมันถึงไม่เข้ากับ Unix และ NTFS / Windows

ฉันทำงานกับระบบไฟล์ที่ไม่ใช่แบบลำดับชั้นสำหรับ minis รุ่นเก่าเช่น HP3000 และ Encore / Gould คุณไม่มีไดเรกทอรี คุณมีกลุ่มและบัญชีและไฟล์ถูกตั้งชื่อเป็น " group . account . file " เช่น "users.jbode.myfile1", "dev.jbode.main" ฯลฯ

ตอนนี้เหล่านี้มีความเก่าระบบที่ดิสก์แต่ละโควต้าพื้นที่อยู่ในเมกะไบต์เดียวจึงไม่เหมือนที่คุณจำเป็นระดับมากเกินไปในการจัดระเบียบข้อมูลของคุณ แต่จากมุมมองของผู้ใช้และโปรแกรมเมอร์ระบบลำดับชั้นมีมากดีกว่า

ฉันไม่เห็นว่าระบบไฟล์ปัจจุบัน (อย่างน้อยบางส่วน) จำเป็นต้องทำอะไรมาก [แก้ไข: ทุกสิ่งเพื่อความซื่อสัตย์] เพื่อสนับสนุนแท็ก เมื่อคุณลงไปถึงแท็กสนับสนุนหมายถึงข้อมูลเพิ่มเติมที่เกี่ยวข้องกับไฟล์เพียงเล็กน้อยแต่ไม่ได้เขียนลงในสตรีมไบต์สำหรับไฟล์นั้น

NTFS (เพื่อเลือกหนึ่งตัวอย่างที่ใช้กันอย่างแพร่หลาย ) สามารถทำได้เช่นกัน: ตราบใดที่ NTFS ใส่ใจไฟล์ไม่จำเป็นต้องเป็นสตรีมไบต์เดียว บน NTFS คุณสามารถเชื่อมโยงสตรีมข้อมูลจำนวนเท่าใดก็ได้กับชื่อไฟล์เดียว แต่ละไฟล์มี "สตรีมหลัก" (อาจว่าง) ที่ไม่มีชื่อ อย่างไรก็ตามยังสามารถมีจำนวนสตรีมอื่นโดยพลการซึ่งแต่ละรายการจะต้องมีชื่อ การใช้สิ่งนี้จะเป็นการง่ายมากที่จะเพิ่มสตรีมที่ชื่อ (ตัวอย่างเช่น) "แท็ก" ลงในไฟล์ที่มีอยู่และ (ชัดเจนพอ) เขียนแท็กของคุณในสตรีมนั้น

หลังจากนั้นมาเป็นส่วนที่ค่อนข้างยากขึ้น: นำเครื่องมือของคุณมาใช้ประโยชน์จากแท็กที่คุณใส่ไว้ ตามหลักแล้วคุณอาจต้องการจัดทำดัชนีเพื่อการค้นหาที่รวดเร็วดังนั้นคุณสามารถทำสิ่งต่างๆเช่นสร้าง "ไดเรกทอรีเสมือน" ของไฟล์ทั้งหมดด้วยแท็กเฉพาะ

อย่างน้อยจากมุมมองของฉันระบบไฟล์มีสิ่งที่จำเป็นอยู่แล้ว - มันควรจะจัดเก็บและดึงข้อมูลและมันสามารถทำได้อย่างสมบูรณ์แบบในขณะนี้ การใช้ข้อมูลนั้นเป็นงานของเครื่องมืออื่น ๆ เครื่องมือเหล่านั้นไม่มีอยู่ในขณะนี้ แต่โครงสร้างพื้นฐานของระบบไฟล์เพื่อสนับสนุน

ถ้าฉันได้รับอนุญาตให้เหยียดหยามสักครู่ฉันก็บอกว่ามันคงหนีไม่พ้นว่าฟีเจอร์ของ NTFS นี้จะยังคงถูกเพิกเฉยและไม่รู้ ท้ายที่สุดมันใช้งานง่ายและไม่ต้องการ API พิเศษหรืออย่างอื่น คุณสามารถใช้มันค่อนข้างดีในพกพาอย่างสมบูรณ์ C, 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;
}

และนี่คือโค้ดสำหรับอ่านและแสดงแท็ก:

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

ทั้งหมดง่ายและสะดวก โปรดทราบว่าแม้ว่าฉันจะเขียนข้อมูลเพียงเล็กน้อยเท่านั้น แต่คุณสามารถใช้งาน AFS ได้เช่นเดียวกับไฟล์อื่น ๆ - "สิ่งของ" ตามปกติทั้งหมดใช้งานได้เหมือนอย่างอื่น ในการแสดงผลไดเรกทอรีปกติสิ่งที่จะแสดงคือสตรีมหลัก (เช่นขนาดที่แสดงสำหรับไฟล์จะเป็นขนาดของสตรีมหลัก) แต่ถ้าคุณต้องการดูมันdir สามารถแสดงข้อมูลเกี่ยวกับสตรีมสำรองได้เช่นกัน ด้วย/Rธง ตัวอย่างเช่นรายชื่อสำหรับไฟล์ที่สร้างขึ้นด้านบนมีลักษณะดังนี้:

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