기본 데이터 구조로서 (계층 적) 파일 시스템과 어떻게 안장을 이루었습니까?

나는 독학이고 CS 학위가 없습니다. 데이터 구조에 대해 더 많이 배우면서 요즘 시대에 OS의 기본 데이터 스토리지 구조로 파일 시스템, 디렉토리 및 파일을 어떻게 안장하고 있습니까?

나는 그것의 단순성을 이해하지만 요즘에는 기본적으로 더 많은 옵션이있을 수 있습니다. 내가 아는 한, 파일 시스템의 기본 기능을 향상시키는 유일한 프로젝트는 ReiserFS뿐입니다. 여기서 파일의 줄을 누가, 언제 변경했는지 알 수 있습니다.

예를 들어, 이미지, 다이어그램, 워드 프로세싱 문서, 전체 코드 리포지토리를 모두 단일 프로젝트에 속하는 태그를 지정할 수있는 파일에 대한 고유 태그를 지정할 수 있다면 실제로 도움이 될 것입니다. 파일 시스템 패러다임에 갇혀 있기 때문에 모든 폴더를 단일 폴더 / 디렉토리에 넣을 수는 있지만 이미 다른 디렉토리에 있으면 어떻게해야합니까? 나는 이것을 할 수있는 프로그램이 있다는 것을 알고 있지만 왜 파일 시스템에 있지 않습니까?

RDBMS와 마찬가지로 파일 시스템의 일종의 관계형 기능이 있으면 좋을 것입니다. Vista / 7의 일부인 것으로 생각되었지만 기능 목록에서도 떨어졌습니다.

물론 어떤 프로그램이든 바이너리 파일을 저장할 수 있고 원하는 데이터 구조를 가질 수 있습니다. 왜 OS가 파일 시스템의 단순한 계층 구조를 넘어서 더 복잡한 데이터 저장 방법을 제공 할 수 없었습니까?

이것으로 시작하십시오 : 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

"OS가 파일 시스템의 단순한 계층 구조를 넘어서 더 복잡한 데이터 저장 방법을 제공 할 수 없었던 이유"에 대한 간단한 대답이 있습니다.

OS가 할 일이 너무 많기 때문입니다.

이것이 바로 라이브러리와 응용 프로그램 패키지입니다.

예를 들어, Oracle은 Oracle 툴셋으로 관리하는 파일 시스템과 유사한 기능 세트를 판매합니다.

파이썬은 DBM 라이브러리를 사용하여 매우 정교한 온 디스크 스토리지 구조를 만듭니다.

CouchDB 및 Mongo (및 기타)는 데이터베이스와 유사한 기능을 제공하는 매우 정교한 스토리지 구조입니다.

요점은 OS가 최소한으로해야하며 모든 것이 애드온이라는 것입니다.

짧은 대답은 : 매일 사람들은 파일 시스템을 이해합니다. 파일 캐비닛을 상기시킵니다. 웹 페이지와 팻 앱에 대해 생각해보십시오. 왜 Tabs그렇게 인기가 있다고 생각 하십니까? 사람들은 그들과 함께 식별하고 빨리 이해할 수 있습니다.

Grandma에게 속성 태그를 기반으로 File에 대한 DB를 검색하도록 가르치려고하는 영상. 파일 시스템을 통해 Grandma는 파일이 어디에 있는지 알고 있습니다 .

WinFS를 사용하더라도 MS가 파일 시스템의 모양과 느낌을 없애지 않을 것이라고 생각합니다.

여기에 모든 대답에 약간의 진실이 있지만 그것이 전부 진실이라고 생각하지 않습니다.

당신이 나열하는 것은 대부분 사용자와 개발자 모두가 매일 그리워하는 기능입니다.

사람들은 DAG 기반 파일 시스템을 이해하는 것보다 트리 기반 파일 시스템을 더 이상 이해하지 못합니다.

그리고 확장명이라는 파일 이름의 애매한 추가에 대한 변명은 전혀 없습니다. 그것들은 파일 형식을 식별하는 목적에 완전히 부적합 할뿐만 아니라 사용자에게 끝없는 성가신 소스입니다.

우리가 여전히 그것들을 사용하는 이유는 "할 것이다"태도와 이전 코드와의 호환성을 유지하기위한 실질적인 필요성이 혼합되어 있기 때문입니다. 파일 저장에 대한 새로운 접근 방식은 기본 파일 I / O API의 급격한 변화를 의미하며 대부분의 기존 코드를 쓸모 없게 만듭니다. 그 중 하나이거나 레거시 API를 유지하면서 발끝을 내야합니다. PROGRA ~ 1을 기억하십시오.

미래에는 특수 응용 프로그램을 위해 더 전문화 된 파일 시스템을 보유 할 수 있지만 현재의 데스크톱 및 랩톱 PC 아키텍처는 살아남지 만 메타 데이터와 그 끔찍한 작은 확장.

이제 측면을 바꾸겠습니다.

그것이 우리 주변에 있기 때문에, 우리는 나무의 은유가 얼마나 놀랍게도 강력하다는 것을 결코 감사하지 않습니다. 내 하드 드라이브에는 수십만 개의 파일이 있습니다. 하나를 찾아야 할 경우 파일에 대해 거의 알지 못하더라도 1 분 이상 걸리지 않습니다. 이제 구조가없고 동일한 이름의 목록 만 있고 끝없이 스크롤되는 동일한 작업을 상상해보십시오.

그러나 모든 작전은 간단하고, 먼 거리에서 짜증나는 행동은 없습니다.

실제로, 풍부한 메타 데이터와 DAG 기반 계층 구조로 문서 저장소를 한 번 구현했습니다. (자유형 DAG조차 아니었고, 엄격하게 2 단계 메타 구조이며 문서는 레벨 1 또는 레벨 2 컬렉션의 하위 항목이 될 수 있습니다. 따라서 매우 간단합니다.)

분명히, 문서 이름이 컬렉션 내에서 고유해야한다는 요구 사항이 유지되어야했습니다.

그리고 문제가 시작되었습니다. 컬렉션을 열고 문서의 이름을 문서가 속한 다른 컬렉션과 충돌하는 이름으로 변경하면 어떻게 되나요? 오류 메시지가 표시되었지만 사용자가 완전히 당황했습니다. (이 요구 사항을 요청한 동일한 사용자입니다.)

그들은 문서를 삭제하려고 시도했지만, 그 모든 것은 컬렉션에서 문서를 제거하기 만했습니다. 따라서 여전히 검색 결과에 나타납니다. 우리는 다른 방법으로 시도했지만 컬렉션 A에서 문서를 삭제하고 컬렉션 B에서 마술처럼 사라 졌다고 불평했습니다. 따라서 "링크 해제"와 강제 삭제 작업이 모두 필요했습니다.

결국 우리는 운 좋게도 여전히 제 시간에 패배를 인정했습니다.

메타 데이터가 가능해지면서 추가 검색이 가능해졌지만 절대적인 대우를 받았습니다.

솔직히 말하면, 나는 Mac에서 파일의 메타 데이터를 거의 만지지 않습니다. 지난 5 년 동안 OSX (댓글 등을 지원하는)를 사용했을 때 아마도 2 개의 파일에서 메타 데이터를 사용했다고 생각합니다. 나쁜 생각은 아닙니다.

태그 지정 오버 헤드가 어떻게 실용적인지 잘 모르겠습니다.

내가 아는 가장 좋은 파일 시스템 기능은 파일 시스템 수준 버전 관리 시스템 일 것입니다 ... 그것은 70 년대와 80 년대 초 VAXen에서 이루어졌으며, 왜 Unix와 NTFS / Windows를 따라 잡지 않았는지 확실하지 않습니다.

HP3000 및 Encore / Gould와 같은 구형 미니에서 비 계층 파일 시스템으로 작업했습니다. 디렉토리가 없었습니다. 당신은 그룹 및 계정을 가지고 및 파일은 다음과 같이 "라는 한 그룹 . 계정 . 파일 "users.jbode.myfile1 ","dev.jbode.main "등처럼"

이제 이들은 개별 디스크 공간 할당량이 단일 메가 바이트 로 된 오래된 시스템이므로 물건을 구성하는 데 너무 많은 수준이 필요하지는 않지만 사용자와 프로그래머의 관점에서 보면 계층 적 시스템이 훨씬 좋습니다.

현재 파일 시스템이 (적어도 일부) 실제로 태그를 지원하기 위해 많은 부분을 편집해야하는 것을 보지 못했습니다. 당신은 관련된 몇 가지 여분의 데이터보다 조금 더 많은 태그 수단을 지원하고, 그것을 내려 할 때 와 파일 만 바이트의 스트림으로 기록되지 않습니다 에 대한 해당 파일.

NTFS ( 광범위하게 사용 되는 하나의 예를 선택 하기 위해)는 그렇게 할 수 있습니다. NTFS가 관심을 갖는 한 파일은 반드시 단일 바이트 스트림 일 필요는 없습니다. NTFS에서는 임의의 수의 데이터 스트림을 단일 파일 이름과 연결할 수 있습니다. 각 파일에는 이름이없는 (기본 비어 있음) "기본 스트림"이 있습니다. 그러나 또한 임의의 수의 다른 스트림을 가질 수 있으며 각 스트림에는 이름이 있어야합니다. 이것을 사용 하면 기존 파일에 "tags"라는 이름의 스트림을 추가하고 태그를 해당 스트림에 작성하는 것이 정말 간단 합니다.

그 후에는 다소 어려운 부분이 생깁니다. 도구를 사용하여 태그를 활용하는 것입니다. 이상적으로는 빠른 검색을 위해 색인을 생성하고 싶을 수 있으므로 특정 태그가있는 모든 파일의 "가상 디렉토리"를 만드는 것과 같은 작업을 수행 할 수 있습니다.

적어도 내 관점에서 볼 때 파일 시스템에는 이미 필요한 것이 있습니다. 데이터를 저장하고 검색해야하며 지금 당장 완벽하게 수행 할 수 있습니다. 해당 데이터를 활용하는 것은 다른 도구의 역할입니다. 이러한 도구는 현재 존재하지 않지만이를 지원하는 파일 시스템 인프라는 존재합니다.

내가 냉소적으로 허용된다면, 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를 다른 파일과 같이 취급 할 수 있습니다. 모든 일반적인 "소재"는 다른 것과 마찬가지로 작동합니다. 일반 디렉토리 표시에서 모든 것은 1 차 스트림 (예 : 파일에 표시된 크기는 1 차 스트림의 크기 임)이지만,보고 싶다면 대체 스트림에 대한 정보도 표시 dir 할 수 있습니다. 와 /R플래그. 예를 들어, 위에서 만든 파일 목록은 다음과 같습니다.

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