Diseqc und Channel-Konfiguration dran
DiSEqC brauchst Du nur wenn Du mehrere Satelliten empfängst oder wenn Du SCR/Unicable hast.
Kanäle nimmst Du ganz einfach von Channelpedia (in WFE).
Albert
Diseqc und Channel-Konfiguration dran
DiSEqC brauchst Du nur wenn Du mehrere Satelliten empfängst oder wenn Du SCR/Unicable hast.
Kanäle nimmst Du ganz einfach von Channelpedia (in WFE).
Albert
DiSEqC brauchst Du nur wenn Du mehrere Satelliten empfängst oder wenn Du SCR/Unicable hast.
Guckst Du meine Sig - hab hier einen Wavefrontier-Spiegel mit zwei Quad-LNBs. Immerhin habe ich vorhin, nachdem ich die channels.conf mal mit einigen Astra-Sendern gefüllt hatte, über eine DVB-S-Karte sofort EPG-Daten bekommen ("Was läuft?").
In meinem alten Linvdr gab es ja auch schon eine diseqc.conf - die müßte ich ja einfach übernehmen können. Da komme ich jedenfalls noch gut ran.
Kanäle nimmst Du ganz einfach von Channelpedia (in WFE).
Jupp, genau dort hab ich mich vorhin bedient.
Mit sudo fdisk -l habe ich nun auch die vier direkt erreichbaren Platten (plus die Systemplatte) aufgestöbert. Die SATAs sind bislang weder formatiert noch gemounted, natürlich auch noch nicht in der fstab (oder ist das jetzt doppeltgemoppelt?)
In einem Deiner Links fand ich den Hinweis, daß der von mir benutzte PCI-4-SATA-Kanal-Controller eigentlich ein Zweikanaler ist, der noch zwei 2in1-Multiplier mit draufhat. Den Vorläufer (SiI 2114?) konnte ich damals, wenn ich mich recht erinnere, in die Mahlzeit-Distri einfach so reinstecken, als ich die von 2 auf 4 SATA-Platten erweitert habe. Plug and play. Da muß ich hier mal ein bißchen suchen, ich werde ja nicht der erste und einzige sein, der diesen Controller in dieser Anwendung einsetzt.
Nu ist erstmal Feierabend. Vielen Dank in die Runde so weit!
Ach ja, und an die Macher von yaVDR richte ich auch schon mal ein herzliches Dankeschön! Da ist viel Gutes drin, und schön stabil bisher.
Gruß,
U.
DiSEqC brauchst Du nur wenn Du mehrere Satelliten empfängst oder wenn Du SCR/Unicable hast.
Hab gestern abend noch gesehen, daß es da ja schon eine vorkonfigurierte diseqc.conf gibt. Irgendwas daran scheint zu stimmen, denn ich konnte heute morgen hier schon ZDF, ZDF_neo und NDR SH auf den PC streamen. Alles in SD, HD findet hier (noch) nicht statt.
Das Erste sah ich zwar auch in der Liste, die EPG-Daten sind auch da, aber da streamte nichts.
Immerhin.
Gruß,
U.
Zitat von »UlrichKliegis«
Kann mir hier jemand sagen, ob der Treiber für SiliconImage3114-Controller im yaVDR-Kernel schon drin ist?
Ist seit 2.4.18-14 drin, wie Du es auch schon gefunden hast. Lies mal das hier durch, Du hast ein fakeraid Kontroller!
So. Gute Nachrichten. Die beste ist typisch: Der SiI3114 hat mir die ganze Zeit die vier Platten gezeigt, die an ihm dranhängen. Ich ging bis eben davon aus, daß zwei davon aber über den etwas exotischen IDE<>SATA-Adapter angebunden waren, den ich auf dem zweiten IDE-Platz stecken habe. Nein, aber wenn ich zu blind bin, zu erkennen, daß der Floppy-Stromversorgungsstecker auf dem kleinen Konverter beileibe nicht der Versorgung eines allfälligen Antikgerätes zur spanhebenden Datenverarbeitung dient, sondern dem Eigenverbrauch (denn über den IDE-Port gibbet nichts!), bin ich ja selbst schuld. Sorry, daß ich hier mit meiner Fragerei nach Treibern unnütz Aufregung gestiftet habe, zumindest habe ich aber für die Links zur Treiberkonfiguration zu danken, man wird ja nicht blöder, wenn man das liest. Und wenn man dann Herrn Galva die Ehre gibt und den Controller richtig anschließt, wird man mit zwei weiteren Platten im System belohnt. Fein. Nu gibts auch sdf und sdg.
Erwähnte ich schon, daß Hotbird auch schon ganz gut reinkommt? Evtl. muß ich bei der Diseqc-Konfiguration noch ein bißchen rumtauschen, denn das sieht noch nicht ganz richtig aus, aber das kommt.
So, nun kommt noch mal was vermeintlich Triviales - die Einbindung der sechs 2TB-HDD als Video-Senke. Da ich mich nach wie vor als Linux-Vorschüler sehe, wäre ich für eine hinreichend detaillierte Backanleitung dankbar, zumindest für einen Fingerzeig auf ein ~4dummies - Tutorial, oder wie man das heute nennt. Die einschlägigen Hinweise hier gehen meistens davon aus, daß schon eine video-Partition existiert.
Die Systemplatte ist also sde, sda..d und sdf und sdg sind für Video vorgesehen.
Wenn das getan ist, sind noch die Media-MVP dran. Das habe ich vor Jahren schon mal für die Mahlzeit-Kiste hinbekommen, es sollte also möglich sein.
Gruß,
U.
grundsätzlich wäre ein Post pro Problem wünschenswert.
Zum Thema: Was sind es für Platten, wie hast du vor sie einzubinden ?
Du hättest da so ca 4 Möglichkeiten:
- mdraid (softraid) - eine grosse Partition (je nachdem was es für Platten sind könnte es ein Problem werden)
- LVM - eine grosse Partition
- mhddfs - eine grosse Partition
- einzeln einhängen, Zusammenführen mit VDR
Alle haben Ihre Vor und Nachteile. Sinnvoll wäre sicher ein Raid5 wenn möglich. Hier verlierst du dann IMHO die Kapazität einer Platte, aber kannst bei defekt eine Platte mal tauschen ohne Daten zu verlieren.
Um 6 Platten mit jeweils 2 TB (soweit ich das verstanden habe) in dein System einzubinden solltest du dir überlegen welche Anforderungen du daran stellst.
Imho gibt es 2 (oder mehr) grundlegende Varianten mit vor und Nachteilen:
- alle Videoplatten per mhddfs als eine große zusammenhängen (können auch schon Daten drauf sein und unterschiedliche Filesysteme haben) - das ist auch das Konzept von yavdr soweit ich das sehe ( ? )
- ein SoftwareRaid 5 oder 6 Verbund
- ein ZFS Pool - das ist aber "höhere" und experimentelle Thematik
- LVM - don't ask me
- einzellen einhängen und verlinken
Aus eigener Erfahrung bin ich mit mhddfs sehr zufrieden. Wenn mal eine Platte sterben sollte dann fehlt halt nur dass was drauf war. Die restlichen Platten kümmert das nicht.
Eine Schritt für Schritt Anleitung kann ich dir aber nicht aus dem Hut zaubern - aber so grob
- Platten partitionieren und formatieren (yavdr empfielt XFS als Filesystem) - kannst auch mit einer externen live boot cd wie z.b. qparted machen.
- Dann einbinden in yavdr per FSTAB über UUID (nicht über /dev ) nach /mnt/sda1 usw.
- Inhalt von /srv/ auf erste Platte /mnt/sda1 kopieren
- fstab eintrag für mhddfs erstellen (bzw. vorher testen über Consolen befehl) und nach /srv/ mounten
so in der Art:
mhddfs#/mnt/sda1,/mnt/sdb1,/mnt/sdc1,/mnt/sdd1,/mnt/sdg1,/mnt/sdh1 /srv fuse 0 0
Damit erhältst du eine virtuelles riesige Platte mit der Größe der Summe aller Datenplatten
Lesestoff:
http://www.yavdr.org/documentation/0.5/de/ch02s01.html
http://wiki.ubuntuusers.de/fstab
http://manpages.ubuntu.com/manpages/lucid/man1/mhddfs.1.html
Bitte um Korrektur und Anregungen
Joe
grundsätzlich wäre ein Post pro Problem wünschenswert.
Erstmal Dank für die Antwort, dann: Danke, ja, eigentlich klar, Usenet-Sozialisation...
Zum Thema: Was sind es für Platten, wie hast du vor sie einzubinden ?
Sechs Stück HD204 UI, 5 davon als Seasung/Samgate-Variante. Alle über SATA, mit fdisk-l sichtbar.
Die Frage der Einbindung war bei meinem ersten Mahlzeit-Linvdr vor vielen Jahren auch einfacher. Da begann ich mit zwei 400 GB-Platten und war der King in meiner Straße :)- Zum Schluß steckten da (und stecken noch, fast voll) 4,5 TB drin, auf vier Scheiben.
Fazit: 2TB / Platte sind zwar viel, aber auch die werden eines Tages Platz machen müssen. Das System sollte also wachstumsfähig sein.
Da ich Media-MVP als Guck-Client einsetze, begrenzte dann VOMP irgendwann die Zahl der dort im Inhaltsverzeichnis noch sichtbaren Aufnahmen, was nicht nur den WAF abrupt drückte. Soweit ich es gesehen habe, sind die Probleme heute keine mehr, aber das ist dann wirklich ein neuer Thread. Ist ja ab einem gewissen Komplexitätslevel immer die Frage, wo und wie dieselbe am besten gestellt wird.
Du hättest da so ca 4 Möglichkeiten:
- mdraid (softraid) - eine grosse Partition (je nachdem was es für Platten sind könnte es ein Problem werden)
- LVM - eine grosse Partition
- mhddfs - eine grosse Partition
- einzeln einhängen, Zusammenführen mit VDR
Wie ist es denn bei mdraid (gefühlt eigentlich nicht der Favorit) mit dem Austausch von Platten gegen größere? Sprich, die ganze Sammlung könnte eines Tages ja auch in eine andere Host-Harware wandern... Eierlegende Wollmilchsau gibts nicht oder ist teuer, klar, aber einzeln wären Eier, Wolle, Milch und Schinken schon ok...
Alle haben Ihre Vor und Nachteile. Sinnvoll wäre sicher ein Raid5 wenn möglich. Hier verlierst du dann IMHO die Kapazität einer Platte, aber kannst bei defekt eine Platte mal tauschen ohne Daten zu verlieren.
Nun ist dieses ja kein System zum Echtzeit-Logging einer Reise zu den Klingonen. Was weg ist, ist weg. Kann man etwas über die Sinnhaftigkeit des Raid-Einsatzes hier sagen - wieviele Leute haben damit schon Platten wiederhergestellt, speziell in dieser Umgebung? Logo, das wird nicht jeder berichten, aber... - Dabei auch die Frage nach der Migrationsfähigkeit und zukunftssicheren Kompatibilität - das System soll sicher einige Jahre im Keller vor sich hin möllern.
- alle Videoplatten per mhddfs als eine große zusammenhängen (können auch schon Daten drauf sein und unterschiedliche Filesysteme haben) - das ist auch das Konzept von yavdr soweit ich das sehe ( ? )
Könnte ich da z.B. auch die Platten aus dem alten Mahlzeit-Server über das LAN mit einbinden? Das wäre ja hochelegant! Dem würde ich dann vielleicht auch noch einen yavdr-Hut aufsetzen. Oder letzteres als stand-alone-Lösung, optional, wenn das geht, miteinander vernetzt, sodaß jeder auf den Aufnahmebestand der anderen Kiste zugreifen kann - wahrscheinlich zu weit geträumt.
- ein SoftwareRaid 5 oder 6 Verbund
- ein ZFS Pool - das ist aber "höhere" und experimentelle Thematik
- LVM - don't ask me
- einzellen einhängen und verlinken
Danke auch hierfür! Der Mahlzeit-linvdr verteilte Aufnahmen ja über mehrere Platten, wohl im Sinne der gleichmäßigen Füllung. Das war dann beim inkohärenten Vergrößern der Laufwerke manchmal etwas überraschend, aber... Ich geh mal gutgläubig davon aus, daß die Macher von yavdr und solchen Konzepten wie mhddfs weiter vorausgedacht haben als ich es jetzt kann. Wo wären Stolpersteine, Nachteile, Fallen, wenn ich mich für mhddfs entscheiden würde? (Außer der Ausfallsicherheit von Raid - geht Raid nicht auch auf die Performance? Es soll ja noch alles über den PCI-Bus laufen.
Übrigens hat INTOS in seinem Datenblatt für den 17-Euro-netto-Vierkanal-Controller stehen, daß der 150 GB/s transportiert. Was reg ich mich also auf?
Euch beiden (und den stillen Mitdenkern ebenso) meinen herzlichen Dank!
Gruß,
U.
Raid5 dürfte je nach CPU immernoch schnell genug sein. Zumindest nicht langsamer als eine einzelne Platte.
http://de.wikipedia.org/wiki/R…_Parit.C3.A4tsinformation
"RAID 5 bietet sowohl gesteigerten Datendurchsatz beim Lesen von Daten als auch Redundanz bei relativ geringen Kosten"
Und ja die Platten sollten gleich groß sein.
MHDDFS: "Nehme alle Platten lege dessen Inhalt übereinander. Schreibe immer auf die Platte mit dem meisten verfügbaren Speicher. "
Also im wesentlichen die Funktionsweise des VDR als virtuelles Dateisystem. Das ist auch der Hauptgrund des Einsatzes bei uns. Wie gibt man mehrere Videoverzeichnisse per NFS frei ? Man muss sie ja zusammenführen.
In Anbetracht der Tatsache, dass Klaus in der Post-2.0 Ära die Video-Verzeichnis-Zusammenführung aus dem VDR schmeissen will, eine gute Alternative. Man muss sich auch nicht mit der Komplexität von LVM auseinandersetzen - übereinandergelegt, zusammengeklebt, fertig.
Nachteil: Es ist ein FUSE Dateisystem. Die Daten liegen aber am Ende ganz normal auf den zugrundeliegenden Dateisystemen.
LVM: Komplexität. Ich weiss nicht genau was passiert wenn eine Platte ausfällt.
Vorteil: Man kann verschiedene Platten zu einem grossen Dateisystem verbinden, auch unterschiedlicher Grösse und auch nachträglich (bei entsprechenden Dateisystem).
ZFS, BTRFS RAID/LVM Funktionen: keine Ahnung wie sicher/nützlich die sind.
LVM: Komplexität. Ich weiss nicht genau was passiert wenn eine Platte ausfällt.
Wenn man kein zusätzliches Netz wie einen RAID-Verbund eingebaut hat, der den Ausfall einer oder mehrerer Platten kompensieren kann, sind alle Daten weg: http://wiki.ubuntuusers.de/Log…ger?redirect=no#Nachteile
MHDDFS ist sicherlich nett, aber die Probleme fangen dann an, wenn man die Konstellation hat, dass nicht alles was im VDR-Aufnahmeverzeichnis liegt beschreibbar sein soll bzw. wenn man Daten gezielt an eine Stelle (z.B. externe Platte, NAS) befördern möchte. Auch das Mounten zusätzlicher Quellen auf dem Fuse-Dateisystem ist nicht wirklich sinnvoll möglich. Symlinks in einen (Quell)ordner des mhddfs funktionieren nur mit absoluten Pfaden.
aber die Probleme fangen dann an, wenn man die Konstellation hat, dass nicht alles was im VDR-Aufnahmeverzeichnis liegt beschreibbar sein soll
Ich empfehle einen Blick auf AUFS: http://aufs.sourceforge.net/
Hier hat man die Möglichkeit R/O Branches einzubinden.
bzw. wenn man Daten gezielt an eine Stelle (z.B. externe Platte, NAS) befördern möchte.
Wenn die Schreibstrategie so aussieht das immer der Branch genutzt wird wo das Top Level Directory exisitert, dann kann man das schon steuern. Einfach ./ARCHIV auf dem NAS Branch erstellen, dann gehen alle Schreibvorgänge unter ./ARCHIV/* dort hin. Es sei denn dort geht der Platz aus, dann wird ein anderer R/W Branch genutzt.
http://aufs.sourceforge.net/aufs3/man.html
Speziell -> Policies to Select One among Multiple Writable Branches
cu
MHDDFS ist sicherlich nett, aber die Probleme fangen dann an, wenn man die Konstellation hat, dass nicht alles was im VDR-Aufnahmeverzeichnis liegt beschreibbar sein soll bzw. wenn man Daten gezielt an eine Stelle (z.B. externe Platte, NAS) befördern möchte. Auch das Mounten zusätzlicher Quellen auf dem Fuse-Dateisystem ist nicht wirklich sinnvoll möglich. Symlinks in einen (Quell)ordner des mhddfs funktionieren nur mit absoluten Pfaden.
Problemvariante 1 sehe ich hier im Augenblick noch nicht, was nach "bzw." kommt - heißt das, daß ich z.B. mit Winscp nicht in das oder aus dem Monsterlaufwerk als solchem schreiben oder lesen kann? Also doch lieber einzeln einhängen?
Ich empfehle einen Blick auf AUFS:
Hab ich angesehen. Ohne alles zu verstehen, macht mich der Changelog etwas zurückhaltend, weil da Funktionen auch wieder rausgenommen werden, die ich nicht einschätzen kann. Vor vielen Jahren hatte Microsoft ja sogar mal eine Verkettung von Partitionen (war es eine der letzten MSDOS-Versionen? Ja, eher als win <=3.11), wie ich es vorher nur mal in einem halbtägigen UNIX-Kurs gesehen hatte, auf diesem ersten tragbaren Unix-Rechner von HP. Muß Anfang der 90er gewesen sein.
MHDDFS: "Nehme alle Platten lege dessen Inhalt übereinander. Schreibe immer auf die Platte mit dem meisten verfügbaren Speicher. "
Also im wesentlichen die Funktionsweise des VDR als virtuelles Dateisystem. Das ist auch der Hauptgrund des Einsatzes bei uns. Wie gibt man mehrere Videoverzeichnisse per NFS frei ? Man muss sie ja zusammenführen.
In Anbetracht der Tatsache, dass Klaus in der Post-2.0 Ära die Video-Verzeichnis-Zusammenführung aus dem VDR schmeissen will, eine gute Alternative. Man muss sich auch nicht mit der Komplexität von LVM auseinandersetzen - übereinandergelegt, zusammengeklebt, fertig.
Nachteil: Es ist ein FUSE Dateisystem. Die Daten liegen aber am Ende ganz normal auf den zugrundeliegenden Dateisystemen.
Doch MHDDFS? Wird das noch weiterentwickelt, und erweitern sich dann ggf. die Möglichkeiten auch für bestehende Installationen?
Zu "Nachteil": das heißt: MHDDFS ist sozusagen so eine Über-Inhaltsverwaltung, die weiß, was wo liegt, auf das hat man aber im Zweifel auch ohne das MHDDFS Zugriff? Sorry, wenn ich nicht auf Eure Acronym-Nomenklatur einsteige(n kann). Slightly conFUSEd Warum ist FUSE ein Nachteil? (Völlig ahnungslos fragend, aber einordnen können möchtend).
Gruß,
U.
Problemvariante 1 sehe ich hier im Augenblick noch nicht, was nach "bzw." kommt - heißt das, daß ich z.B. mit Winscp nicht in das oder aus dem Monsterlaufwerk als solchem schreiben oder lesen kann? Also doch lieber einzeln einhängen?
Lesen aus dem mhddfs ist kein Problem. Aber das gezielte schreiben auf einen der Quellordner des fuse-Dateisystems. Nimm mal an, du hast ein Video-Archiv auf einem NAS/alten VDR oder einer externen Festplate und willst es unter /srv/vdr/video.00/Archiv einhängen, damit der VDR es anzeigt.
mhddfs schreibt immer in das Quellverzeichnis mit dem größten freien Speicherplatz - damit funktioniert z.B. das Verschieben von Aufnahmen über das VDR-OSD (mit extrecmenu) nicht zuverlässig, weil ja z.B. auf einem anderen Quellverzeichis mehr freier Speicherplatz vorhanden sein kann als auf dem NAS/der externen Platte - damit hat man keine Kontrolle wo die Daten landen. Bei nicht-beschreibbaren Datenträgern ist das Verhalten für den normalen Nutzer auch recht unerwartet: es gibt keine Fehlermeldung, aber die Daten landen woanders, wo der Schreibzugriff möglich ist, nicht unbedingt da wo man sie eigentlich haben wollte...
aufs muss ich mir mal genauer anschauen (die Manpage hat es ja in sich) - insbesondere, ob das mit dem NFS-Export für alle Fälle so funktioniert wie es soll (oder ob die Beschränkungen da Probleme machen können).
aufs muss ich mir mal genauer anschauen (die Manpage hat es ja in sich) - insbesondere, ob das mit dem NFS-Export für alle Fälle so funktioniert wie es soll (oder ob die Beschränkungen da Probleme machen können).
Das muss sowieso einfach mal jemand im ernsthaften produktiv Betrieb ausprobieren *), theoretisch funktioniert aufs hier ja klasse, aber wie es praktisch wohl aussieht? Da gibts ja generell einige Fallstricke, so führt z.B. ein mutiges chown -R vdr aufs Videoverzeichnis dazu das alle Dateien aus dem Archiv (also den R/O Branches) in einen R/W Branch kopiert werden.
Man muss sich für solche Sachen also generell ein sauberes Arbeiten angewöhnen sonst passieren da gerne seltsame Dinge.
Wobei irgendein Overlay Dateisystem für den VDR IMHO generell die einzig vernünftige Variante ist (wenn man das VDR eigene System ersetzen will). LVM, RAID und Co. erfordern ja Einarbeitung und ständige Wartung, sonst sitzt man schnell auf nem haufen nutzloser Daten und verliert alles.
cu
*) Ich nutze es nur für mein VDR Configverzeichnis und für mein VDR Quellverzeichnis um den Upstreamcode von meinen eigenen Basteleien zu trennen. Und da hat es sich im praktischen Betrieb bestens bewährt.
Wenn ich das so lese, neige ich derzeit doch eher zur klassischen Einzelpartitionen-verwenden-Option, weil die Interaktion mit anderen Quellen und Servern hier sicher irgendwann mal relevant wird. Und wenn ich es richtig verstanden habe, behalte ich ja die Möglichkeit, die Einzelplatten später doch mal zusammenwachsen zu lassen.
Und daher noch mal auf Feld 1: alle sechs Platten formatieren als xfs (womit? qparted-CD machen?), und wie dann weiter?
Gruß, Dank,
U.
aufs ist obsolete und wird nicht mehr lange unterstützt meine ich. overlayfs ist hier der letzte Schrei ;).
Kann man bei mhddfs nicht einen Mount in das Dateisystem machen *1 ? Das wäre mir neu.
*1 mhddfs hängt auf /srv/vdr/video.00 und man hängt das Archiv auf /srv/vdr/video.00/Archiv ein ? Daten die in /srv/vdr/video.00/Archiv geschrieben werden gehen auf eine der mhddfs-Platten ? Das wäre in der Tat ungünstig.
ZitatZu "Nachteil": das heißt: MHDDFS ist sozusagen so eine Über-Inhaltsverwaltung, die weiß, was wo liegt, auf das hat man aber im Zweifel auch ohne das MHDDFS Zugriff?
Genau.
Schreiben ist kein Problem - funktioniert wie beim VDR auf die Platte mit dem meisten Platz, ohne Kompromisse.
Zum Nachteil: FUSE (Filesystem in Userspace) - die Daten gehen vom Prozess in den Kernel , dann in den Userspace (also einem "Server") dann wieder an den Kernel , dann auf die Platte. man hat also mehr Overhead - dürfte aber beim VDR zu vernachlässigen sein. Wenn Morgen kein MHDDFS mehr existiert, nimmt man ein anderes "Zusammenführendes Dateisystem" - es macht nichts anderes als alles wie eine Platte aussehen zu lassen und beim Schreiben die Daten "wieauchimmer" zu verteilen.
Wenn LVM und Raid aus der Wahl sind, kannst du die Platten in der Tat Partitionieren und formatieren. Beim Dateisystem kommt der nächste Glaubenskrieg - ich finde xfs ist eine gute Wahl.
aufs ist obsolete und wird nicht mehr lange unterstützt meine ich.
Die Homepage sagt:
Note: it becomes clear that "Aufs was rejected. Let's give it up."
According to Christoph Hellwig, linux rejects all union-type filesystems
but UnionMount.
Also das übliche "irgendein fuzzy bestimmt das die User das nicht wollen und lehnt es ab", AFAIK gabs bei diversen DVB Sachen ähnliche Probleme.
overlayfs ist hier der letzte Schrei ;).
Oder doch "UnionMount"? Weil alles andere ist per Definition eh überflüssig. Aber wie du sagtest, fuse ist beim VDR auch kein Problem.
Da blickt doch niemand mehr durch, warum nicht ein Unionfs das alle Features hat? Wäre aber vermutlich wieder viel zu langweilig
cu
Eines der Probleme von overlafs (wie es bei aufs aussieht weiß ich nicht) ist IIRC, dass man das lowerdir nicht im Betrieb verändern darf, weil es sonst inkonsistente Zustände geben kann.
Im Git von aufs scheint immer noch was los zu sein, IMHO wäre es schade, wenn die Funktionalität einfach verloren gehen würde...
Moin,
darf ich jetzt noch mal auf meine noch zu machenden Schritte zurückkommen? Wie man damals beim Mahlzeit-VDR einzelne Platten korrekt hizufügte, hatte ich damals irgendwann verstanden. Steht hier auch irgendwo in den tiefsten Archivordnern. Dieses hier ist ja nun noch etwas anders.
Edit-Einfügung: Ich hab beschlossen, zunächst mal mit klassischen, nicht vereinigten Platten arbeiten zu wollen. Das ist also mein Ziel für die nächsten Schritte. Ich stocher nur noch etwas unsicher und hilflos im großen Pool rum ;).
Der letzte Stand war ja, daß nun alle sechs SATA-Platten zumindest in fdisk -l sichtbar sind:
ulli@blueeye:~$ sudo fdisk -l
Disk /dev/sda: 2000.4 GB, 2000398934016 bytes
255 Köpfe, 63 Sektoren/Spur, 243201 Zylinder, zusammen 3907029168 Sektoren
Einheiten = Sektoren von 1 × 512 = 512 Bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes
Festplattenidentifikation: 0x00000000
Festplatte /dev/sda enthält keine gültige Partitionstabelle
Disk /dev/sdb: 2000.4 GB, 2000398934016 bytes
255 Köpfe, 63 Sektoren/Spur, 243201 Zylinder, zusammen 3907029168 Sektoren
Einheiten = Sektoren von 1 × 512 = 512 Bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes
Festplattenidentifikation: 0x00000000
Festplatte /dev/sdb enthält keine gültige Partitionstabelle
Disk /dev/sdc: 2000.4 GB, 2000398934016 bytes
255 Köpfe, 63 Sektoren/Spur, 243201 Zylinder, zusammen 3907029168 Sektoren
Einheiten = Sektoren von 1 × 512 = 512 Bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes
Festplattenidentifikation: 0x00000000
Festplatte /dev/sdc enthält keine gültige Partitionstabelle
Disk /dev/sdd: 2000.4 GB, 2000398934016 bytes
255 Köpfe, 63 Sektoren/Spur, 243201 Zylinder, zusammen 3907029168 Sektoren
Einheiten = Sektoren von 1 × 512 = 512 Bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes
Festplattenidentifikation: 0x00000000
Festplatte /dev/sdd enthält keine gültige Partitionstabelle
Disk /dev/sde: 80.1 GB, 80060424192 bytes
255 Köpfe, 63 Sektoren/Spur, 9733 Zylinder, zusammen 156368016 Sektoren
Einheiten = Sektoren von 1 × 512 = 512 Bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes
Festplattenidentifikation: 0x000e5d98
Gerät boot. Anfang Ende Blöcke Id System
/dev/sde1 * 2048 148897791 74447872 83 Linux
/dev/sde2 148899838 156366847 3733505 5 Erweiterte
/dev/sde5 148899840 156366847 3733504 82 Linux Swap / Solaris
Disk /dev/sdf: 2000.4 GB, 2000398934016 bytes
255 Köpfe, 63 Sektoren/Spur, 243201 Zylinder, zusammen 3907029168 Sektoren
Einheiten = Sektoren von 1 × 512 = 512 Bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes
Festplattenidentifikation: 0x00000000
Festplatte /dev/sdf enthält keine gültige Partitionstabelle
Disk /dev/sdg: 2000.4 GB, 2000398934016 bytes
255 Köpfe, 63 Sektoren/Spur, 243201 Zylinder, zusammen 3907029168 Sektoren
Einheiten = Sektoren von 1 × 512 = 512 Bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes
Festplattenidentifikation: 0x00000000
Festplatte /dev/sdg enthält keine gültige Partitionstabelle
Alles anzeigen
Dann hab ich (hoffentlich richtig) mit xfs formatiert:
ulli@blueeye:~$ sudo mkfs.xfs -f /dev/sda
meta-data=/dev/sda isize=256 agcount=4, agsize=122094662 blks
= sectsz=512 attr=2, projid32bit=0
data = bsize=4096 blocks=488378646, imaxpct=5
= sunit=0 swidth=0 blks
naming =version 2 bsize=4096 ascii-ci=0
log =Internes Protokoll bsize=4096 blocks=238466, version=2
= sectsz=512 sunit=0 blks, lazy-count=1
realtime =keine extsz=4096 blocks=0, rtextents=0
ulli@blueeye:~$ sudo mkfs.xfs -f /dev/sdb
meta-data=/dev/sdb isize=256 agcount=4, agsize=122094662 blks
= sectsz=512 attr=2, projid32bit=0
data = bsize=4096 blocks=488378646, imaxpct=5
= sunit=0 swidth=0 blks
naming =version 2 bsize=4096 ascii-ci=0
log =Internes Protokoll bsize=4096 blocks=238466, version=2
= sectsz=512 sunit=0 blks, lazy-count=1
realtime =keine extsz=4096 blocks=0, rtextents=0
ulli@blueeye:~$ sudo mkfs.xfs -f /dev/sdc
meta-data=/dev/sdc isize=256 agcount=4, agsize=122094662 blks
= sectsz=512 attr=2, projid32bit=0
data = bsize=4096 blocks=488378646, imaxpct=5
= sunit=0 swidth=0 blks
naming =version 2 bsize=4096 ascii-ci=0
log =Internes Protokoll bsize=4096 blocks=238466, version=2
= sectsz=512 sunit=0 blks, lazy-count=1
realtime =keine extsz=4096 blocks=0, rtextents=0
ulli@blueeye:~$ sudo mkfs.xfs -f /dev/sdd
meta-data=/dev/sdd isize=256 agcount=4, agsize=122094662 blks
= sectsz=512 attr=2, projid32bit=0
data = bsize=4096 blocks=488378646, imaxpct=5
= sunit=0 swidth=0 blks
naming =version 2 bsize=4096 ascii-ci=0
log =Internes Protokoll bsize=4096 blocks=238466, version=2
= sectsz=512 sunit=0 blks, lazy-count=1
realtime =keine extsz=4096 blocks=0, rtextents=0
ulli@blueeye:~$ sudo mkfs.xfs -f /dev/sdf
meta-data=/dev/sdf isize=256 agcount=4, agsize=122094662 blks
= sectsz=512 attr=2, projid32bit=0
data = bsize=4096 blocks=488378646, imaxpct=5
= sunit=0 swidth=0 blks
naming =version 2 bsize=4096 ascii-ci=0
log =Internes Protokoll bsize=4096 blocks=238466, version=2
= sectsz=512 sunit=0 blks, lazy-count=1
realtime =keine extsz=4096 blocks=0, rtextents=0
ulli@blueeye:~$ sudo mkfs.xfs -f /dev/sdg
meta-data=/dev/sdg isize=256 agcount=4, agsize=122094662 blks
= sectsz=512 attr=2, projid32bit=0
data = bsize=4096 blocks=488378646, imaxpct=5
= sunit=0 swidth=0 blks
naming =version 2 bsize=4096 ascii-ci=0
log =Internes Protokoll bsize=4096 blocks=238466, version=2
= sectsz=512 sunit=0 blks, lazy-count=1
realtime =keine extsz=4096 blocks=0, rtextents=0
Alles anzeigen
Das ist der Stand der Dinge:
ulli@blueeye:~$ mount
/dev/sde1 on / type ext4 (rw,errors=remount-ro)
proc on /proc type proc (rw,noexec,nosuid,nodev)
sysfs on /sys type sysfs (rw,noexec,nosuid,nodev)
none on /sys/fs/fuse/connections type fusectl (rw)
none on /sys/kernel/debug type debugfs (rw)
none on /sys/kernel/security type securityfs (rw)
udev on /dev type devtmpfs (rw,mode=0755)
devpts on /dev/pts type devpts (rw,noexec,nosuid,gid=5,mode=0620)
tmpfs on /run type tmpfs (rw,noexec,nosuid,size=10%,mode=0755)
none on /run/lock type tmpfs (rw,noexec,nosuid,nodev,size=5242880)
none on /run/shm type tmpfs (rw,nosuid,nodev)
[color=#ff0000]/srv/vdr/video.00 on /srv/share/vdr type none (rw,bind)[/color]
rpc_pipefs on /run/rpc_pipefs type rpc_pipefs (rw)
nfsd on /proc/fs/nfsd type nfsd (rw)
ulli@blueeye:~$
Alles anzeigen
Was muß ich jetzt tun, um a) die oben rot markierte video.00 wegzubekommen? Denn ich will auf der Systemplatte keine Videodateien haben. Die soll System machen und sonst nichts.
Und was, um die Platten nun verfügbar zu machen?
Bitte ein möglichst explizites Kochrezept, ich hab in den letzen Tage zwar mal wieder viel Linux-Lehrmaterial gelesen, aber da schwirrt mir schon wieder der Kopf ... Vielen Dank!
Und wenn ich ggf. die Verzeichnisse erzeugt (wie? - mit mkdir? ) und gemounted (wie genau, und was fehlt da noch?) habe, was muß ich dann in die fstab genau reinschreiben?
Danke vorab, wie immer! Und einen schönen 3. Atzpfendt!
Gruß,
U.
Was muß ich jetzt tun, um a) die oben rot markierte video.00 wegzubekommen?
Ich kann keine Rotmarkierung erkennen.
System ist OK, der Rest sollte auf /srv gehen, egal ob RAID5 oder sonst was.
Albert
Was muß ich jetzt tun, um a) die oben rot markierte video.00 wegzubekommen?
Das was du meinst ist ein mount-bind über den das Aufnahmeverzeichnis des VDR per NFS exportiert wird. Der stört dein Vorhaben eigentlich nicht...
Das mit der fstab solltest du selbst schaffen, eine kleine Übersicht dazu gibt es im UU-Wiki: http://wiki.ubuntuusers.de/fstab
Sie haben noch kein Benutzerkonto auf unserer Seite? Registrieren Sie sich kostenlos und nehmen Sie an unserer Community teil!