FreeBSD 10.0: Probleme beim Schreiben auf Band (si_iosize_max, MAXPHYS)

[Morfio]

Hallo zusammen,

beim Versuch, auf Tape zu schreiben, erhalte ich nach dem Update auf 10.0 folgende Fehlermeldungen:

sa0.0: request size=2097152 > si_iosize_max=131072; cannot split request
sa0.0: request size=2097152 > MAXPHYS=131072; cannot split request
Could not move: slots are invalid.
sa0.0: request size=2097152 > si_iosize_max=131072; cannot split request
sa0.0: request size=2097152 > MAXPHYS=131072; cannot split request

Weiss jemand, was ich da tun kann?

Viele Grüße

Morfio

 

[andreas.b]

..
beim Versuch, auf Tape zu schreiben, erhalte ich nach dem Update auf 10.0 folgende Fehlermeldungen:

sa0.0: request size=2097152 > si_iosize_max=131072; cannot split request
sa0.0: request size=2097152 > MAXPHYS=131072; cannot split request Could not move: slots are invalid.

Hi,

ich kann dieses Problem mit FreeBSD-10.0-AMD64 bestätigen, aber ich benenne auch die Commando-Situation unter der es aufgetreten ist

Wobei tritt es auf:

cp dumpimg.bin /dev/sa0
cp /dev/sa0 dumpimg.bin

Hintergrund:
ich speichere nur Dateisystem images auf dem Band, kein inkrementelles Backup, und
cp ist dd in dem Fall überlegen, da man nicht erst die performance passende blocksize herrausfummeln muss. Das Verfahren mit copy habe ich auch schon lange mit Schreibversuchen validiert, denn ich will ja ein Backup und nicht nur ein gutes Gewissen eins möglicherweise zu haben. Die Performance
ist super ~103mbyte/s Dauerrate. ( super für meine Ansprüche da ich sata600 platten an einem sata300 controller betreibe weil der SAS-Controller keine SATA Platten >2Gbyte unterstützt)

Andere Fehlermeldung:
Die Fehlermeldung ist bei mir aber etwas anders und zwar minde request size sind "1 048 576" aber die si_iosize_max=131072 stimmt überein:
wärst Du so nett und könntest mal posten wieviel Speicher(RAM und Swap) Du im System einsetzt,

Ich habe den Fehler bei (4Gbyte Swap Partition und 512mbyte) bekommen, jedoch auch nachdem ich auf 2Gbyte den Ram aufgerüstet habe ebenfalls

Ich habe es jetzt mal durch eine Testinstallation von 9.1 auf dem gleichen System (amd64-atom-D510-X7SPA-HF) durchgeführt und siehe da, alles funktioniert wieder.

Alternativweg für Band-Backup:
Alternativ kann ich folgenden Weg vorschlagen: "tar" oder "dump" / "restore", und wenn es vorher verschlüsselt werden soll geht das mit gnupg-symetric (ich feuerte sonst einfach ganze verschlüsselte Dateisystem-Images aufs Band gesplittet über mehrere Bänder, keine crypt/decrypt Last == sehr hohe Datenrate das Band läuft durch der Puffer nicht leer)


Lösungsfindeweg:

1. ist der Wert si_iosize_max über ein sysctl zu erreichen und quasi zur Laufzeit zu verändern, das werde ich testen
   
2. die Quellen von 10 und 9.1/9.2 zum sa-subsystem durchforsten, finde ich ggf. commit messages die auf die Änderung hindeuten, zur Not werde ich testhalber das sa-Subsystem auf den 9.2er Stand zurückpatchen und den Kernel neukompilieren, mal sehen ob es geht (DATENGEFÄHRLICH: JA, bevor ich mich dann auf eine solche Lösung verlasse mache ich Schreibversuche und Hashprüfungen auf den Band-daten)

Hardwaredetails:
Hier war ich aber auch etwas "short on details", es ist ein Quantum LTO-5 SAS laufwerk an einem
"HP gelabelten LSI-Logic SAS/SATA controller"

sa0 at mpt0 bus 0 scbus0 target 2 lun 0
sa0: <QUANTUM ULTRIUM 5 3085> Removable Sequential Access SCSI-6 device
sa0: 300.000MB/s transfers
sa0: Command Queueing enabled

mpt0: <LSILogic SAS/SATA Adapter> port 0xc000-0xc0ff mem 0xfdbec000-0xfdbeffff,0xfdbf0000-0xfdbfffff
irq 16 at device 0.0 on pci1

Update - dem Problem immer einen Schritt näher:
Hab diesen Eintrag hier in der FreeBSD Mailinglist gefunden:
http://lists.freebsd.org/pipermail/freebsd-geom/2010-April/004121.html

datiert zwar auf apr/2010 aber ich habe jetzt einen Anhaltspunkt wo ich weitersuchen muss, um zu überprüfen ob das noch immer "hardcoded" (MAXPHYS) ist, wenn ja dann hab ich das Problem so gut wie gelöst.

 

[andreas.b]

Update2 - nach ein bisschen stöbern in den Quellen:


Ab wann existiert das Problem genau:
seit 10.0 - 9.2(funktioniert) ist nicht betroffen, das ist erstmal mein temporärer Workaround
die ISOs für die beta1 - beta4 von 10.0 sind leider nicht auf die schnelle mehr auffindbar (vom ftp-server gelöscht) finde ich ein bisschen Schade, ausserdem finde ich in den Rel-Notes nicht den Commit-Stand
verzeichnet, ab dem 9.2 und 10.0 eingefroren wurden, also muss ich im svn-baum Suchen.


MAXPHYS:
hardcoded - zwischen 9.1/9.2 und 10 nicht geändert, ausserdem verraten die Einträge in der Mailingliste das man diesen Parameter nicht befummeln sollte


Punkte für die Suche nach dem Auslöser:
- Quellen für das "mpt" / SAS-Controller vergleichen, was gab es an Änderungen
- Commit freeze für 9.2 und 10.0 finden, dazwischen liegen ~3800 commits
- vielleicht geb ich mir den Spass und mach nach eingrenzen durch Commitmessages ein divide & conquer und bau mal 10 Kerne und teste ob das auftritt
- Bevor ich aber Big Bertha raushole werfe ich einen Blick in die Quellen von cp und gucke wo die Abhängigkeiten sind, und brate das von 9.2 einfach über 10.0

 

[ChaosKind]

Hi,

bist du einer Lösung näher? ich habe quasi genau das gleiche Problem mit FBSD10 AMD64, allerdings über den isp(4) treiber auch mit meinen Bandlaufwerken

 

[Morfio]

Ja, bei mir funktioniert es jetzt einwandfrei. Ich hatte eine zu hohe Blocksize eingestellt. Mit dem folgenden Befehl geht es jetzt:

star -c -f=${DRIVE} -h -L -fifo -fifostats fs=800m b=64k -v -time "${TAPE_PATH}"

 

[ChaosKind]

ich habe jetzt den Kernel mal mit "option MAXPHYS=(1024x1024)" kompiliert, mal schauen ob es geht (gerade ebend fertig geworden)
Ich habe leider keine Option die Blocksize runterzusetzen .., da ich mit Bareos arbeite und von einem Linuxsystem "migriere" wo die Blocksize bereits auf 1MB gesetzt war..
und da ein Fullbackup alleine >30 LTO6 Bänder verschlingt will ich die Daten nicht aufgeben

aber mit MAXPHYS auf 1048576 krieg ich trotzdem noch:
(sa11:isp0:0:0:0): 1048576-byte tape record bigger than supplied buffer

ich probiers jetzt mal mit 2097152, wenn das nicht klappt bin ich momentan ratlos

 

[ChaosKind]

Update, also mit 2097152 und kleineren Anpassungen im Bareos/Bacula selbst, läuft das Backupsystem jetzt einwandfrei...
"options MAXPHYS=2097152" in Kernelconf packen und neukompilieren fertig.

 

[cabriofahrer]

Also wenn ich das lese, ist das wieder eine weitere Bestätigung dafür, dass 10.0 offensichtlich nicht ausgereift ist. Ich hatte auch diverse Probleme und bin dann zu 9.3 zurückgekehrt. Tut mir leid. dass ich hier nicht mehr beitragen kann.

 

[foxit]

@ChaosKind
Bareos gibt es ja nicht in den Ports hast du da eine Ahnung ob das kommen wird und ob auch der Director unter FreeBSD läuft?
Danke

 

[ChaosKind]

@foxit Sorry für die Späte antwort, aber kurz gesagt:

Ich habe die Sourcen (ohne Anpassungen!) von Hand compiliert. Der Director, der FileDaemon und der StorageDaemon laufen alle bei mir auf dem FreeBSD System.
Genauere Commandline zum compilieren kann ich gerade nicht sagen, in der bash_history steht sie nicht mehr drin aber im Prinzip muss man nur paar Sachen "weglassen", dann compilerts.