Tester gesucht: FUSE für FreeBSD, Runde 2

Dieses Thema im Forum "FreeBSD - Allgemein" wurde erstellt von Yamagi, 19 September 2012.

  1. Yamagi

    Yamagi Possessed With Psi Powers Mitarbeiter

    Registriert seit:
    14 April 2004
    Beiträge:
    7.216
    Wohnort:
    Schleswig-Holstein
    Wie aufmerksame Leser dieses Forums sicher schon wissen, ist eines der Ziele für FreeBSD 10.0 die Unterstützung für nicht-SMP-fähige Dateisysteme aufzugeben. Dies soll hauptsächlich den Code des VFS, jener Komponente an welche die Dateisysteme andocken, vereinfachen und den Weg hin zu weiteren Optimierungen ebnen. Allerdings bedeutet dies auch, dass die Unterstützung für einige Dateisysteme wegfallen wird. Neben einigen älteren, heute weitgehend irrelevanten Dateisystemen wie HPFS, NWFS oder PortalFS zählen dazu auch das wichtige NTFS und SMBFS. In den letzten Wochen wurde daher recht emotional diskutiert, wie diese in Zukunft implementiert werden sollen. Die Ergebnisse waren grob:

    - NTFS ist in einer seiner derzeitigen Form einfach grundlegend kaputt und kann kaum gerettet werden. Zudem ist es extrem langsam und read-only. Ein Import von Apples NTFS-Implementierung wäre denkbar, würde aber keine größeren Vorteile bringen. ntfs-3g ist die beste Wahl, verlangt aber nutzbares und stabiles FUSE.

    - SMBFS ist ebenfalls völlig veraltet. Hier könnte man die vorhandene Unterstützung weiterentwickeln, oder Code von IllumOS oder Apple importieren. Aber beides verlangt deutliche Anpassungen und Zeit. Auch wenn es vielleicht irgendwann noch passieren wird, ist FUSE die bessere Wahl.

    Zudem eröffnet eine vollständige und saubere FUSE-Unterstützung den Zugriff auf den riesigen Pool von FUSE-Dateisystemen. In den letzten Wochen hat daher eine Gruppe Entwickler den halbfertigen und bereits einige Male verbesserten FUSE-Port aufgegriffen und optimiert. Mit diesem ist es möglich, FUSE-Dateisysteme sicher und stabil zu nutzen. Bevor dieser Port Anfang Oktober in das Basisystem einfließen wird, bitten die Entwickler noch um Tester. Gerade Tests anderer FUSE-Dateisysteme als ntfs-3g sind erbeten. Alles weitere findet sich wie immer in der E-Mail:

    Code:
    From: Attilio Rao <attilio@freebsd.org>
    To: FreeBSD FS <freebsd-fs@freebsd.org>, freebsd-current@freebsd.org,  Peter Holm <pho@freebsd.org>, Gustau Pérez <gperez@entel.upc.edu>,  George Neville-Neil <gnn@freebsd.org>, Florian Smeets <flo@freebsd.org>, bdrewery@freebsd.org
    Cc: 
    Reply-To: attilio@FreeBSD.org
    Subject: Re: MPSAFE VFS -- List of upcoming actions
    Date: Wed, 19 Sep 2012 03:48:03 +0100
    Sender: owner-freebsd-fs@freebsd.org
    
    On Fri, Jul 13, 2012 at 12:18 AM, Attilio Rao <attilio@freebsd.org> wrote:
    > 2012/7/4 Attilio Rao <attilio@freebsd.org>:
    >> 2012/6/29 Attilio Rao <attilio@freebsd.org>:
    >>> As already published several times, according to the following plan:
    >>> http://wiki.freebsd.org/NONMPSAFE_DEORBIT_VFS
    >>>
    >>
    >> I still haven't heard from Vivien or Edward, anyway as NTFS is
    >> basically only used RO these days (also the mount_ntfs code just
    >> permits RO mounting) I stripped all the uncomplete/bogus write support
    >> with the following patch:
    >> http://www.freebsd.org/~attilio/ntfs_remove_write.patch
    >>
    >> This is an attempt to make the code smaller and possibly just focus on
    >> the locking that really matter (as read-only filesystem).
    >> On some points of the patch I'm a bit less sure as we could easily
    >> take into account also write for things like vaccess() arguments, and
    >> make easier to re-add correct write support at some point in the
    >> future, but still force RO, even if the approach used in the patch is
    >> more correct IMHO.
    >> As an added bonus this patch cleans some dirty code in the mount
    >> operation and fixes a bug as vfs_mountedfrom() is called before real
    >> mounting is completed and can still fail.
    >
    > A quick update on this.
    > It looks like NTFS won't be completed for this GSoC thus I seriously
    > need to find an alternative to not loose the NTFS support entirely.
    >
    > I tried to look into the NTFS implementation right now and it is
    > really a poor support. As Peter has also verified, it can deadlock in
    > no-time, it compeltely violates VFS rules, etc. IMHO it deserves a
    > complete rewrite if we would still support in-kernel NTFS. I also
    > tried to look at the NetBSD implementation. Their code is someway
    > similar to our, but they used very complicated (and very dirty) code
    > to do the locking. Even if I don't know well enough NetBSD VFS, I have
    > the impression not all the races are correctly handled. Definitively,
    > not something I would like to port.
    >
    > Considering all that the only viable option would be meaning an
    > userland filesystem implementation. My preferred choice would be to
    > import PUFFS and librefuse on top of it but honestly it requires a lot
    > of time to be completed, time which I don't currently have as in 2
    > months Giant must be gone by the VFS.
    >
    > I then decided to switch to gnn's rewamp of FUSE patches. You can find
    > his initial e-mail here:
    > http://lists.freebsd.org/pipermail/freebsd-fs/2012-March/013876.html
    >
    > I've precisely got the second version of George's patch and created
    > this dolphin branch:
    > svn://svn.freebsd.org/base/projects/fuse
    >
    > I'm fixing low hanging fruit for the moment (see r238411 for example)
    > and I still have to make a throughful review.
    > However my idea is to commit the support once:
    > - ntfs-3g is well stress-tested and proves to be bug-free
    > - there is no major/big technical issue pending after the reviews
    
    In the last weeks Peter, Florian, Gustau and I have been working in
    stabilizing fuse support. In the specific, Peter has worked hard on
    producing several utilities to nit stress-test fuse and in particular
    ntfs, Florian has improved fuse related ports (as explained later) and
    Gustau has done sparse testing. I feel moderately satisfied by the
    level of stability of fuse now to propose to wider usage, in
    particular given the huge amount of complaints I'm hearing around
    about occasional fuse users.
    
    The final target of the project is to completely import into base the
    content of fusefs-kmod starting from earlier posted patches by George.
    So far, we took care only of importing in the fuse branch the kernel
    part, so that fusefs-kmod userland part is still needed to be
    installed from ports, but I was studying the mount_fusefs licensing
    before to process with the import for the userland bits of it.
    
    The fixing has been happening here:
    svn://svn.freebsd.org/base/projects/fuse/
    
    which is essentially an HEAD branch + fuse kernel components. In order
    to get fuse, please compile a kernel from this branch with FUSE option
    or simply build and load fuse module.
    Alternatively, a kernel patch that should work with HEAD@240684 is here:
    http://www.freebsd.org/~attilio/fuse_import/fuse_240684.patch
    
    I guess the patch can easilly apply to all FreeBSD branches, really,
    but it is not tested to anything else different then -CURRENT.
    
    As said you still need currently to build fusefs-kmod port. However
    you need these further patches, to be put in the fusefs-kmod/files/
    directory::
    http://www.freebsd.org/~attilio/fuse_import/patch-Makefile
    http://www.freebsd.org/~attilio/fuse_import/patch-mount_fusefs__mount_fusefs2.c
    
    They both disable the old kernel building/linking and import new
    functionality to let the new kernel support work well in presence of
    many consumers.
    
    In addition to fusefs-kmod, Bryan and Florian have also updated
    fusefs-lib and fusefs-ntfs ports. For instance, please refer to this
    e-mail:
    http://lists.freebsd.org/pipermail/freebsd-ports/2012-August/077950.html
    
    Even if this work is someway independent by the fusefs-kmod import, I
    warmly suggest to all of you to use their patches (and this what we
    have been testing so far too).
    
    At this point what I'm looking for are reviews and further testing.
    I would like to spend some words on what you should expect from this work:
    *Fuse is far from being perfect*.
    I cannot stress this enough. Peter stress-tests could break also Fuse
    on Linux generally and by Fuse authors admissions the modules can
    never guarantee to be completely starvation-free. However, they tend
    to be designed in a way that sleeps can be at least interrupted
    easily, making at least easy to recover from deadlocks. This is mostly
    retained also in FreeBSD, for what I can tell. Also, sometimes fuse
    seems to leave a small amount of hidden files, when it find references
    on files it wants to delete. This happens also under Linux and it is
    part of FUSE design, not much we can do.
    However, if deadlocks can be someway tollerated, things you should
    really pay attention are dumps of fuse modules (like ntfs-3g binary)
    and kernel panics. They must not happen and if they do they need to be
    fixed promptly.
    However, the good new is that ntfs seems doing exceptionally good.
    Florian could use ntfs as a backend for postgresql test. I think this
    is by far a big improvement if compared to current in-kernel ntfs
    which is completely torned.
    
    So far we have almost entirely tested only ntfs-3g. I know Gustau also
    used other modules like sshfs and George used GlusterFS with his older
    patches, but I encourage you to test as many modules as you want, as
    they may expose different bugs. Of course, I don't plan to spend much
    more time on FUSE, but I can occasionally look at bugs as they fall in
    the filesystems category and I'm always interested in keeping a good
    open eye on such issues.
    
    A few operational informations:
    - In the next days I will import the userland bits of fusefs-kmod to
    the fuse project branch making the port obsolete. When this happens I
    will make this clear to the user of this thread.
    - If no major bug is remained by the early October, I will commit this
    to -CURRENT
    - I expect Bryan and Florian to commit libfuse and ntfs updates soon.
    They can do independently from the fusefs-kmod retiral, but I would
    prefer their patches to go on first.
    - After that I will handover fusefs maintainership to gnn as agreed in
    precedence but I will be around helping with analysis and fixing,
    depending on time availability
    
    In the end I have really 2 minor questions:
    - One is about importing the mount_fusefs userland bits. I don't think
    we need a vendor import at all because they were developed by a
    FreeBSD GSoC student and kept in his git repo (or someone else's).
    Anyway, i'd just commit as new files once I do a good sweep. I hope
    nobody objects to that.
    - Another one is: fusefs-kmod right now is only amd64/i386 specific. I
    have no idea why as it has not any MD specific code. However I'm sure
    it has not been tested on other arches so far. Anyway I left it usable
    by all the arches. I think this is the correct choice. If someone
    objects with valid argument I can bring it back to be usable only on
    i386 and amd64.
    
    That's all, for any question please don't hesitate to contact me and
    the other people involved in this work.
    
    Thanks,
    Attilio
    
    
    -- 
    Peace can only be achieved by understanding - A. Einstein
    
  2. Kamikaze

    Kamikaze Bottom Poster Mitarbeiter

    Registriert seit:
    26 Mai 2005
    Beiträge:
    9.953
    Wohnort:
    /Earth/Europe/Germany/Karlsruhe
  3. kai_001

    kai_001 Member

    Registriert seit:
    10 Mai 2005
    Beiträge:
    380
    Wohnort:
    Berlin
    Sehr schön ... damit wird auch mooseFS wieder interessant ...

    Mal schaun wann wir Kapazitäten zum Testen haben, Danke für die Infos!

    Grüße,
    Kai
  4. foxit

    foxit Member

    Registriert seit:
    4 Juli 2012
    Beiträge:
    662
    Wohnort:
    /home
    Mir gefällt der Ansatz über FUSE überhaupt nicht. Ich würde daher lieber auf Ceph setzen welches auch unter FreeBSD funktionieren sollte. (Getestet habe ich das bis jetzt nur mit Debian) Zweitens haben die Jungs gerade 1 Million Dollar erhalten für die Weiterentwicklung. Bis Ende Jahr soll es hier die Version 1.0 geben.
  5. Yamagi

    Yamagi Possessed With Psi Powers Mitarbeiter

    Registriert seit:
    14 April 2004
    Beiträge:
    7.216
    Wohnort:
    Schleswig-Holstein
    So, inzwischen gab es ein kleines Update:
    - sysutils/fusefs ist zur aktuellen Version aktualisiert worden
    - sysutils/fusefs-ntfs ist aktualisiert worden
    - In der Porjekt-Branch und im aktuellen Patch ist fusefs-kmod nun vollständig enthalten. Der Port muss also nicht mehr installiert werden.

    Man muss also nur noch das Basisystem patchen, kann dann die Ports wie gewohnt installieren und es sollte funktionieren.

    Der Code soll am 4. Oktober in 10-CURRENT eingehen. Es wird diskutiert, gleich darauf sysutils/fusefs-kmod mit diesem Code zu aktualisieren, damit auch die Nutzer regulärer Release-Versionen sofort in seinen Genuss kommen.

    Quelle:
    Code:
    So, after Bryan and Florian ports update, I've also committed userland
    part of fusefs-kmod and now the project branch fully mirrors
    functionality of fusefs-kmod. The code in projects/fuse, infact, will
    also install mount_fusefs as part of the fuse support.
    
    You can use the branch directly or this patch against -CURRENT at 240752:
    http://www.freebsd.org/~attilio/fuse_import/fuse_240752.patch
    
    In order to test this work, then, you just need to patch (or use
    directly the branch) your sources with this patch and install ports
    normally as they work.
    
    If no major bugs are found before October 4th, this is the code that
    is going to be committed to HEAD.
    
    Thanks,
    Attilio
    
  6. ath0

    ath0 Member

    Registriert seit:
    4 Oktober 2009
    Beiträge:
    388
    Wohnort:
    ~
    Verstehe ich das Richtig? FUSE wird Teil des Basis systems? o_O
  7. Yamagi

    Yamagi Possessed With Psi Powers Mitarbeiter

    Registriert seit:
    14 April 2004
    Beiträge:
    7.216
    Wohnort:
    Schleswig-Holstein
    Ja, allerdings nur das Kernelmodul und das "mount_fusefs"-Kommando. FUSE in das Basissystem aufzunehmen, wurde schon öfter diskutiert. Es gib tatsächlich gute Gründe dafür, zum Beispiel das es nicht mehr ständig durch Änderungen der internen API unbeabsichtigt gebrochen wird und den kompletten Testprozess aller Dateisysteme durchläuft. Es wurde bisher nur immer abgelehnt, da FUSE nicht den Qualitätsanforderungen entsprach. Der nun eingehende Code basiert auf der Arbeit des GSoC 2011, in Kombination mit der darauf aufbauenden Arbeit von George Neville-Neil, die nun von Attilio Rao aufgeräumt und fertig gestellt wurde. Unterstützt wurde dieser Schritt durch die Tatsache, dass FreeBSDs Unterstützungen für NTFS und SMB auf der Abschussliste stehen.

    Natürlich ist FUSE keine 100% optimale Lösung. So schreibt Attilio Rao selbst, dass FUSE durch einige schlechte Design-Entscheidungen gar nicht komplett funktionieren kann, eine Neigung zu sich glücklicherweise selbstauflösenden Deadlocks und Starvation-Problemen hat. Allerdings ist FUSE dennoch ein sinnvoller Weg, da man damit endlich Unterstützung für diverse bisher fehlende und kaum nativ portierbare Dateisysteme bekommt. Es mag Alternativen geben, z.B. PUFFS mit Refuse oder Ceph, aber FUSE hat halt den unbestrittenen Vorteil, dass es mit wenig Aufwand integrierbar war und gut verstanden ist.
  8. ath0

    ath0 Member

    Registriert seit:
    4 Oktober 2009
    Beiträge:
    388
    Wohnort:
    ~
    Ich finde das gut, zumal ich es gerne für sshfs nutzen würde. Die Entscheidung wird dann wohl dazu beitragen das Fusefs wirklich nutzbar wird, und man hat es in der Basis cool wie ich finde. Wie könnte ich das neue Modul eigentlich unter 8.2 testen? Den Code habe ich, aber das ist ja Nunmal das Komplette system. Muss ich nur das Fuse Modul bauen und es dann Kopieren?
  9. Crest

    Crest rm -rf /*

    Registriert seit:
    25 Juni 2008
    Beiträge:
    1.268
    Wohnort:
    /dev/random
    ath0: 8.2 ist EOL.
  10. ath0

    ath0 Member

    Registriert seit:
    4 Oktober 2009
    Beiträge:
    388
    Wohnort:
    ~
    Ich weiß :( hätte es trotzdem gerne getestet.
  11. Crest

    Crest rm -rf /*

    Registriert seit:
    25 Juni 2008
    Beiträge:
    1.268
    Wohnort:
    /dev/random
    Willst du mir sagen all deine System sind EOL?
  12. Yamagi

    Yamagi Possessed With Psi Powers Mitarbeiter

    Registriert seit:
    14 April 2004
    Beiträge:
    7.216
    Wohnort:
    Schleswig-Holstein
    Da du mal probiert, den Patch auf 8.2 anzuwenden? Am besten mit "svn patch" direkt gegen die Arbeitskopie des FreeBSD-Quellcodes, denn dann hilft die Subversion beim Mergen. Die Chancen, dass es mit minimalen manuellen Eingriffen geht sind gut, denn fast alle Änderungen sind das Einfügen des FUSE-Source. Es könnte allerdings sein, dass der Compiler über Inkompatiblitäten zwischen 8.x und 10-CURRENT stolpert.
  13. ath0

    ath0 Member

    Registriert seit:
    4 Oktober 2009
    Beiträge:
    388
    Wohnort:
    ~
    @Crest Nein nicht alle Systeme sind alt, mein Server ist auf 9.0 der Rest ist derzeit auf 8.2, da ich gerade keine Zeit habe die Kisten mit einem Update zu versorgen. Das hat diverse gründe, z.b. das ich derzeit selten Zuhause bin, bzw. ich zu faul bin. :D

    @Yamagi Das hört sich ja fast nach einem Plan an :) Ich probiere das mal. Danke schön!
  14. Kamikaze

    Kamikaze Bottom Poster Mitarbeiter

    Registriert seit:
    26 Mai 2005
    Beiträge:
    9.953
    Wohnort:
    /Earth/Europe/Germany/Karlsruhe
    Juhu, seitdem fusefs-libs aktualisiert wurde funktioniert smbnetfs nicht mehr. :(
  15. Yamagi

    Yamagi Possessed With Psi Powers Mitarbeiter

    Registriert seit:
    14 April 2004
    Beiträge:
    7.216
    Wohnort:
    Schleswig-Holstein
    Wahrscheinlich müssen die Dateisystem-Module aktualisiert werden, um mit den neuen Libs zusammenspielen zu können. Stabile APIs sind ja für Luschen und so.
  16. Kamikaze

    Kamikaze Bottom Poster Mitarbeiter

    Registriert seit:
    26 Mai 2005
    Beiträge:
    9.953
    Wohnort:
    /Earth/Europe/Germany/Karlsruhe
    Letzte Nacht wurde der Maintainer für den Port ausgetragen. Und ich habe meinen backtrace natürlich zum Maintainer geschickt.

    Richtiger Thread? Richtiger Thread! :huth:
  17. Yamagi

    Yamagi Possessed With Psi Powers Mitarbeiter

    Registriert seit:
    14 April 2004
    Beiträge:
    7.216
    Wohnort:
    Schleswig-Holstein
    So, der Kram ist nun in 10-CURRENT und wird auch in FreeBSD 9.2 sein:
    Code:
    Author: attilio
    Date: Sat Oct 13 23:54:26 2012
    New Revision: 241519
    URL: http://svn.freebsd.org/changeset/base/241519
    
    Log:
      Import a FreeBSD port of the FUSE Linux module.
      This has been developed during 2 summer of code mandates and being revived
      by gnn recently.
      The functionality in this commit mirrors entirely content of fusefs-kmod
      port, which doesn't need to be installed anymore for -CURRENT setups.
      
      In order to get some sparse technical notes, please refer to:
      http://lists.freebsd.org/pipermail/freebsd-fs/2012-March/013876.html
      
      or to the project branch:
      svn://svn.freebsd.org/base/projects/fuse/
      
      which also contains granular history of changes happened during port
      refinements. This commit does not came from the branch reintegration
      itself because it seems svn is not behaving properly for this functionaly
      at the moment.
      
      Partly Sponsored by:		Google, Summer of Code program 2005, 2011
      Originally submitted by:	ilya, Csaba Henk <csaba-ml AT creo DOT hu >
      In collabouration with:		pho
      Tested by:			flo, gnn, Gustau Perez,
      				Kevin Oberman <rkoberman AT gmail DOT com>
      MFC after:			2 months
    
    Code:
    I've committed the FUSE support into base as r241519.
    
    Few things I would like to stress out at the present time:
    - The import of the fusefs in base, along with update of fusefs-ntfs
    and fusefs-libs ports (which happened by Florian and Brian), will
    bring us a fairly good ntfs (and possibly smbfs too, which is
    currently untested, as far as I know) support. In particular,
    in-kernel ntfs is so fragile that I don't understand how people cannot
    easily experience deadlocks, memory leaks and panics at the present
    time.
    - In -CURRENT, you don't need to install fusefs-kmod anymore. It would
    be good if a port committer (Florian, Brian?) will update the port in
    order to forbid install of fusefs-kmod in -CURRENT at the present
    time. I didn't bump the __FreeBSD_version because it is really
    unnecessary (port can just detect 10xxxx version and be ok with not
    installing the port) but once I will MFC it, I will bump the version
    in order to make the port not installable in STABLE branches
    - It would be good if someone could give a sweep to the style(9) of
    the fuse code. I tried to reduce the changes to the gnn's proposed
    patches at the minimum, thus I didn't fix style before to commit it,
    but there are several style violations that should be addressed. This
    could be a work for junior developers willing to take over.
    - There are still a couple of bugs, but they are infrequent and minor
    enough that they can be addressed after the committing of the
    infrastructure. gnn has agreed to take care of them in the long term
    and I will feed him as soon as possible with the details to reproduce
    and fix them. I will also help directly with fuse code when I will
    have available time.
    
    Next step for the VFS deorbit project now include the disconnect of
    non-MPSAFE filesystems, including NTFS and SMBFS that can be now used
    as FUSE modules instead.
    
    Thanks,
    Attilio