nicx
-
Posts
49 -
Joined
-
Last visited
Content Type
Profiles
Forums
Downloads
Store
Gallery
Bug Reports
Documentation
Landing
Posts posted by nicx
-
-
@bonienl great plugin. is it possible to add the "preserve symlinks" option to a copy process? should be "cp -P" I think. (-P, --no-dereference)
I just realized that if I copy data from one disk to another with a lot of links then the links are "reverted" to real data. The destination disk size was not big enough for that
-
ok, next question: how should I copy the data preserving the symlinks? and because its a lot of data, how to do it in a way that the process survives even. when quitting the ssh shell for example?
-
oh shit... I think I found my mistake by myself: I copied the data via the webgui of unraid (Dynamic File Manager). The source data includes a lot of symlinks. I think all symlinks are now "real data" and no more just links. That is why the data is now a lot bigger on the destination disk. Funny coincidence that the compressed data has an identical size as the source uncompressed data with symlinks
-
here it comes:
root@nas:~# zfs get all disk1/backup | grep compress disk1/backup compressratio 1.63x - disk1/backup compression on inherited from disk1 disk1/backup refcompressratio 1.63x - root@nas:~# root@nas:~# zfs list -t all NAME USED AVAIL REFER MOUNTPOINT cache 545G 377G 248K /mnt/cache cache/appdata 70.8G 377G 70.8G /mnt/cache/appdata cache/domains 56.3G 377G 56.3G /mnt/cache/domains cache/icloud 378G 377G 378G /mnt/cache/icloud cache/isos 14.3G 377G 14.3G /mnt/cache/isos cache/share 1.97G 377G 1.97G /mnt/cache/share cache/system 23.7G 377G 23.7G /mnt/cache/system disk1 2.30T 341G 184K /mnt/disk1 disk1/backup 2.30T 341G 2.30T /mnt/disk1/backup root@nas:~#
and yes, there is no other data on the disk:
root@nas:~# ls -la /mnt/disk1/ total 17 drwxrwxrwx 3 nobody users 3 Feb 23 04:40 ./ drwxr-xr-x 10 root root 200 Feb 22 13:46 ../ drwxrwxrwx 5 nobody users 5 Feb 22 19:50 backup/ root@nas:~# root@nas:~#
-
Hi,
i have turned on ZFS compression on a new array with 1 3tb hdd without parity disk. After turning on, I copied about 2,5 tb data from another identical 3tb disk (unassigned, xfs, without compression)
When looking on the compression rate, its abaou 1.7. But when looking on the disk usage, its exactly the same for the zfs disk in the array and the xfs disk unassigned.
In my expectation the used disk space should differ in relation to the compression rate. Whats wrong?
-
@Archonw Danke für dein Feedback. Mit "Ausfallsicherheit" meine ich aber nicht nur Backup. Das habe ich sowieso noch vor regelmässig auf eine externe HD zu machen. Vielmehr meine ich Hochverfügbarkeit, d.h. bei Ausfall einer SSD soll das System weiter laufen. Das wäre meinem Verständnis nach mit deinem Vorschlag nicht gegeben, oder? Oder ist das "ZFS in einem Mirror" genau das?
Und bzgl. Trim: Als Cache Pool würde Trim dann funktionieren?
-
Hallo zusammen,
ich möchte gerne einen Unraid Server aufbauen. Als Hardware nutze ich einen Dell Optiplex 5070 mit einer i5-9500 CPU (6 cores) und 4x16GB RAM. Dazu habe ich 2 SSDs mit je 1 TB Kapazität (Samsung Pro 850). Wichtig sind mir natürlich Ausfallsicherheit und Performance. Rein von der Datenmenge her reichen mir 1TB an nutzbarer Kapazität völlig.
Jetzt stelle ich mir die Frage, wie ich die SSDs in Unraid konfigurieren soll?!
Frage 1: XFS oder ZFS?
In meiner Konstellation (nur 2 SSDs) scheint es meinem Verständnis nach keinen Vorteil von ZFS zu geben, daher ist auch XFS ok. Im Grunde also egal. Stimmt das?
Frage 2: Array/Pool/Cache?
Ich habe mir überlegt einfach ein Array mit beiden SSDs zu erstellen, eine SSD wird die Party, die andere "normale" Array-Disk. Also kein Cache, kein Pool. Ist das so empfehlenswert? Habe ich eventuell Probleme bzgl. "Trim" der SSDs?
Ergänzung zu Frage 2: Ich hätte auch noch eine dritte baugleiche SSD hier liegen. Rein aus Stromverbrauchs-Gründen habe ich die erst einmal nicht mit eingeplant, sollte es aber eine Empfehlenswertere Konfiguration geben wo alle 3 SSDs benötigt würden wäre das auch OK.
Ich bin gespannt auf eure Ratschläge
-
-
On 1/23/2023 at 8:44 PM, SEL81 said:
Experiencing a similar issue. After reboot of Unraid the USB port that has the Sonoff Stick connected is not passed throug to the VM anymore. Both checkboxes are not ticked. That is an issue. When there is a restart of Unraid due to whatever reason the whole Zigbee stuff cannot be used as Home Assistant inside the VM does not have access to the stick. I also did not quite understand the boot order thing (changed in the Bios?). Is this a bug and or what can be done to reliably keep the passthrough setting even after Unraid reboot?
same here, after a reboot of Unraid the usb devices are missing in the vm. checkboxes in the vm config are not ticked anymore. any hint how to solve this?
-
On 9/15/2021 at 5:00 PM, JonathanM said:
Unraid has a built in NTP server by default. Just point your devices at Unraid's IP.
Hey @JonathanM is this still the case? I just tested it with my Mac client in the same subnet, but got a timeout. Anything else to be aware of?
-
same here... symbolic links are not workung using in docker. any solution?
-
I get the error "Out Of Memory errors detected on your server". Attached the diagnostics. Anything I should care?
-
9 minutes ago, jonathanm said:
How did you come to this conclusion? I just tested it by putting the name of my Unraid server in the ntp server box for one of my windows laptops, and it synchronized just fine. With the appropriate firewall rule in place, it works over WAN as well.
I tried the same with no luck. And if I check the ntp config on the unraid server I can see that its restricted to 127.0.0.1.
-
@jonathanm I stumbled across a similar question: I would have liked to use the built-in NTPD server, but it seems this is limited to the local IP, so it is not usable by other clients. Unfortunately this can't be adjusted via GUI.
For this reason, this Docker solution could be useful. Or does anyone have an idea how to open the integrated NTPD server without more complex customizations?
-
hier nochmal ein kurzer Test mit den 250GB Samsung 850 Evo SATA SSD und sysctl vm.dirty_bytes=100000000:
root@nas:~# dd if=/dev/zero of=/mnt/disk1/test.img bs=128K iflag=count_bytes count=10G 81920+0 records in 81920+0 records out 10737418240 bytes (11 GB, 10 GiB) copied, 77.6048 s, 138 MB/s root@nas:~# dd if=/dev/zero of=/mnt/disk1/test.img bs=128K iflag=count_bytes count=10G 81920+0 records in 81920+0 records out 10737418240 bytes (11 GB, 10 GiB) copied, 70.3208 s, 153 MB/s root@nas:~# dd if=/dev/zero of=/mnt/disk1/test.img bs=128K iflag=count_bytes count=10G 81920+0 records in 81920+0 records out 10737418240 bytes (11 GB, 10 GiB) copied, 71.5436 s, 150 MB/s root@nas:~# dd if=/dev/zero of=/mnt/disk1/test.img bs=128K iflag=count_bytes count=1G 8192+0 records in 8192+0 records out 1073741824 bytes (1.1 GB, 1.0 GiB) copied, 5.52136 s, 194 MB/s root@nas:~# dd if=/dev/zero of=/mnt/disk1/test.img bs=128K iflag=count_bytes count=1G 8192+0 records in 8192+0 records out 1073741824 bytes (1.1 GB, 1.0 GiB) copied, 4.4092 s, 244 MB/s root@nas:~# dd if=/dev/zero of=/mnt/disk1/test.img bs=128K iflag=count_bytes count=1G 8192+0 records in 8192+0 records out 1073741824 bytes (1.1 GB, 1.0 GiB) copied, 4.45699 s, 241 MB/s root@nas:~# dd if=/dev/zero of=/mnt/disk1/test.img bs=128K iflag=count_bytes count=1G 8192+0 records in 8192+0 records out 1073741824 bytes (1.1 GB, 1.0 GiB) copied, 4.45771 s, 241 MB/s root@nas:~# dd if=/dev/zero of=/mnt/disk1/test.img bs=128K iflag=count_bytes count=1G 8192+0 records in 8192+0 records out 1073741824 bytes (1.1 GB, 1.0 GiB) copied, 5.13349 s, 209 MB/s root@nas:~#Mein grundsätzliches Fazit: Ich muss mir überlegen ob ich nicht einfach ein wenig investiere und statt
4* 250GB Evo für Data und 1* 250GB Evo für Parity
dann auf
1* 1TB Pro für Data und 1* 1TB Pro für Parity umswitche.
Zusätzlicher Vorteil im zweiten Fall: Weniger SSDs für den Beginn, und daher erst einmal kein zusätzlicher SATA-Controller benötigt. Ergo geringerer Stromverbrauch. Wenn das System "wachsen" soll dann wird das aber früher oder später nötig, da nur 3 SATA Ports auf dem Mainboard zur Verfügung stehen (und der dritte belegt wäre doch die 3TB WD Backup HDD) .
@mgutt Wäre denn rein aus Performancesicht auch dein Vorschlag mit 1* 1TB Pro als Parity und 4* 250GB Evo als Daten SSDs sinnvoll? Also wie würde sich das denn voraussichtlich auswirken?
-
5 minutes ago, mgutt said:
Was soll das sein? Du musst schon sagen welches Modell genau und ob NVMe oder SATA. Für SATA wäre das Ergebnis zu schnell und für NVMe zu langsam.
Und beim Test war RAM Caching auf 100MB eingestellt?
Sorry, Modell habe ich ergänzt. Es sind Samsung 850 Pro 1TB SATA SSDs.
Und du hast recht, ich hab vergessen das Caching runter zu setzen. Nun hier die Performance Werte mit sysctl vm.dirty_bytes=100000000:
root@Tower:~# dd if=/dev/zero of=/mnt/disk1/test.img bs=128K iflag=count_bytes count=10G 81920+0 records in 81920+0 records out 10737418240 bytes (11 GB, 10 GiB) copied, 20.7396 s, 518 MB/s root@Tower:~# dd if=/dev/zero of=/mnt/disk1/test.img bs=128K iflag=count_bytes count=10G 81920+0 records in 81920+0 records out 10737418240 bytes (11 GB, 10 GiB) copied, 20.712 s, 518 MB/s root@Tower:~# dd if=/dev/zero of=/mnt/disk1/test.img bs=128K iflag=count_bytes count=10G 81920+0 records in 81920+0 records out 10737418240 bytes (11 GB, 10 GiB) copied, 20.7638 s, 517 MB/s root@Tower:~# -
Ein kurzer Test mit den 1TB Samsung 850 Pro SSDs (sowohl Party als auch Daten-Disk) ergibt folgendes Bild:
root@Tower:~# dd if=/dev/zero of=/mnt/disk1/test.img bs=128K iflag=count_bytes count=10G 81920+0 records in 81920+0 records out 10737418240 bytes (11 GB, 10 GiB) copied, 17.1165 s, 627 MB/s root@Tower:~# dd if=/dev/zero of=/mnt/disk1/test.img bs=128K iflag=count_bytes count=10G 81920+0 records in 81920+0 records out 10737418240 bytes (11 GB, 10 GiB) copied, 17.1138 s, 627 MB/s root@Tower:~# dd if=/dev/zero of=/mnt/disk1/test.img bs=128K iflag=count_bytes count=10G 81920+0 records in 81920+0 records out 10737418240 bytes (11 GB, 10 GiB) copied, 17.1058 s, 628 MB/s root@Tower:~#Das ist wirklich mal eine krasse Speed
Ok, für mich ist es damit recht klar dass das Bottleneck die SSDs sind. Sind halt einfach nicht "Pro".
-
Hier mal die Testergebnisse mit count=1G:
root@nas:~# root@nas:~# dd if=/dev/zero of=/mnt/disk1/test.img bs=128K iflag=count_bytes count=1G 8192+0 records in 8192+0 records out 1073741824 bytes (1.1 GB, 1.0 GiB) copied, 0.343877 s, 3.1 GB/s root@nas:~# dd if=/dev/zero of=/mnt/disk1/test.img bs=128K iflag=count_bytes count=1G 8192+0 records in 8192+0 records out 1073741824 bytes (1.1 GB, 1.0 GiB) copied, 5.14304 s, 209 MB/s root@nas:~# dd if=/dev/zero of=/mnt/disk1/test.img bs=128K iflag=count_bytes count=1G 8192+0 records in 8192+0 records out 1073741824 bytes (1.1 GB, 1.0 GiB) copied, 5.08903 s, 211 MB/s root@nas:~# dd if=/dev/zero of=/mnt/disk1/test.img bs=128K iflag=count_bytes count=1G 8192+0 records in 8192+0 records out 1073741824 bytes (1.1 GB, 1.0 GiB) copied, 5.13674 s, 209 MB/s root@nas:~# dd if=/dev/zero of=/mnt/disk1/test.img bs=128K iflag=count_bytes count=1G 8192+0 records in 8192+0 records out 1073741824 bytes (1.1 GB, 1.0 GiB) copied, 5.10374 s, 210 MB/s root@nas:~# dd if=/dev/zero of=/mnt/disk2/test.img bs=128K iflag=count_bytes count=1G 8192+0 records in 8192+0 records out 1073741824 bytes (1.1 GB, 1.0 GiB) copied, 0.346902 s, 3.1 GB/s root@nas:~# dd if=/dev/zero of=/mnt/disk2/test.img bs=128K iflag=count_bytes count=1G 8192+0 records in 8192+0 records out 1073741824 bytes (1.1 GB, 1.0 GiB) copied, 5.02571 s, 214 MB/s root@nas:~# dd if=/dev/zero of=/mnt/disk2/test.img bs=128K iflag=count_bytes count=1G 8192+0 records in 8192+0 records out 1073741824 bytes (1.1 GB, 1.0 GiB) copied, 6.11291 s, 176 MB/s root@nas:~# dd if=/dev/zero of=/mnt/disk2/test.img bs=128K iflag=count_bytes count=1G 8192+0 records in 8192+0 records out 1073741824 bytes (1.1 GB, 1.0 GiB) copied, 5.89215 s, 182 MB/s root@nas:~# dd if=/dev/zero of=/mnt/disk2/test.img bs=128K iflag=count_bytes count=1G 8192+0 records in 8192+0 records out 1073741824 bytes (1.1 GB, 1.0 GiB) copied, 6.09679 s, 176 MB/s root@nas:~# dd if=/dev/zero of=/mnt/disk3/test.img bs=128K iflag=count_bytes count=1G 8192+0 records in 8192+0 records out 1073741824 bytes (1.1 GB, 1.0 GiB) copied, 0.345798 s, 3.1 GB/s root@nas:~# dd if=/dev/zero of=/mnt/disk3/test.img bs=128K iflag=count_bytes count=1G 8192+0 records in 8192+0 records out 1073741824 bytes (1.1 GB, 1.0 GiB) copied, 6.46925 s, 166 MB/s root@nas:~# dd if=/dev/zero of=/mnt/disk3/test.img bs=128K iflag=count_bytes count=1G 8192+0 records in 8192+0 records out 1073741824 bytes (1.1 GB, 1.0 GiB) copied, 7.11701 s, 151 MB/s root@nas:~# dd if=/dev/zero of=/mnt/disk3/test.img bs=128K iflag=count_bytes count=1G 8192+0 records in 8192+0 records out 1073741824 bytes (1.1 GB, 1.0 GiB) copied, 7.30008 s, 147 MB/s root@nas:~# dd if=/dev/zero of=/mnt/disk3/test.img bs=128K iflag=count_bytes count=1G 8192+0 records in 8192+0 records out 1073741824 bytes (1.1 GB, 1.0 GiB) copied, 7.30834 s, 147 MB/s root@nas:~# dd if=/dev/zero of=/mnt/disk3/test.img bs=128K iflag=count_bytes count=1G 8192+0 records in 8192+0 records out 1073741824 bytes (1.1 GB, 1.0 GiB) copied, 7.80251 s, 138 MB/s root@nas:~#Dabei ist mir nun aufgefallen dass die Performance mit jedem Test abnimmt, ist richtig schön zu sehen. dazu kommt dass ich all meine Tests mit den Disks stets in der gleichen Reihenfolge durchgeführt habe, also erst disk1, dann disk2 und zuletzt disk3.
Also nochmal alle Files gelöscht, 10min pausiert, und gleich mal mit disk3 gestartet:
root@nas:~# rm /mnt/disk1/test.img root@nas:~# rm /mnt/disk2/test.img root@nas:~# rm /mnt/disk3/test.img root@nas:~# dd if=/dev/zero of=/mnt/disk3/test.img bs=128K iflag=count_bytes count=1G 8192+0 records in 8192+0 records out 1073741824 bytes (1.1 GB, 1.0 GiB) copied, 0.3305 s, 3.2 GB/s root@nas:~# dd if=/dev/zero of=/mnt/disk3/test.img bs=128K iflag=count_bytes count=1G 8192+0 records in 8192+0 records out 1073741824 bytes (1.1 GB, 1.0 GiB) copied, 5.01092 s, 214 MB/s root@nas:~# dd if=/dev/zero of=/mnt/disk3/test.img bs=128K iflag=count_bytes count=1G 8192+0 records in 8192+0 records out 1073741824 bytes (1.1 GB, 1.0 GiB) copied, 4.89985 s, 219 MB/s root@nas:~# dd if=/dev/zero of=/mnt/disk3/test.img bs=128K iflag=count_bytes count=1G 8192+0 records in 8192+0 records out 1073741824 bytes (1.1 GB, 1.0 GiB) copied, 5.2154 s, 206 MB/s root@nas:~# dd if=/dev/zero of=/mnt/disk3/test.img bs=128K iflag=count_bytes count=1G 8192+0 records in 8192+0 records out 1073741824 bytes (1.1 GB, 1.0 GiB) copied, 5.14711 s, 209 MB/s root@nas:~# dd if=/dev/zero of=/mnt/disk3/test.img bs=128K iflag=count_bytes count=1G 8192+0 records in 8192+0 records out 1073741824 bytes (1.1 GB, 1.0 GiB) copied, 5.19081 s, 207 MB/s root@nas:~#und mit count=10G:
root@nas:~# rm /mnt/disk3/test.img root@nas:~# dd if=/dev/zero of=/mnt/disk3/test.img bs=128K iflag=count_bytes count=10G 81920+0 records in 81920+0 records out 10737418240 bytes (11 GB, 10 GiB) copied, 48.3488 s, 222 MB/s root@nas:~# dd if=/dev/zero of=/mnt/disk3/test.img bs=128K iflag=count_bytes count=10G 81920+0 records in 81920+0 records out 10737418240 bytes (11 GB, 10 GiB) copied, 124.092 s, 86.5 MB/s root@nas:~# dd if=/dev/zero of=/mnt/disk3/test.img bs=128K iflag=count_bytes count=10G 81920+0 records in 81920+0 records out 10737418240 bytes (11 GB, 10 GiB) copied, 51.329 s, 209 MB/s root@nas:~# dd if=/dev/zero of=/mnt/disk3/test.img bs=128K iflag=count_bytes count=10G 81920+0 records in 81920+0 records out 10737418240 bytes (11 GB, 10 GiB) copied, 51.551 s, 208 MB/s root@nas:~#Daraus schlussfolgere ich, das es nicht an einer spezifischen SSD liegt (also z.b. die disk3 irgendein Problem hat), aber wie du sagst @mgutt entweder mit den Lasttest eine Komponente heisser (und dadurch unperfomanter) wird, oder irgend eine grundsätzliche SSD-integrierte Logik (wahrscheinlich auf der Parity SSD) zur Verlangsamung führt.
Die eklatanten einzelnen Aussreisser nach unten auf <50MB/s kann ich mir nach wie vor nicht erklären... eventuell läuft hier auch noch irgendein andere Operation auf den SSDs die mir dazwischenfunkt.
Rein von den Temperaturen der SSDs steigen diese auf um die 50-55 Grad an sobald ich ausgiebig teste. Deinen Tip mit dem Lüfter werde ich mal ausprobieren
Zudem habe ich auch noch 2 Stück 1TB Samsung 850 Pro SSD, diese werde ich mal zu einem Vergleich einbauen und testen.
Ich denke wenn Lüfter- und ProSSD-Tests vorliegen, dann sehen wir wohin der Hase läuft
Danke auf jeden Fall schon mal @mgutt für deine Tips!
-
Nach einigen weiteren Tests mit sowohl dem Marvell als auch dem ASM Controller habe ich festgestellt, das meine ersten Tests mit dem Marvell Controller wohl nicht ausreichend waren.
Mit dem Befehl
dd if=/dev/zero of=/mnt/disk1/test.img bs=128K iflag=count_bytes count=10Gteste ich ja lediglich die Performance der ersten Disk im Zusammenspiel mit der Parity, nicht aber die der anderen Disks. In meinem Fall hängt diese disk1 und auch die Parity-Disk am SATA Controller des Mainboards, d.h. der Erweiterung-Controller war hier überhaupt nicht involviert🤦♂️ Habe ich das soweit richtig verstanden?
Also habe ich den Test mal mit jeder Disk durchgeführt:
Die Disks am Mainboard Controller (disk1 und disk2) hatten durchweg ca. 170-200MB/s.
Die Disk am Marvell Controller (disk3) bot lediglich knapp 50MB/s.
Ein Austausch des Controllers auf den ASM1166 (PCI4x) erbrachte auch für diese Disk dann ebenfalls ca. 170-200MB/s:
root@nas:~# dd if=/dev/zero of=/mnt/disk1/test.img bs=128K iflag=count_bytes count=10G 81920+0 records in 81920+0 records out 10737418240 bytes (11 GB, 10 GiB) copied, 52.4511 s, 205 MB/s root@nas:~# dd if=/dev/zero of=/mnt/disk2/test.img bs=128K iflag=count_bytes count=10G 81920+0 records in 81920+0 records out 10737418240 bytes (11 GB, 10 GiB) copied, 62.3242 s, 172 MB/s root@nas:~# dd if=/dev/zero of=/mnt/disk3/test.img bs=128K iflag=count_bytes count=10G 81920+0 records in 81920+0 records out 10737418240 bytes (11 GB, 10 GiB) copied, 58.6474 s, 183 MB/sIch vermute nun mal dass dies schlicht die Grenze der kleinen Evo SSDs ist wie von dir @mgutt angesprochen.
Was mich noch ein wenig verwundert: Wenn ich den Test mit der disk3 ein paar mal wiederhole (das ist die Disk am Erweiterungs-Controller), dann sind hier ab und zu (so ca. bei jedem fünften Mal) erhebliche Performance Einbrüche nach unten festzustellen:
root@nas:~# dd if=/dev/zero of=/mnt/disk3/test.img bs=128K iflag=count_bytes count=10G 81920+0 records in 81920+0 records out 10737418240 bytes (11 GB, 10 GiB) copied, 265.577 s, 40.4 MB/sDies ist mir bei den anderen disk1 und disk2 am Mainboard nicht aufgefallen. Diese schwanken immer zwischen 150 und 200 MB/s.
Gibts für den eklatanten Einbruch eventuell eine Erklärung oder eine Idee wie ich der Ursache auf den Grund kommen könnte?
-
I think this could even help when using nextcloud and its "preview generation" for videos/photos (which I am already using). The longer I think about it the more I tend towards the i5
-
1
-
-
good point, currently I don't need HW transcoding, maybe in future... I will keep that in mind.
-
Hi,
For my "new" Unraid server I have the choice between the following CPUs / Hardware:
i7-4790 in a Dell Precicion T1700
i5-7500 in a Dell Optiplex 3050
The i7 comes with hyper threading (8 vs 4 cores), the i5 is much more newer and supports a higher ram speed.
I am using no classic VMs, but Docker containers (about 15).
Which CPU would you prefer and why?
-
Ich probiere den Controller einfach mal aus
Danke @mgutt für deine Ausführungen 👍
-
@mgutt der SLC Cache liegt bei 3GB... inwiefern das viel oder wenig ist: Keine Ahnung
Glaubst du denn das ein SATA-Controller Upgrade trotzdem auf https://www.amazon.de/dp/B08F56WKW7/ref=pe_27091401_487024491_TE_item lohnt? Das wäre dann der besagte ASM1166 PCI4x Controller. Oder kann ich mir das Geld sparen?
ZFS compression on, but disk usage is same?!
in General Support
Posted
ok just in case someone encounters the same "problem", I now use a user script and run it in the background:
rsync -av /mnt/disks/backup/* /mnt/user/backup/
seems to work so far as expected.