Difference between revisions of "Performance tuning"

Jump to navigation Jump to search
590 bytes removed ,  23:25, 6 September 2015
m
ShAkE is incompatible with ZFS
m (Warn about single disk RAID 0 arrays)
m (ShAkE is incompatible with ZFS)
Line 155: Line 155:
The first method is to configure your client to download the files to a temporary directory and then copy them into their final location when the downloads are finished, provided that your client supports this.
The first method is to configure your client to download the files to a temporary directory and then copy them into their final location when the downloads are finished, provided that your client supports this.


The second method is to use the [http://vleu.net/shake/ ShAkE] tool to perform defragmentation by rewriting the files sequentially. Integrity verification should be done after running ShAkE to ensure that the file contents are identical to what they were before running ShAkE. Those using the ShAkE tool should be aware that ShAkE works by triggering copy on write for the entire file, which will cause files stored in snapshots to be stored twice. This can be exploited for verification purposes by calculating md5/sha1/sha256 checksums and comparing, but it is not otherwise desirable. Alternatively, verification can be performed with the bit torrent protocol.
The second method is to use send/recv to recreate a dataset sequentially.


In practice, defragmenting files obtained through bit torrent should only improve performance when the files are stored on magnetic storage and are subject to significant sequential read workloads after creation.
In practice, defragmenting files obtained through bit torrent should only improve performance when the files are stored on magnetic storage and are subject to significant sequential read workloads after creation.
Editor
348

edits

Navigation menu