[Sammelthread] OpenZFSonWindows: HowTos, Performance, wasauchimmer...

Wenn Du diese Anzeige nicht sehen willst, registriere Dich und/oder logge Dich ein.
Aus noch nicht wirklich von mir nachvollziehbaren Gründen haben mir heute mehre VMs Probleme gemacht, deren VHDX auf ZFSonWin liegen. Bei Problemen mit einer VM denke ich an die VM, bei gleich zweien hakt was "Größeres", vor allem wenn bei beiden Fehler auftauchen, die mit dem Filesystem/Storage in Verbindung stehen (beide mit korrupten Dateisystemen - der Server selbst lief aber die ganze Zeit sauber durch). Ob noch weitere VMs betroffen sind, weiss ich noch nicht.

Nach einem Reboot des Servers waren die ZFS Pools / Datasets zwar im Explorer sichtbar, aber es konnte nicht darauf zugegriffen werden. Nach einem Pool Export/Import ging es wieder, aber eine Windows-VM hängt seitdem in einer "Autorepair" Schleife. Letztes Backup gerade von dieser VM ist natürlich auch schon lange her, also muss ich mal schauen, ob ich die manuell gefixed bekomme.

Ich bin noch auf 2.3.1rc14 unterwegs, zfs version
zfswin-2.3.1rc14
zfs-kmod-zfswin-2.3.1rc14

Ich lass das hier nur mal als abstrakte Warnung da, kann halt evtl. auch was ganz anderes sein.
 
Könnte eventuell daran liegen (Problem mit Win10 vermutlich auch Server 2022 mit MultiCore Systemen)
Fix thread priority BSOD on large multicore systems in KiAddThreadToPrcbQueue, behoben in 2.4.1

Vor Update wird ein uninstall empfohlen

zfs-windows-2.4.1rc9 Latest

** rc9
  • Fix uninstall process. Recommended to remove previous version, reboot, before install rc9
  • Remove UAC requirement
  • Attempt elevation on some commands
  • Add "zfs allow" feature
** rc8
  • Fix thread priority BSOD on large multicore systems in KiAddThreadToPrcbQueue()
  • Correct potential arm64 disk IO race in completion.
  • Speedup dirlisting, avoid memory fragmentation
  • OpenZVOL driver unload fix
  • Fix double free of MDL in write path (CrystalDiskMark)
c3ac00aebfe121b78a7806f608a58e76 *OpenZFSOnWindows-debug-2.4.1rc8.exe

wenn Problem bleibt: Issue erstellen damit das Problem bekannt wird
 
Nervt mich.

Eigentlich trauere ich immer noch beim Storage Solaris 11.4 hinterher und will auch von Hyper-V als Hypervisor weg. Bin eh noch auf Server 2022 und der ist ja nun auch nicht mehr so richtig taufrisch.

Aber ESXi mag ich wegen Lizenzkäse in der Vergangenheit nicht mehr und mit Proxmox bin ich bisher auch noch nicht so richtig warm geworden. Werde aber wohl Proxmox nochmal eine Chance geben…
 
So stabil wie natives Solaris ZFS oder Illumos (kompatibel zu OpenZFS) ist aktuelles OpenZFS beileibe nicht, siehe
github.com

Issues · openzfs/zfs

OpenZFS on Linux and FreeBSD. Contribute to openzfs/zfs development by creating an account on GitHub.
github.com github.com

Soviele offene Probleme hatte Solaris oder Illumos ZFS in 10 Jahren nicht. Dem steht halt entgegen, dass OpenZFS sehr interessante neue Features bringt. Die schnelle Integration dieser Features ist sicher eines der Probleme und der Grund warum OmniOS so stabil ist - ohne allerneueste Features.

Bei Windows kommt dazu, dass es soviele Varianten gibt, im OS, in der Hardware und in der Kombination mit anderen Programmen und Treibern. Diese Vielfalt an Distributionen und Systemen ist auch eines der Probleme von OpenZFS.
 
Ich brauch halt keine besonderen Features, mir reicht Poolerweiterung zur Not mit neuen Platten / vdevs, bisserl Replikation, Komprimierung, ab und an mal Dedup, Verschlüsselung und simpelste SMB/NFS Freigaben. Das gibts alles schon quasi von Anfang an.

Ich will eigentlich nur „läuft“ 24/7 über Jahre hinweg, ohne mich drum kümmern zu müssen. ;)

Hyper-V musste ja schon gefühlt mindestens einmal pro Woche wg. Updates rebooten…
 
Tut einfach, jahrelang. Dafür ist Solaris und Illumos unerreicht.

Dedup2 bei Solaris ist auch ok, bei OmniOS hat man halt nur klassisches Dedup, kein moderneres OpenZFS Fast Dedup. Raid-Z Expansion gibts auch nur bei neuestem OpenZFS, genau wie Hybrid Pools mit special vdev auch für slog, dedup und zvol.
 
besterino schrieb:
Hyper-V musste ja schon gefühlt mindestens einmal pro Woche wg. Updates rebooten…
Zum Vergrößern anklicken....

Windows hat einen Patchday pro Monat (bis auf unerwartetes), bedeutet 12x Neustart pro Jahr.
Windows Server 2025 führt "Hot Patching" ein, soll Neustart auf 4x pro Jahr reduzieren.

Man kann Updates auch verzögern oder aussetzen wenn Windows nur Server ist und kein Desktop mit viel Internet Nutzung.

ps
Wenn man bei Linux auch alle Patches einspielt, sieht das ähnlich aus. Ist ja nicht so, dass es für Linux/Unix keine Security/Bugfixes gibt mit Reboot.
 
besterino schrieb:
Ich will eigentlich nur „läuft“ 24/7 über Jahre hinweg, ohne mich drum kümmern zu müssen. ;)

Hyper-V musste ja schon gefühlt mindestens einmal pro Woche wg. Updates rebooten…
Zum Vergrößern anklicken....
Naja, also mein W2k12 hat ne Uptime, die ich gar nicht kenne.
Warum? Naja, der läuft einfach. Reboots gibt es durch Spannungsausfall beim EVU und das ist sehr selten.
Patchen? Hä?
Also gehen tut das schon. :fresse:

Ansonsten, wenn du 24/7 brauchst, nimm DOS 6.22, das kennt kein Schwein (mehr) und die, die es noch kennen, gehen alle langsam in Rente.
Sonst musst du, wenn man es "richtig" machen will, jedes OS patchen. Linux ist schon seit 20 Jahren kein "läuft immer" System.
Läuft immer ist Mainframe, aber das willst du nicht haben.

Die Software, angefangen beim OS, ist viel zu komplex geworden, als dass die "fertig" ist.
Gab erst letztens wieder irgendso nen Supergau in ner Bibliothek und deswegen die gesamte IT der Welt gepatcht werden muss.
Das gilt btw. auch für Switche. Dein geliebtes Webinterface ist das Hauptgrund, warum man Switche patchen muss.
Das sind aber auch nur noch PCs mit nem angeschlossenen SwitchASIC.
 
Zuletzt bearbeitet:
Immer müsst Ihr mir meine Illusionen kaputt machen! ;)
 
Neuer release candidate 10 for OpenZFS on Windows 2.4.1

github.com

Releases · openzfsonwindows/openzfs

OpenZFS on Linux and FreeBSD. Contribute to openzfsonwindows/openzfs development by creating an account on GitHub.
github.com github.com
github.com

Issues · openzfsonwindows/openzfs

OpenZFS on Linux and FreeBSD. Contribute to openzfsonwindows/openzfs development by creating an account on GitHub.
github.com github.com

** rc10
  • Add FileCompressionInformation to enable query of on-disk compressed size
  • Do some performance fixes to make things faster
  • Hardlink deletion would hide all other hardlinks
  • Fix deadlock in write path
  • Prioritise HarddiskXPartitionY paths over hack path
  • Add import --fix-gpt to correct NumPartitions=9 to NumPartitions=128.
  • Fix up condvar and mutex
  • Use User credentials, enabling zfs allow to work. Mix Unix and Windows permissions and hope for the best
  • OpenZVOL unload bug fixes
  • Fix spl_panic() call print and stack
So with Unix created GPT partitions, they use gpt.NumPartitions=9, this Windows does not accept, and Windows
computes gpt.checksum "as if" gpt.Numpartitions==128. So checksum mismatches, and partition table is ignored.
This is why OpenZFS uses path encoding of #partition_offset#partition_length#/path/to/device, saved into vdev->vdev_physpath.
This continues to work.
We added a new zpool import --fix-gpt which will rewrite gpt.NumPartitions=128, and recompute gpt.checksum. Since libefi already reads in the full GPT partition, we need not change anything else, and write it back out. This is left as a user option, as there could be partition usage I am unaware of. Who know if some legacy archs can only use fewer partitions? Or store microcode in the backhalf.
If GPT is written with gpt.NumPartitions=128, Windows will recognise the partitions, and create //?/HarddiskXPartitionY device objects, so we can import those directly, no need for special path. Success. We prioritise //?/HarddiskXPartitionY over #partition_offset#partition_length#/path/to/device - but it will try both.
Let's check for regression in this release.

Evaluate and report issues
 
Pools sollen ja zwischen Free-BSD, Illumos, Linux/Unix, OSX und Windows verschiebbar sein.
Das hat zur Folge dass sich der Windows OpenZFS Treiber um unterschiedliches Verhalten bei Permissions, Partitionen, Mounts, Locking, Links etc kümmern muss. Alles in ZFS kommt halt ursprünglich aus der Unix/Solaris Welt.

Da es zudem bei Windows viel mehr Variationen in der Hardware, Software und Treiberumgebung als bei Unix gibt, dauert es mit dem Release State unter Windows ja so lange, da immer noch etwas berichtet wird was noch gefixt werden sollte, jedesmal mit der Gefahr dass etwas was schon funktionierte erneut Probleme bereitet. Software lebt halt. OpenZFS selber entwickelt sich auch schnell weiter, 2.4 kann deutlich mehr als 2.3 oder 2.2 und wenn man sich da den Issue Tracker anschaut, ist das auch nicht ohne, sicher der Grund warum Illumos oder Solaris ZFS ohne diese sehr schnellen Weiterentwicklungen so viel stabiler ist.

Das Dateisystem OpenZFS selber unter Windows ist aber schon sehr gut, wegen dem Debug Code noch etwas langsamer, aber da sollte der aktuelle Build bereits etwas besser geworden sein. BlueScreens bei Inkompatibilitäten wie bei frühen Versionen von OpenZFS unter Windows sind sehr selten geworden, sind wegen Copy on Write auch eher unkritisch.
 
OpenZFS 2.4.1 on Windows

https://github.com/openzfsonwindows/openzfs/releases
https://github.com/openzfsonwindows/openzfs/issues


** rc12

a lot of big changes, test calmly

  • fix MountManager confusion from snapshot mounts
  • fix zfs_vss_pool_remove not removing snapshots on pool export
  • zfs_vnops_windows_lib: also filter snapshot DCBs from BusRelations
  • zfs_vnops_windows_lib: exclude snapshot mounts from BusRelations reply
  • zfs_ctldir: return mounted snapshot root vnode from zfsctl_root_lookup
  • icp: fix AVX2-VAES GCM path for both kernel and userland on Windows
  • icp/simd: add VAES and VPCLMULQDQ runtime detection, enable AVX2-VAES GCM path
  • icp: restore ASMABI on aesni_gcm_encrypt/decrypt declarations
  • zfs_windows_unmount: rmdir reparse-point directory after deletion
  • zfs_windows_unmount: clear DCB mounted_on before DeleteReparsePoint
  • zfs_vnops_windows_lib: fix FileStandardInformation size for ADS
  • wosix_open: strip trailing backslash from paths
  • posix/zutil: fix zpool import -d . from UNC CWD
  • zfs_vnops_windows: fix FileStreamInformation for directories
  • zfs_vnops_windows: fix fsutil fsinfo volumeinfo storage IOCTL failures
  • zfs_vnops_windows: advertise FILE_SUPPORTS_BLOCK_REFCOUNTING when feature is enabled
  • zfs_vnops_windows: implement FileLinkInformationEx support
  • zfs_vnops_windows: fix git clone (pack file corruption + unlink failure)
  • zfs_vnops_windows: implement FSCTL_OFFLOAD_READ and FSCTL_OFFLOAD_WRITE
  • zfs_vss/vfsops/vnops: fix three BSODs in VSS snapshot path
 
OpenZFS on Windows 2.4.1rc14

** rc14
  • Pageout write stalls in rangelock
  • panic exceptions were masked
  • Unmount fixes, cause finally known of poor unmount
  • Change condvar to be posix compliant in mutex_exit -> cv_broadcast cases
  • Setting mountpoint would compute wrong path

    Issues:
    github.com

    Update 2.4.1 rc13 to rc14 · Issue #619 · openzfsonwindows/openzfs

    Update rc13-> rc14: error during reboot: BSOD -> Driver Power State failure memory.dmp https://drive.google.com/file/d/1FPoqVPIrik5xHm56rpFx4TNDfpYj55oo/view?usp=sharing after reboot PS C:\Users\me...
    github.com github.com

btw
OpenZFS on OSX 2.4.1 has released state, not a release candidate
 
OpenZFS for Windows 2.4.1 rc15

github.com

Release zfs-windows-2.4.1rc15 · openzfsonwindows/openzfs

** rc15 Fixed a BSOD (MEMORY_MANAGEMENT) that could occur running .exe files directly from a ZFS volume, caused by a Valid Data Length race during cached writes. Fixed data corruption during large...
github.com github.com
github.com

Issues · openzfsonwindows/openzfs

OpenZFS on Linux and FreeBSD. Contribute to openzfsonwindows/openzfs development by creating an account on GitHub.
github.com github.com

** rc15

  • Fixed a BSOD (MEMORY_MANAGEMENT) that could occur running .exe files directly from a ZFS volume, caused by a Valid
    Data Length race during cached writes.
  • Fixed data corruption during large downloads to a ZFS volume (e.g. LM Studio model downloads) —
    FSCTL_QUERY_FILE_REGIONS was reporting invalid data regions incorrectly, and several related races/deadlocks in the
    cached-write fast path (fastio_write) under concurrent writers have been fixed.
  • Fixed a second, related MEMORY_MANAGEMENT BSOD that could occur when a file was reopened while another handle
    already had it memory-mapped.
  • Fixed filenames being mangled to the wrong case when a pool is mounted to a folder (reparse point) instead of a
    drive letter.
  • Fixed pool mount failures when Driver Verifier is enabled.
  • Fixed partition number (dki_partition) always reporting 0 on Windows.
  • Healed pre-existing non-power-of-2 block sizes that could otherwise cause issues when a file's block size grows.
  • Fixed several bugs in zfsinstaller found during code review.
  • Fix BSOD in shani benchmark at boot
 
OpenZFS on Windows 2.4.1rc16

Ich habe den Eindruck dass die letzten Neuheiten wie VSS
Probleme bereiten, Jorgen Lundman ist aber ultra schnell am Fixen:
Vielleicht liegts auch nur daran, dass immer mehr ZFS auf Windows testen und dann
Probleme mit besonderen Setups oder Programmen auftauchen.

** rc16
  • Fixed a deadlock that could hang the system running VeraCrypt (or anything else doing large
    cached writes) on a ZFS volume — the Cache Manager's write-behind flush and the app's own
    cached write could end up waiting on each other forever.
  • Fixed a BSOD (PFN_LIST_CORRUPT) creating a VHD/VHDX file on a ZFS volume, caused by an invalid
    lock attempt on a kernel-mode write buffer (seen with vhdmp.sys).
  • Fixed mounting a pool read-only (e.g. force-imported after an unclean export) crashing instead
    of mounting.
  • Fixed renaming a file, or deleting via the Recycle Bin, spuriously reporting failure even
    though the operation actually succeeded.
  • Fixed a hang deleting files while another handle still had them open, caused by
    CcPurgeCacheSection blocking indefinitely (LM Studio downloads and others).
  • Fixed files getting permanently stuck reporting "access denied" on delete under fast
    open/close churn (seen with FreeFileSync's lock files).
  • Fixed two related memory-mapping BSODs (MEMORY_MANAGEMENT): one writing near the end of a file
    opened for append, one via FSCTL_OFFLOAD_WRITE.
  • Fixed a hang truncating a file while a concurrent write to the same file was flushing.
  • Fixed a file's on-disk size not being persisted correctly for some paging writes, which could
    revert a file to 0 bytes after a crash.
  • Fixed unbounded ARC growth: the ARC now actually caps itself around a third of system memory
    as documented, and proactively reclaims idle vnodes and returns freed memory to the OS instead
    of holding onto it indefinitely.
  • Fixed a crash in the Windows performance-counter (PCW) provider when a pool was mid-import or
    mid-export.
  • Fixed a crash in zed/event handling caused by resolving the wrong internal file handle.
  • Fixed IOCTL_VOLUME_GET_VOLUME_DISK_EXTENTS reporting the wrong extent length.
  • Fixed a rare crash reading files with a corrupted/zero block size.
  • Fixed write/read errors (out of space, I/O error) being silently reported back as success.
  • Fixed a crash (VERIFY panic) on a short/truncated read, e.g. during zfs receive.
  • Fixed IRPs occasionally completing with an invalid internal status in rare error paths.
  • Fixed ZVOLs not honoring SCSI Force Unit Access (FUA) — writes requiring guaranteed durability
    weren't actually being synced.
  • Fixed ZVOL disk-cache flush (SYNCHRONIZE CACHE) never actually reaching the underlying disk —
    data could be lost on power failure. Also fixed a related crash when write-caching was disabled
    on a ZVOL.
  • Fixed ZVOL writes being logged to the ZIL at the wrong offset, which could corrupt data during
    crash recovery. Also fixed ZVOL read/write throughput statistics always reporting 0.
 
Es gibt noch Probleme mit einzelnen Windows Programmen,
die werden aber immer spezieller...

zfs-windows-2.4.1rc17b
github.com

Release zfs-windows-2.4.1rc17b · openzfsonwindows/openzfs

** rc17b Delete via recycle.bin can stop unmount/exports. zget attach could cpubusy loop on rare race overwrite/truncate would fail to do so correctly show mount flags (readonly etc) in userlan...
github.com github.com

Issues
github.com

Issues · openzfsonwindows/openzfs

OpenZFS on Linux and FreeBSD. Contribute to openzfsonwindows/openzfs development by creating an account on GitHub.
github.com github.com

rc17b
  • Delete via recycle.bin can stop unmount/exports.


  • zget attach could cpubusy loop on rare race
  • overwrite/truncate would fail to do so
  • correctly show mount flags (readonly etc) in userland
  • skip updating EA when existing
  • wire atime for Windows
  • zfs_tray cosmetic fixes
  • spl: fix memory eviction, stop lying about available memory

Hoping this is the last 2.4.1 version, moving us up to 2.4.4 to match macOS port.
 
OpenZFS for Windows 2.4.4 rc1

github.com

Releases · openzfsonwindows/openzfs

OpenZFS on Linux and FreeBSD. Contribute to openzfsonwindows/openzfs development by creating an account on GitHub.
github.com github.com
github.com

Issues · openzfsonwindows/openzfs

OpenZFS on Linux and FreeBSD. Contribute to openzfsonwindows/openzfs development by creating an account on GitHub.
github.com github.com

These are the changes from upstream 2.4.1 to 2.4.4

L2ARC — substantial rework

  • DWPD-based rate limiting with adaptive feed intervals (protects SSD endurance)
  • Per-device parallel feed threads (was single-threaded feed)
  • Persistent markers with consistent tail scanning + lazy reset flags + scan-based depth cap
  • Even-depth multi-sublist scanning, write budget fairness (metadata no longer monopolizes)
  • Rebuild bounded by write hand on first sweep; fixed a prev_hdr use-after-free

Performance


  • Predict and throttle buffers dirtied by the sync context
  • Batch object reallocation syncs in zfs receive
  • Parallelize metaslab_sync_done(), dedup block cloning, and brt_pending_apply() across vdevs
  • RAIDZ: optimize single data column writes; avoid extra abd_t allocations in RAIDZ/dRAID
  • Bridge speculative and prescient prefetchers; bound user prefetch to a fraction of ARC

New features / CLI


  • zpool condense — new verb
  • zpool scrub -t — thorough scrub support
  • zfs bookmark -r — recursive bookmark creation
  • zpool initialize -z — write zeroes
  • New dedupused/dedupsaved pool properties
  • zoned_uid property (Linux container/namespace delegation — not applicable to us)
  • FIDEDUPERANGE via block cloning
  • zstream: major rework — multithreaded, new raw/drop_record/queue subcommands, memory tracking

Data-integrity fixes (the ones that matter most)


  • Fix read corruption after block-clone-after-truncate
  • Fix double free for blocks cloned after DDT prune
  • draid: fix data corruption after disk clear; fix checksum errors after rebuild with degraded disks; fix import
    failure after disk replacement
  • Prevent range-tree corruption race in dnode_sync()
  • z_seq now persists across znode eviction — fixes the VMware ESXi-over-NFS "file specified is not a virtual disk" bug
    (Linux/FreeBSD only for now, per our earlier gap analysis)
  • DDT: multiple pruning bugs fixed (including negative time overflow)
  • Fix off-by-one in PREVIOUSLY_REDACTED handling that dropped the last block

Security hardening


  • vdev_open/zfs_file_open/vdev_file/vdev_disk: now check the calling credential instead of always using kcred (we
    ported the Windows side of this yesterday)
  • Additional verification of size fields and strings in the receive path
  • Hardened receive record validation
  • secpolicy_nfs removed; secpolicy_zinject/secpolicy_sys_config restricted to global-zone credentials

Deadlock/hang fixes


  • Fix deadlock on dmu_tx_assign() from vdev_rebuild()
  • Fix snapshot automount deadlock during concurrent zfs recv
  • Fix self-deadlock setting the vdev allocating/path property
  • Fix race between device-removal completion and pool export
  • zfs_ioctl: fix EBUSY race between quota queries and mount (we ported this too)
  • arc: fix race between arc_release() and arc_read_done()

OpenZFS on Windows

  • Add zpool create and zpool destroy to zfs_tray
 
OpenZFS for Windows 2.4.4 rc3
Immer wieder erfreulich, wie schnell es vom Issue Report eines Problems bis zum Fix geht

*** rc3
  • Fix regression in sa_remove_attrs causing BSOD

*** rc2
  • Fix zpool create
    Fixing execve attempted to run zfs_prepare_disk script, which fails on Windows
    Add zfs_prepare_disk.ps1 for Windows

*** rc1

You need to delete (or rename) C:\Program Files\OpenZFS on Windows\zfs_prepare_disk if you want to be able to create pools.
 
Ich finds irgendwie schade, dass es immer noch so viele Fixes braucht…
 
Sind halt zwei Sachen

- OpenZFS bleibt nicht stehen. Der Sprung von 2.4.1 zu 2.4.4 hat eine Menge neue Sachen gebracht und benötigt neue Anpassungen.

- Es gibt eine ganze Reihe von Programmen die mit "Nicht Windows" Volumes Probleme machen,
die aktuellen Fixes sind überwiegen rund um einzelne Programme. Je mehr Leute OpenZFS nutzen, desto mehr Programme werden entdeckt, die noch Probleme bereiten. Windows und Unix unterscheiden sich bei Storage halt doch arg unter der Haube.

Solange immer noch Windows Probleme gefunden werden, bleibts ein Release Candidate und selbst danach eine Baustelle, dann halt eher bei OpenZFS. Ist ja nicht so, dass OpenZFS keine Probleme hat und nur der Windows Port das Problem ist, der Issue Tracker bei OpenZFS ist um einiges länger als der der zusätzliche Issues Tracker der extra Probleme unter Windows beschreibt, https://github.com/openzfs/zfs/issues.

Die Wahrscheinlichkeit eines Datenverlusts unter Windows ZFS ist gering und die Wahrscheinlichkeit dass OpenZFS unter Windows gut funktioniert bereits sehr hoch, höher als mit anderen modernen Unix Dateisystemen unter Windows wie btrfs. Wenn einzelne Programme noch Probleme machen, kann man einen Issue Report machen damit das behoben wird oder die eben weiter auf ntfs/ReFS laufen lassen.

OpenZFS unter OSX z.B. ist seit geraumer Zeit released, da ist aber auch Unix darunter, es gibt viel weniger Treiber und Hardwareoptionen und nicht die schiere Masse von Programmen die aus ntfs oder ReFS das letzte Quentchen Performance herausholen wollen.

Bis dahin gilt, ZFS testen - nutzen wenns gut läuft mit den eigenen Programmen und der eigenen Hardware (kann ja unglaublich viel mehr als ntfs/ReFS) und Issue Reports schreiben wenn man ein Problem findet.

Zuletzt ist es ja auch nicht so, dass ReFS oder ntfs problemfrei sind, vermutlich ist die Wahrscheinlichkeit eines Datenverlusts unter ntfs höher als unter OpenZFS for Windows z.B. nach einem Absturz beim Schreiben.
 
Anmelden, um zu antworten.
Hardwareluxx setzt keine externen Werbe- und Tracking-Cookies ein. Auf unserer Webseite finden Sie nur noch Cookies nach berechtigtem Interesse (Art. 6 Abs. 1 Satz 1 lit. f DSGVO) oder eigene funktionelle Cookies. Durch die Nutzung unserer Webseite erklären Sie sich damit einverstanden, dass wir diese Cookies setzen. Mehr Informationen und Möglichkeiten zur Einstellung unserer Cookies finden Sie in unserer Datenschutzerklärung.


Zurück
Oben Unten refresh