Vermutlich kann man via FreeSwan usw. Verschlüsseln ... Klatr eine Verschöüsselung ist möglich aber die Geschwindigkeit leidet extrem. Ein kleiner Test mit eine ältere Testversion zeigte gravierende Einbüße, die Gescwindigkeit sank um de faktor 3 bis 5. Getestet war eine Verbindung über ssh. Falls die vom Kernel angebotene Fähigkeiten verwendet werden, bei NAS für den Heimbereich selten vorhanden sollte es besser gehen aber immer noch mit Nachteile bezüglich Geschwindigkeit. Mit einer Testversion erreiche ich Zur Zeit bei der Übertragung von große Dateien bis zur 25 MB / sekunde. Dies ist sehr stark von der im NAS Gerät verbaute Hardware abhängig, bei den Hauptauthor sind die Ergebnisse wesentlich schlechter.
Ein weiteren Vorteil von Remotefs ist dass das Exportieren einer Verzeichniss über das Internet kein Problem darstellt (bis auf der fehlenden Verschlüsselung) und sogar IPv6 unterstüzt wird.
Von M wie Meikel am Mo, 20. Oktober 2008 um 09:50 #
> NFS ist langsam.
Wohl mehr dein persönliches Problem als eins von NFS. ;-)
Außerdem ist ein Dateisystem, von dem auf den Projektseiten gesagt wird:
> The reasons i've decided to make it are a) samba isn't working for me at all > b) NFS is not working well for me c) sshfs is great, but not very fast. > In comparison with sshfs, performance on my hardware has improved roughly > four times (with read/write cache enabled).
Viermal mal schneller mit Cache als sshfs über fuse, das klingt wirklich nach einem Burner. ;-)
> SAMBA kaum zu konfigurieren zusammen mit MS Produkten .....
Warum Leute ein Protokoll aus der Windows-Welt für die Kommunikation zwischen Unix/Linux-Büchsen nutzen wollen, habe ich noch nie verstanden.
> Endlich was einfaches was einfach tut.
Ein weiteres sinnloses Projekt, das halbfertig auf Sourceforge vergammeln wird.
Ein weiteres sinnloses Projekt, das halbfertig auf Sourceforge vergammeln wird. Dies war auch meine Meinung. Ich musste diese aber revidieren. Warum Leute ein Protokoll aus der Windows-Welt für die Kommunikation zwischen Unix/Linux-Büchsen nutzen wollen, habe ich noch nie verstanden. Ich gebe dir Recht, cifs ist nicht das richtige, die Einrichtung, wie von den Herstellern vorgeshen, ist nicht immer optimal und auch wenn cifs/Samba es versuchen sich nahtlos in der UNIX Welt einzubinden, bleibt es eine Krankheit. Alle NAS bieten nicht NFS und den Anwender bleibt ertsmal nur das Krebsgeschwür übrig.
Im übrigens sind weder NFS noch SAMBA/CIFS so langsam. NFS profitiert stark von den internen Caching so dass der Anwender den Eindruck bekommt dass nfs sehr schnell ist.
Versuche mal ein ls -l auf einer Verzeichniss mit 8000 Einträge vorzunehmen (nfs gerade eingebunden), Bis zur Listing im Terminal vergehen etliche Sekunden, auf mein Hardware über 20 Sekunden, mit remotefs lediglich 0,3 Sekunden.
Beim Streamen von Daten (Video) hilft beim NFS das Cachen auch nicht mehr.
NFS (Server) unter Solaris ist wesentlich geschmeidiger als unter Linux, und wenn man dann NFS von NetApp nimmt fängt es an richtig Spass zu machen. Aber das ist dann auch eher nicht so die Zielgruppe von remotefs ...
Von M wie Meikel am Mo, 20. Oktober 2008 um 12:13 #
> > Ein weiteres sinnloses Projekt, das halbfertig auf Sourceforge vergammeln wird. > Dies war auch meine Meinung. Ich musste diese aber revidieren.
Das wird die Zeit zeigen.
> Im übrigens sind weder NFS noch SAMBA/CIFS so langsam.
Natürlich nicht. Das wäre ja auch irgendwie erstaunlich, wenn all die Firmen, die sich da engagieren, es in rund 20 Jahren nicht geschafft hätten, das einigermassen performant zu kriegen. ;-)
> NFS profitiert stark von den internen Caching so dass der Anwender den Eindruck bekommt dass nfs sehr schnell ist.
Naja, der lokale Speicher ist ein paar Größenordnungen schneller als das Netzwerk, insofern wirst du wohl kein Netzwerk-Dateisystem finden, das nicht umfangreich Daten cached.
> Versuche mal ein ls -l auf einer Verzeichniss mit 8000 Einträge vorzunehmen (nfs gerade eingebunden), Bis zur Listing im Terminal vergehen etliche Sekunden, auf mein Hardware über 20 Sekunden, mit remotefs lediglich 0,3 Sekunden.
Kann ich nicht nachvollziehen. Ich habe es gerade mal getestet, hier sind das 3 Sekunden (mit Ausgabe nach /dev/null nur noch 1,4s), mit Cache 1,5s (0,7s). Ach ja, zwei angestaubte Athlon64 S939, Ubuntu 8.04. Und ich bin mir noch nicht mal sicher, ob die an einem Gigabit-Switch hängen.
Kann ich nicht nachvollziehen. Ich habe es gerade mal getestet, hier sind das 3 Sekunden (mit Ausgabe nach /dev/null nur noch 1,4s), mit Cache 1,5s (0,7s). Ach ja, zwei angestaubte Athlon64 S939, Ubuntu 8.04. Und ich bin mir noch nicht mal sicher, ob die an einem Gigabit-Switch hängen.
Damit ein Netzwerk-Dateisystem performant ist gehören viele Massnahmen. Bei den erwähntes Beispiel sieht es so aus dass ich auf den Server eine Verzeichniss mit 8000 Dateien angelegt habe. Die Operationen die ich getan habe sind: # mount server:/exportierteVerieichniss /mnt $ time ls -l /mnt/verzeichniss >/dev/null Die Wartezeit betrug bis zur Erscheinen der Zeitangabe mehr als 20 Secunden. Natürlich bringt ein weiteren ls auf dies Verzeichniss eine sehr geringe Antwortzeit. Beim erstenmal ist aber immer langsam. Es ist zudem zu bedenken dass der Server auf ein langsamen Gerät läuft (CPU mit 200 MHz bei mir) und dass dass die CPU troz GB Etherbetschnittstelle es schaft gerade auf maximal 300Mbps zu übertragen (Kein Protokoll, Telegramme immer mit maximaler Länge, Kein Rücksicht auf Verlust,...) Bei der Hardware des Hauptautors sieht es viel schlechter aus. Trozdem erreicht er gerade bei sehr große Dateien wie z.B. Video Streams wesentlich bessere Werte als mit nfs möglich wäre (cache hilft nicht mehr). Für meiner Teil lege ich ein Großer Wert auf IPv6 damit ich mein Server Problemlos aus den Interner erreichen kann. Nfs unter Linux kann es noch nicht. Mit remotefs ist der Zugriff Problemlos, und eine Verschlüsselung (auf Kosten der Geschindigkeit) stelle auch kein Problem.
Sorry for English reply, i don't know German. First, four times faster - it's outdated info, we'll update homepage Second, this is not killer fs in any way, and it's not NFS replacement. It's just filesystem for home NAS, not less, not more. If you find it's senseless, then remotefs is not for you, sorry about that. I would be glad to hear you more precise opinion about remotefs useless by e-mail: aleksey_t@users.sourceforge.net (no mailing list yet), i believe your feedback will be valuable for us, thanks in advance.
Aber nicht wenn der Server ein NAS ist. Diese Geräte haben Leistungsschwache CPU und sehr oft nur 100 Mbps auf der Ethernetseite. Die Übetragungsgeschwindigkeit hängt zudem auch von der Größe der Datei ab. Mit meine Hardware erreicht ntfs (Server zur Client bei große Dateien) gerade 14 MBps, remotefs 20!. Bei manche Dateiengröße ist cifs sogar schneller als NFS.
"... Build scripts are available in SVN (https://remotefs.svn.sourceforge.net/svnroot/remotefs), so you could make packages for your platform(s) if you wish so. ..."
Verwende seit Jahren fuse mit sshfs. Lokal sowie im vom Internet aus. Etwas sicheres, kompatibleres (WinSCP unter Windows, falls Windows unabdingbar ist) und einfach zu wartendes (nur Port 22 offen, Shell-Login kann man unterbinden = sftp, nur sshd muss man per Security-Newsletter verfolgen bzw. ist das einrichten selbst für den Hobby-Admin minimal).
Geschwindigkeit? Wenn der Server in der Ecke nicht ne ganz lahme Krücke (~1GHZ reicht locker für privat) ist, hab ich im 100Mbit LAN 11-12MB/s. Ist mir eh egal, da der Zugriff hauptsächlich über WLAN (zu Hause) oder Internet stattfindet.
Viel Glück mit remotefs und es ist schön bei der Vielfalt, aber m.E. ist das verschwendete Zeit.
"Geschwindigkeit? Wenn der Server in der Ecke nicht ne ganz lahme Krücke (~1GHZ reicht locker für privat) ist, hab ich im 100Mbit LAN 11-12MB/s. Ist mir eh egal, da der Zugriff hauptsächlich über WLAN (zu Hause) oder Internet stattfindet."
Das ist schön für dich, nur bist du nicht das Zentrum der Welt :)
Es gibt aber auch Leute die mit Leistungsschwacher, aber Stromsparender Hardware die sich freuen wenn sie dennoch einen guten Datendurchsatz über eine Kabelverbindung haben.
> Das ist schön für dich, nur bist du nicht das Zentrum der Welt :)
Das könntest Du behaupten, wenn nur ich sshfs verwende
> Es gibt aber auch Leute die mit Leistungsschwacher, aber Stromsparender Hardware
Die können intern im eigenen LAN problemlos FTP verwenden, gerade wenn die Leute Wlan nicht als gute Lösung sehen. Für FTP gibt es auch ein bewährtes Fuse-Modul zum transparenten einbinden. Wenn wirklich Sicherheit/Dateirechte ne Rolle spielen, ist ein Dateisystem von irgendwen eh für die Katz... im Firmen LAN sowieso.
Gibts dann doch noch Windows im heimischen Netzwerk (nicht ungewöhnlich, wenn z.b. die studierende Freundin zwingend Windows benötigt), ist es ganz aus mit dem propietärem RemoteFS von einem Hobbyprogrammierer.
Irgendwie kann man alles anzweifeln. Die News wirkt nach Werbung und wenn jemand ein Remote FS programmieren, aber nicht Samba/NFS fürs heimische Netzwerk einrichten kann, hat er eh schlecht argumentiert... sehr schlecht... die 10-20 Zeilen smb.conf fürs heimische Netzwerk werd ich ihm vielleicht mal mailen. Dann funktionieren sogar Zeichensätze mit Linux _und_ Windows. Samba/NFS ist eh überall dabei, RemoteFS müsste man sich selbst kompilieren. Und auch da: wer das schafft/kann, kann problemlos NFS oder Samba konfigurieren.
Naja, egal. Viel Spaß, auch wenn es wie eine Nischen-Distribution wirkt, bei der 5 Leute wie wild pro Nischen-Distribution kämpfen... bin ja nur neidisch, weil ich nicht soviel Zeit für sinnlose Euphorie habe ... die Zeiten sind vorbei...
Von Daniel Böhmer am Mo, 20. Oktober 2008 um 11:54 #
Klingt ja vielversprechend. Scheint ja hier einige Leute zu geben, die das schon ausprobiert haben. Vielleicht könnt einer mir ein paar Fragen beantworten:
1.) Stabilität: Läuft das jetzt so gut, dass es mir nicht jeden Tag den Server einreißt? Ich habe kein Problem, wenn ab und an der Daemon streikt und neugestartet werden will. Hauptsache es gehen keine Daten flöten.
Ich hatte bei NFS anfangs öfter mal das Problem, dass sich der Kernel von Client oder auch Server verschluckt hat, wenn man die Netzwerkverbindung getrennt hat (WLAN-Infrastruktur...). Ob das auch beim remotefs passiert?
2.) In den Downloads sehe ich nur das .deb-Paket für den Server? Ist da auch ein Client enthalten? Ich kann das .deb auf dem Server installieren, bräuchte aber den Source-Tarball oder wenigstens korrekte Binaries des Clients für Gentoo. Nebenbei: Wenn das GPL-Software ist, müssten die Sourcen ja irgendwo zu finden sein...
3.) UIDs: Wie werden denn die UIDs bei remotefs gelöst? Das hat mir auch schon einige Probleme hier bereitet.
1) remotefs already has some tools for detection of connection lose and we're still working on this in testing branch 2) At this point, we're providing just packages we're use (if any). I'm using .deb for client and .ipk for server - they're could be found in downloads section. Here is link to SVN: https://remotefs.svn.sourceforge.net/svnroot/remotefs, yes, it's GPL'ed. 3) There are no UIDs and GIDs transferred between client and server, this is how we solved it If file owner is alice:alice, then server tells client that it's "alice:alice" and not "1000:1000" or something. Please refer to rfs man page (known issues) for details on side effects of this approach: http://remotefs.sourceforge.net/rfs.1.html, rfsd man page also has some info about this.
1.) Stabilität: Der Haupt Author nutz es täglich und hat auch jeder Menge von Stresstests vorgenommen. Fehler können wir nicht gänzlich ausschliessen aber das gutes Stück sollte sehr stabil sein. 2.) In den Downloads sehe ich nur das .deb-Paket für den Server? Fehler erkannt ich habe den Hauptautor gerade einer Mail geschickt. Am beste ist es die sbn Version herunterzuladen. Im trunk Verzeichniss befindet sich die Version 0.10, einfach cd /trunk absetzen und make aufrufen (-/configure gibt es nicht dafür können die Makefiles selbständig die passenden Optionen, Betriebssytem/compiler abhängig setzen). Die installation der 2 vorhandenen Programme muss per Hand erfolgen. Im Verzeichniss testing ist die "unstabile" Version die schon weiter und Leistungsfähiger ist als das offizielle Release. 3.) UIDs: Die Ur-Version funktionnierte wie sshfs, nur eben schneller. Bei der 0.10, haben wir einige kleine Erweiterungen vorgenommen. Remotefs ist primär ein persönnliches Dateisystem. Der Server läuft mit der Kennung der angemeldeten Anwender. Du bindest deine Remoteverzeichniss z.B. als daniel:daniel (Aus der Sicht des Servers) und der Server nummit diese Kennung an. In ein weiteren Modus ist es erlaubt das mehere Anwender mit eigenständige Accounts eine gemeisame Verzeichniss teilen. Für jede Anwender läuft eine Instanz des Servers mit der entsprecheden Kennung. Die Uid/Gid werden nicht übertragen, dafür die Anwender und Gruppenname. Diese werden sogut wie möglich auf den Client abgebildet. Wenn Du vom der Firma deines Arbeitsgeber als Login xyz hast und auf dein Server daheim als Daniel bekannt ist, wird daniel auf den Client als xyz abgebildet. Wenn Du daheim bist und z.B. ein Debian server hast und als Workstation eine Fedora, würden normalerweise Probleme mit der UID enstehen. Diese Probleme werden dadurch gelöst das nur die Namen massgeben sind.
Endlich mal was einfacheres als NFS. Auch bei mir ist NFS alles andere als schnell. Das Problem, es war mal schnell >10MB/s auf einer 100MBit Leitung. Mittlerweile bin ich bei ~3.5MB/s und die Prozessoren popeln in der Nase. Die eine Seite (A) ist ein Desktop PC mit Opteron 175 (2.2GHz) und die andere Seite(B) ein Laptop mit Core Duo U2500 (1.2GHz). Desweiteren kann ich Dateien nur von B->A kopieren. Wenn ich es von A->B versuche kommt immer ein Abbruch mit NFS Timeout. Ich habe keine Ahnung, wo das Problem sein könnte. Es gibt diesbezüglich auch keine saubere Anleitung im Netz, was man alles prüfen sollte/kann. BTW: Ein scp von A->B wird immer langsamer(!) von ~1.4MB/s runter auf 10kb/s wenn ich allerdings (B) unter Last setze (z.B. mit glxgears) steigt die Übertragungsrate wieder. Scheint was mit Powermanagement zu tun zu haben.
Ich werde für mich auch mal remotefs probieren, da ich häufiger Dateien im GB Bereich kopieren muss.
Dann solltest Du immer wieder nach der testing Version nachschauen, es wird nicht garantiert dass alles läuft, der momentaner Stand lässt sich aber schauen (besser als der offizieler Release, dafür nicht unbedingt fehlerfrei). Zur Zeit ist der Upload (Server -> Client) sehr gut, die Andere Richtung erfordet noch einiges an Arbeit, dies gehöhrt zu den nächsten Tätigkeiten.
Argh, kein tar ball, nur Debian depp Files. Dann im svn kein configure, kein Haupt Makefile, schade, hätte so einfach sein können, also warte ich noch etwas. Vielleicht strickt ja jemand mal ein brauchbares ebuild für mein Gentoo. Ich würde auch selbst eins stricken, nur leider verstehe ich noch nicht, wie ich aus dem svn trunk content die Dateien erstelle. 'make -f Makefiles/base.mk TAG' geht nicht, egal was ich aus dem 'help' File als TAG angebe. :-(
Dann im svn kein configure, kein Haupt Makefile Configure ? warum es geht besser ohne. Mit den Makefile im SVN Verzeichniss trunk (das Haupt Makefile) geht das kompilieren/cross Kompilieren ohne Probleme auf unterschiedliche Platzforme und mit unterschiedliche Compiler. Kode auf eine Linux, openSolaris oder FreeBSD Rechner bringen und einfach make aufrufen. Da Server und Client nicht auf den selben Rechner laufen, gibt es natürlich die Möglichkeit make rfs, make rfsd und make rfspasswd um die 3 Programme zu ersteleln aufzurufen.
SAMBA kaum zu konfigurieren zusammen mit MS Produkten .....
Endlich was einfaches was einfach tut. Vermutlich kann man via FreeSwan usw. Verschlüsseln ...
Klatr eine Verschöüsselung ist möglich aber die Geschwindigkeit leidet extrem. Ein kleiner Test mit
eine ältere Testversion zeigte gravierende Einbüße, die Gescwindigkeit sank um de faktor 3 bis 5. Getestet war eine Verbindung über ssh. Falls die vom Kernel angebotene Fähigkeiten verwendet werden, bei NAS für den Heimbereich selten vorhanden sollte es besser gehen aber immer noch mit Nachteile bezüglich Geschwindigkeit. Mit einer Testversion erreiche ich Zur Zeit bei der Übertragung von große Dateien bis zur 25 MB / sekunde. Dies ist sehr stark von der im NAS Gerät verbaute Hardware abhängig, bei den Hauptauthor sind die Ergebnisse wesentlich schlechter.
Ein weiteren Vorteil von Remotefs ist dass das Exportieren einer Verzeichniss über das Internet kein Problem darstellt (bis auf der fehlenden Verschlüsselung) und sogar IPv6 unterstüzt wird.
Wohl mehr dein persönliches Problem als eins von NFS. ;-)
Außerdem ist ein Dateisystem, von dem auf den Projektseiten gesagt wird:
> The reasons i've decided to make it are a) samba isn't working for me at all
> b) NFS is not working well for me c) sshfs is great, but not very fast.
> In comparison with sshfs, performance on my hardware has improved roughly
> four times (with read/write cache enabled).
Viermal mal schneller mit Cache als sshfs über fuse, das klingt wirklich nach einem Burner. ;-)
> SAMBA kaum zu konfigurieren zusammen mit MS Produkten .....
Warum Leute ein Protokoll aus der Windows-Welt für die Kommunikation zwischen Unix/Linux-Büchsen nutzen wollen, habe ich noch nie verstanden.
> Endlich was einfaches was einfach tut.
Ein weiteres sinnloses Projekt, das halbfertig auf Sourceforge vergammeln wird.
Vielleicht weil bei NFS die UID/GID auf allen Clients ident sein muss, bei Samba aber vorgegeben werden kann(?)
Das ist falsch. Schau dir die Manpage zu /etc/exports an, Stichwort {root,all,uid,gid}_squash, map_daemon.
Dies war auch meine Meinung. Ich musste diese aber revidieren.
Warum Leute ein Protokoll aus der Windows-Welt für die Kommunikation zwischen Unix/Linux-Büchsen nutzen wollen, habe ich noch nie verstanden.
Ich gebe dir Recht, cifs ist nicht das richtige, die Einrichtung, wie von den Herstellern vorgeshen, ist nicht immer optimal und auch wenn cifs/Samba es versuchen sich nahtlos in der UNIX Welt einzubinden, bleibt es eine Krankheit. Alle NAS bieten nicht NFS und den Anwender bleibt ertsmal nur das Krebsgeschwür übrig.
Im übrigens sind weder NFS noch SAMBA/CIFS so langsam. NFS profitiert stark von den internen Caching so dass der Anwender den Eindruck bekommt dass nfs sehr schnell ist.
Versuche mal ein ls -l auf einer Verzeichniss mit 8000 Einträge vorzunehmen (nfs gerade eingebunden), Bis zur Listing im Terminal vergehen etliche Sekunden, auf mein Hardware über 20 Sekunden, mit remotefs lediglich 0,3 Sekunden.
Beim Streamen von Daten (Video) hilft beim NFS das Cachen auch nicht mehr.
NFS (Server) unter Solaris ist wesentlich geschmeidiger als unter Linux, und wenn man dann NFS von NetApp nimmt fängt es an richtig Spass zu machen. Aber das ist dann auch eher nicht so die Zielgruppe von remotefs ...
> Dies war auch meine Meinung. Ich musste diese aber revidieren.
Das wird die Zeit zeigen.
> Im übrigens sind weder NFS noch SAMBA/CIFS so langsam.
Natürlich nicht. Das wäre ja auch irgendwie erstaunlich, wenn all die Firmen, die sich da engagieren, es in rund 20 Jahren nicht geschafft hätten, das einigermassen performant zu kriegen. ;-)
> NFS profitiert stark von den internen Caching so dass der Anwender den Eindruck bekommt dass nfs sehr schnell ist.
Naja, der lokale Speicher ist ein paar Größenordnungen schneller als das Netzwerk, insofern wirst du wohl kein Netzwerk-Dateisystem finden, das nicht umfangreich Daten cached.
> Versuche mal ein ls -l auf einer Verzeichniss mit 8000 Einträge vorzunehmen (nfs gerade eingebunden), Bis zur Listing im Terminal vergehen etliche Sekunden, auf mein Hardware über 20 Sekunden, mit remotefs lediglich 0,3 Sekunden.
Kann ich nicht nachvollziehen. Ich habe es gerade mal getestet, hier sind das 3 Sekunden (mit Ausgabe nach /dev/null nur noch 1,4s), mit Cache 1,5s (0,7s). Ach ja, zwei angestaubte Athlon64 S939, Ubuntu 8.04. Und ich bin mir noch nicht mal sicher, ob die an einem Gigabit-Switch hängen.
Damit ein Netzwerk-Dateisystem performant ist gehören viele Massnahmen. Bei den erwähntes Beispiel sieht es so aus dass ich auf den Server eine Verzeichniss mit 8000 Dateien angelegt habe. Die Operationen die ich getan habe sind:
# mount server:/exportierteVerieichniss /mnt
$ time ls -l /mnt/verzeichniss >/dev/null
Die Wartezeit betrug bis zur Erscheinen der Zeitangabe mehr als 20 Secunden. Natürlich bringt ein weiteren ls auf dies Verzeichniss eine sehr geringe Antwortzeit. Beim erstenmal ist aber immer langsam.
Es ist zudem zu bedenken dass der Server auf ein langsamen Gerät läuft (CPU mit 200 MHz bei mir) und dass dass die CPU troz GB Etherbetschnittstelle es schaft gerade auf maximal 300Mbps zu übertragen (Kein Protokoll, Telegramme immer mit maximaler Länge, Kein Rücksicht auf Verlust,...) Bei der Hardware des Hauptautors sieht es viel schlechter aus. Trozdem erreicht er gerade bei sehr große Dateien wie z.B. Video Streams wesentlich bessere Werte als mit nfs möglich wäre (cache hilft nicht mehr). Für meiner Teil lege ich ein Großer Wert auf IPv6 damit ich mein Server Problemlos aus den Interner erreichen kann. Nfs unter Linux kann es noch nicht. Mit remotefs ist der Zugriff Problemlos, und eine Verschlüsselung (auf Kosten der Geschindigkeit) stelle auch kein Problem.
Über ein 1Gib-Netzwerk kommt NFS mit gut 37MB/sec rüber.
SMB über Samba schafft so um die 25MB, SMB vom Windows-Server liegt meist noch darunter.
Bei mir sind die 37MB/sec fast das max. der Festplatten-Transferrate.
joop ... und ich würde es gern testen ...
nur geht nicht ...
weil: - nur deb-pakete und openwrt, nix tgz oder was für vernünftige distr...
http://remotefs.sourceforge.net/
Geschwindigkeit? Wenn der Server in der Ecke nicht ne ganz lahme Krücke (~1GHZ reicht locker für privat) ist, hab ich im 100Mbit LAN 11-12MB/s. Ist mir eh egal, da der Zugriff hauptsächlich über WLAN (zu Hause) oder Internet stattfindet.
Viel Glück mit remotefs und es ist schön bei der Vielfalt, aber m.E. ist das verschwendete Zeit.
Das ist schön für dich, nur bist du nicht das Zentrum der Welt :)
Es gibt aber auch Leute die mit Leistungsschwacher, aber Stromsparender Hardware die sich freuen wenn sie dennoch einen guten Datendurchsatz über eine Kabelverbindung haben.
Nicht jeder empfindet W-Lan als eine gute Lösung.
Das könntest Du behaupten, wenn nur ich sshfs verwende
> Es gibt aber auch Leute die mit Leistungsschwacher, aber Stromsparender Hardware
Die können intern im eigenen LAN problemlos FTP verwenden, gerade wenn die Leute Wlan nicht als gute Lösung sehen. Für FTP gibt es auch ein bewährtes Fuse-Modul zum transparenten einbinden. Wenn wirklich Sicherheit/Dateirechte ne Rolle spielen, ist ein Dateisystem von irgendwen eh für die Katz... im Firmen LAN sowieso.
Gibts dann doch noch Windows im heimischen Netzwerk (nicht ungewöhnlich, wenn z.b. die studierende Freundin zwingend Windows benötigt), ist es ganz aus mit dem propietärem RemoteFS von einem Hobbyprogrammierer.
Irgendwie kann man alles anzweifeln. Die News wirkt nach Werbung und wenn jemand ein Remote FS programmieren, aber nicht Samba/NFS fürs heimische Netzwerk einrichten kann, hat er eh schlecht argumentiert... sehr schlecht... die 10-20 Zeilen smb.conf fürs heimische Netzwerk werd ich ihm vielleicht mal mailen. Dann funktionieren sogar Zeichensätze mit Linux _und_ Windows. Samba/NFS ist eh überall dabei, RemoteFS müsste man sich selbst kompilieren. Und auch da: wer das schafft/kann, kann problemlos NFS oder Samba konfigurieren.
Naja, egal. Viel Spaß, auch wenn es wie eine Nischen-Distribution wirkt, bei der 5 Leute wie wild pro Nischen-Distribution kämpfen... bin ja nur neidisch, weil ich nicht soviel Zeit für sinnlose Euphorie habe
... die Zeiten sind vorbei... 
1.) Stabilität: Läuft das jetzt so gut, dass es mir nicht jeden Tag den Server einreißt? Ich habe kein Problem, wenn ab und an der Daemon streikt und neugestartet werden will. Hauptsache es gehen keine Daten flöten.
Ich hatte bei NFS anfangs öfter mal das Problem, dass sich der Kernel von Client oder auch Server verschluckt hat, wenn man die Netzwerkverbindung getrennt hat (WLAN-Infrastruktur...). Ob das auch beim remotefs passiert?
2.) In den Downloads sehe ich nur das .deb-Paket für den Server? Ist da auch ein Client enthalten? Ich kann das .deb auf dem Server installieren, bräuchte aber den Source-Tarball oder wenigstens korrekte Binaries des Clients für Gentoo. Nebenbei: Wenn das GPL-Software ist, müssten die Sourcen ja irgendwo zu finden sein...
3.) UIDs: Wie werden denn die UIDs bei remotefs gelöst? Das hat mir auch schon einige Probleme hier bereitet.
2) At this point, we're providing just packages we're use (if any). I'm using .deb for client and .ipk for server - they're could be found in downloads section. Here is link to SVN: https://remotefs.svn.sourceforge.net/svnroot/remotefs, yes, it's GPL'ed.
3) There are no UIDs and GIDs transferred between client and server, this is how we solved it
Der Haupt Author nutz es täglich und hat auch jeder Menge von Stresstests vorgenommen. Fehler können wir nicht gänzlich ausschliessen aber das gutes Stück sollte sehr stabil sein.
2.) In den Downloads sehe ich nur das .deb-Paket für den Server?
Fehler erkannt ich habe den Hauptautor gerade einer Mail geschickt.
Am beste ist es die sbn Version herunterzuladen. Im trunk Verzeichniss befindet sich die Version 0.10, einfach cd /trunk absetzen und make aufrufen (-/configure gibt es nicht dafür können die Makefiles selbständig die passenden Optionen, Betriebssytem/compiler abhängig setzen). Die installation der 2 vorhandenen Programme muss per Hand erfolgen.
Im Verzeichniss testing ist die "unstabile" Version die schon weiter und Leistungsfähiger ist als das offizielle Release.
3.) UIDs:
Die Ur-Version funktionnierte wie sshfs, nur eben schneller. Bei der 0.10, haben wir einige kleine Erweiterungen vorgenommen.
Remotefs ist primär ein persönnliches Dateisystem. Der Server läuft mit der Kennung der angemeldeten Anwender. Du bindest deine Remoteverzeichniss z.B. als daniel:daniel (Aus der Sicht des Servers) und der Server nummit diese Kennung an. In ein weiteren Modus ist es erlaubt das mehere Anwender mit eigenständige Accounts eine gemeisame Verzeichniss teilen. Für jede Anwender läuft eine Instanz des Servers mit der entsprecheden Kennung. Die Uid/Gid werden nicht übertragen, dafür die Anwender und Gruppenname. Diese werden sogut wie möglich auf den Client abgebildet.
Wenn Du vom der Firma deines Arbeitsgeber als Login xyz hast und auf dein Server daheim als Daniel bekannt ist, wird daniel auf den Client als xyz abgebildet.
Wenn Du daheim bist und z.B. ein Debian server hast und als Workstation eine Fedora, würden normalerweise Probleme mit der UID enstehen. Diese Probleme werden dadurch gelöst das nur die Namen massgeben sind.
Dann bist du hier nicht oft
Auch bei mir ist NFS alles andere als schnell. Das Problem, es war mal schnell >10MB/s auf einer 100MBit Leitung. Mittlerweile bin ich bei ~3.5MB/s und die Prozessoren popeln in der Nase. Die eine Seite (A) ist ein Desktop PC mit Opteron 175 (2.2GHz) und die andere Seite(B) ein Laptop mit Core Duo U2500 (1.2GHz). Desweiteren kann ich Dateien nur von B->A kopieren. Wenn ich es von A->B versuche kommt immer ein Abbruch mit NFS Timeout. Ich habe keine Ahnung, wo das Problem sein könnte. Es gibt diesbezüglich auch keine saubere Anleitung im Netz, was man alles prüfen sollte/kann. BTW: Ein scp von A->B wird immer langsamer(!) von ~1.4MB/s runter auf 10kb/s wenn ich allerdings (B) unter Last setze (z.B. mit glxgears) steigt die Übertragungsrate wieder. Scheint was mit Powermanagement zu tun zu haben.
Ich werde für mich auch mal remotefs probieren, da ich häufiger Dateien im GB Bereich kopieren muss.
der momentaner Stand lässt sich aber schauen (besser als der offizieler Release, dafür nicht unbedingt fehlerfrei).
Zur Zeit ist der Upload (Server -> Client) sehr gut, die Andere Richtung erfordet noch einiges an Arbeit, dies gehöhrt zu den nächsten Tätigkeiten.
Configure ? warum es geht besser ohne.
Mit den Makefile im SVN Verzeichniss trunk (das Haupt Makefile) geht das kompilieren/cross Kompilieren ohne Probleme auf unterschiedliche Platzforme und mit unterschiedliche Compiler. Kode auf eine Linux, openSolaris oder FreeBSD Rechner bringen und einfach make aufrufen.
Da Server und Client nicht auf den selben Rechner laufen, gibt es natürlich die Möglichkeit make rfs, make rfsd und make rfspasswd um die 3 Programme zu ersteleln aufzurufen.