Login
Newsletter
Werbung

Thema: DBFS - ein weiteres Datenbankdateisystem

21 Kommentar(e) || Alle anzeigen ||  RSS
Kommentare von Lesern spiegeln nicht unbedingt die Meinung der Redaktion wider.
0
Von Name am Di, 7. September 2004 um 18:42 #
Hallo,

ich dachte ReiserFS bietet in der Version 4 auch erweiterten Suchmöglichkeiten mit seinem plugin System.
Habe ich da was falsch verstanden oder sind das grundverschiedene Entwicklungsziele?

[
| Versenden | Drucken ]
  • 0
    Von fs111 am Di, 7. September 2004 um 19:20 #
    Bei Reiser4 musst Du aber selbiges auch einsetzen, obiges System ist ein Aufsatz und sollte auch mit ext3, xfs, jfs etc. funktionieren. Das ist der Hauptunterschied, und IMHO ein entscheidender, da es Dir kein Dateisystem aufzwängt.

    fs111

    [
    | Versenden | Drucken ]
    • 0
      Von Tim am Di, 7. September 2004 um 19:56 #
      cool mit welchem plugin kann man denn da suchen? kann man auch nach meta daten bzw attributen suchen? und auch mit hocher geschwindigkeit?
      [
      | Versenden | Drucken ]
      0
      Von Tim am Di, 7. September 2004 um 20:24 #
      wenn das mit reiser4 funktionieren würde wär es aber ein vorteil das alle daten automatisch in der datenbank sind. Es könnte ja sein das man von einem anderen os dateien auf die linux partition schreibt diese wären dann nicht in der DB eingetragen. Änliches beim löschen. Aus diesem grund find ich eine umsetung wie beim BeFS besser.
      Ist eigendlcih irgendjemand daran interessiert das BeFs nach linux zu portieren? Es gibt eine opensoure version von openbeos...
      Aber wenn mann das gleiche wie beim BeFS auch mit reiser4 machen kann wär ich natürlich für reiser4
      [
      | Versenden | Drucken ]
      • 0
        Von slashme am Fr, 10. September 2004 um 00:23 #
        sorry, aber mir draengt sich der vergleich mit einem damenkraenzchen auf.
        von welchem befs sprichst/schreibst du? du weisst, dass es bereits einige datenbank- (und aehnliche) ansaetze gibt um gleichartige funktionalitaet in bereits verbreitete dateisysteme zu integrieren?
        deine letzte aussage "Aber wenn mann ..." moechte ich lieber nicht kommentieren.
        [
        | Versenden | Drucken ]
      0
      Von bla am Mi, 8. September 2004 um 16:31 #
      Es sollte vielleicht dazu gesagt werden, dass das darunterliegende Dateisystem bei dbfs mehr oder weniger egal ist, da du ja im in dem das dbfs als ein paar Binärdateien siehst.
      Das ganze wird dadurch natürlich verlangsamt...
      [
      | Versenden | Drucken ]
0
Von lonkus am Di, 7. September 2004 um 19:23 #
Siehe dazu auch:
http://nat.org/beagle/
http://www.gnome.org/projects/beagle/

Scheint mir aktiver zu sein als "Storage"

[
| Versenden | Drucken ]
  • 0
    Von Ronny Buchmann am Di, 7. September 2004 um 21:32 #
    Beagle hat aber eine andere Zielsetzung als Storage oder DBFS.

    Siehe ausführliche Informationen in Seths Blog:
    http://www.gnome.org/~seth/

    [
    | Versenden | Drucken ]
    • 0
      Von moo am Di, 7. September 2004 um 22:11 #
      Ich sehe dort nichts, was man nicht auch mit Beagle machen *könnte*.
      Die Ziele mögen durchaus verschiedene sein, aber praktisch gesehen
      bringen sowohl Beagle wie auch Storage ähnliche Funktionalität zum
      Benutzer: Metadaten, Filter, "Live Queries", Änderungsbenachrichtigung,
      ...
      [
      | Versenden | Drucken ]
mehr DMS
0
Von vicbrother am Di, 7. September 2004 um 19:37 #
Was mir für einen breiteren Firmeneinsatz von KDE/GNOME fehlt ist ein Documen Managment System. Das wäre echt klasse. Ob DBFS das ersetzen kann bezweifle ich, ich werde das aber mal in meiner eigenen KDE-Übersetzung mal testen...
[
| Versenden | Drucken ]
  • 0
    Von Nguyen am Di, 7. September 2004 um 21:53 #
    Meinst du ein DMS für das Filesystem?

    AFAIK bietet das keiner an (als Apple/Spotlight).

    [
    | Versenden | Drucken ]
    0
    Von TBO am Di, 7. September 2004 um 22:41 #
    Für KDE 4.0 sind erweiterte Suchfunktionalitäten geplant. Scott Wheeler hat bei Akademy einen Vortrag über "alternative" Organisation von Daten gehalten.

    Siehe auch:

    http://conference2004.kde.org/cfp-devconf/
    scott.wheeler-search.metadata.interface.elements.php
    (zusammensetzen)

    http://ktown.kde.org/akademy/

    [
    | Versenden | Drucken ]
    0
    Von matze am Mi, 8. September 2004 um 10:02 #
    Hier haben wir Owl am laufen: das besteht prinzpiell aus einer Ordnerhierarchie auf einem beliebigen *nix-Dateisystem, einer MySql-DB im Hintergrund, die Meta-Informationen zu einzelnen Dokumenten beherbergt sowie einem PHP-Frontend zum lokalen oder LAN/WAN-Zugriff. Reicht für unsere Zwecke völlig aus (kleines Projekt-Büro), dürfte sich aber auch im größeren Rahmen skalieren lassen...
    [
    | Versenden | Drucken ]
0
Von ihminen am Di, 7. September 2004 um 22:06 #
Wie sieht denn das mit der Leistung aus? So wie ich das verstehe, ist es eine zusätzliche Schicht, durch die sämtliche FS-Zugriffe durch müssen. Deswegen verwenden Datenbanksysteme ja auch gerne die rohe Festplatte und organisieren die Daten selbst, um nicht den Umweg über das FS gehen zu müssen (das andere Prioritäten hat). Oder verstehe ich da was falsch?

Hyvää yötä,
ihminen

[
| Versenden | Drucken ]
  • 0
    Von Lars. am Mi, 8. September 2004 um 11:29 #
    ... Leistung?
    Keine Ahnung, ist hier aber auch egal, da es erst ein Ansatz ist so etwas zu realisieren.

    ... DB auf RAW Platte?
    Nein, das siehst Du richtig.

    IMHO ist es im ersten Schritt aber egal, wie die Performance ist, Hauptsache die Daten werden gefunden. Bei mir (300GB) dauert es mitlerweile sehr lange bis ich gewisse Dateien wiedergefunden habe zumal nicht alles an seinem eigentlichen Platz mehr landet, habe 4 Festplatten, und noch mehr Partionen, jede für sich hat ein Media Verzeichnis, das Bilder, MP3, etc. enthält des weiteren ein UNSORTED Verz., bis ich ein Bild gefunden habe *Stöhn*, das dauert. Von UNSORTED ganz zu schweigen.
    Das sind halt gesammelte Daten, die sich so langsam selbst deorganisieren, zum Aufräumen komme ich schon lange nicht mehr :-(
    Reicht der Platz nicht mehr aus, wird halt eine neue Platte hineingesteckt.
    Evtl. bringt ein Link Generator etwas Platz, der doppelte Dateien findet und die doppelten durch Softlinks ersetzt.

    Aber der Ansatz von DBFS gefällt mir (einfach die FileSelectorBox zu ersetzen), hoffentlich gibt es bald einen ebuild für Gentoo ;-)

    Lars

    [
    | Versenden | Drucken ]
0
Von Markus M. am Mi, 8. September 2004 um 12:04 #
Weiss jemand, ob es bereits in einem der Dateisysteme (PlugIns etc.) eine Unterstützung für IPTC Metadaten gibt? Diese Metadaten in JPEGs und TIFFs sind allgemein bekannt als Photoshop Dateiinformationen.

Weitere fotobezogene Metadaten wären EXIF, XMP und ICC Profile.

Eine fehlende Lese-/Schreib-Unterstützung für die IPTC Metadaten auf normalen Desktopsystemen verhindert derzeit den Einsatz von Linux Desktops bei Fotografen, Fotoagenturen, Verlagen und bei allen Leuten, die mit beschrifteten digitalen Fotos ihr Geld verdienen.

[
| Versenden | Drucken ]
0
Von Lord am Mi, 8. September 2004 um 13:08 #
Also ich such evtl alle paar Wochen mal eine Datei per locate, das wars dann schon.
Ansonsten organisiere ich meine Daten ordentlich, für was gibts denn Ordner etc.
Wenn man natürlich alles in einen Ordner reinschmeißt wirds schwer was wieder zu finden egal ob mit oder ohne DBFS.
[
| Versenden | Drucken ]
0
Von netsrac am Mi, 8. September 2004 um 14:26 #
Und wieder stellen sich mir zwei Fragen:

1. Es gibt eine quelloffene Implementierung eines solchen File-Systems für OpenBeOS/Haiku. Warum wird nicht diese verwendet ?

2. Wieso wird da wieder mit einem RDBMS rumgefrickelt, das irgendwo im Hintergrund laufen soll und bei jeglichen Änderungen auf dem File-System miteinbezogen werden muß ? Wenn ich da an mögliche Inkosistenzen denke, weil der Update in der Datenbank nicht geklappt hat oder aber erst gar nicht veranlaßt wurde, wird mir ganz anders. Und wie soll das denn konkret aussehen, will man wirklich aus dem Kernel raus (File-System-Operationen sind ja nun mal durch den Kernel gesteuert) ein Userland-Programm (RDBMS) aufrufen ? Oder soll das RDBMS etwa im Kernel-Space laufen ? Klingt für mich alles nach böser Frickelei.

Ich meine, ein File-System mit den genannten Möglichkeiten ist wirklich nix neues. HPFS von OS/2 unterstützt erweiterte Dateiattribute seit OS/2-Version 1.3, also seit mittlerweile über 15 Jahren. BeFS von BeOS kann es ebenso und dort läßt es sich auch prima zur Suche nutzen. Man könnte sich also durchaus da abgucken, wie's gehen kann. Stattdessen macht man meiner Ansicht nach eine ganz schöne Bastelbude auf.

Naja, mal sehen, in 5 Jahren gibt's dann vielleicht doch erweiterte Attribute unter Linux, die man auch wirklich mit überschaubaren Risiken nutzen kann. ;-)

Tschö,
Carsten

[
| Versenden | Drucken ]
  • 0
    Von Clemens am Mi, 8. September 2004 um 18:34 #
    ja wer hatt interesse das haiku befs zu portieren?
    ich hätt bock
    czeidler at gmx . de
    [
    | Versenden | Drucken ]
    0
    Von fuffy am Do, 9. September 2004 um 10:55 #
    Erweiterte Attribute gibt es doch schon für ext2, ext3 und XFS.
    Nur fehlt dann halt der Index für die schnelle Suche (vgl. find und slocate).
    [
    | Versenden | Drucken ]
0
Von Marc am Fr, 17. Dezember 2004 um 13:26 #
*lach*
[
| Versenden | Drucken ]
Pro-Linux
Pro-Linux @Facebook
Neue Nachrichten
Werbung