Activity for Franco Corbelli
-
Franco Corbelli posted a comment on discussion Open Discussion
After a bit of digging, and using -w/tmp/, I get this Error: cannot move the file /tmp/aserver_nooo.zip.tmp /monta/nexes_sei_aserver6/zip/aserver_nooo.zip Operation not permitted System ERROR: Unknown error: -2147024895
-
After switching from a Solaris-based NAS to a FreeBSD one, I get a strange beahyviour The NFS share is mounted as /monta/nexes_sei_aserver6 It is writeable root@aserver:/monta/nexes_sei_aserver6/zip # echo "ciao" >prova.txt root@aserver:/monta/nexes_sei_aserver6/zip # cat prova.txt ciao There is a squash-to-user utente When I try to write on a .zip file, like this root@aserver:/monta/nexes_sei_aserver6/zip # /usr/local/bin/7z a -tzip -mx1 /monta/nexes_sei_aserver6/zip/prova /etc 7-Zip [64] 16.02...
-
BTW: thoroughly testing the restorability of an archive is very different from simply testing it. It presupposes writing to a real filesystem (to check the charset and length, for example) and then comparing file hashes', or whatever. 7-zip is a (very good) archiver, not a backup program, nor do I think it wants to be. For a paranoid++ level you use a different operating system, a different filesystem, a different CPU, and a different compiler (!) and a 3rd-party software to double check (!!). But,...
-
Indeed, corrupted archives can happen, even for subtle bugs, for individual configuration (e.g., the terrifying fake Windows Server files, rather than the "fake video game files" of desktop versions), hardware errors etc. I personally get one such a "strange" case ...where... I threw in the towel. I have not been able to figure out why. In my specific case I adopt paranoid++ level verification strategies, but I am aware that for those who do not do my job they are essentially excessive. The very...
-
Here writing a 100GB container file (just to get an idea) @ 2.2GB/s on NVMe, by VeraCrypt I also tried to disable multithreading, for some kind of hypothetical race condition (the CPU has 32 logical cores), with no effect On the CPU-side the slowest (Kuznyechik(Serpent(Camellia)) runs at about 1.3GB/s AES 29GB/s, Twofish 5.9GB/s (50MB blocks) Does not seems a CPU related issue
-
Here the "plain" drive
-
In the attached images - NON encrypted write speed (from ramdisk) is ~2.2GB/s - VeraCrypt encrypted, after the "cache spike", goes to ~70MB/s - VeraCrypt, during the encryption process, writes at ~2GB/s Short version: on SSD 500MB/s, on NVMe 70MB/s, very same PC, testbed etc It is rather strange
-
Thanks for the answer I am a very seasoned disk encryption user (10+ years) I do not use antivirus of any kind, etc. No Defender at all I have numerous other machines with TrueCrypt, on which the problem recurs in the same way (SSD, HDD OK, NVMe KO), different CPU (Intel/AMD), different chipset, different "everything". I have read numerous reports of poor performance on NVMe with VeraCrypt, so I suppose it is a really existing problem Precisely in order to exclude any kind of hypothetical software...
-
Thank you, now it is clear But I DO NOT use Microsoft compilers, at all Never, ever :) I'll try a gcc port in my next release The difference is small, but interesting just for fun
-
This is the "HW-accelerated" SHA1 introduced in newer 7z, not really sure when (19+? 21+?), not the "plain asm", assembled by asmc64.exe It is just about two times faster than yours C implementation (~1.8GB/s vs ~900MB/s on 5950X) However, since it is (mainly) used to calculate the deduplication rolling hash (therefore with rather high latency) the overall impact (on total archiving time) is more modest, in the order of 10%, compared to a very fast implementation (for this use) by Matt Mahoney Just...
-
Hello, I am the developer of a little zpaq's fork (zpaqfranz) https://github.com/fcorbelli/zpaqfranz I integrated two of yours source code into mine Sha1Opt.asm -- SHA-1 optimized code for SHA-1 x86 hardware instructions ; 2021-03-10 : Igor Pavlov : Public domain ; 7zAsm.asm -- ASM macros ; 2021-02-07 : Igor Pavlov : Public domain https://github.com/fcorbelli/ugo Even if the performance increases very little (maybe 10%), can I use it? I think it is right to ask this explicitly before releasing the...
-
I am experiencing absolutely low write performance on NVMes Windows 10, AMD 5950x, 128GB RAM (ROG CROSSHAIR VIII DARK HERO motherboard) Samsung 980 PRO (2TB), WD SN750 Black and Samsung 860 PRO SSD (to compare), latest firmware Write speed, both on fully encrypted disk and on container file, is in the order of 50-70MB/s on NVMe drives, either configurated (in BIOS) as PCI gen 4 and 3 Standard Microsoft NVMe driver "Normal speed" (uncompressed) well above 1.5GB/s I do not think it is CPU speed issue:...
-
-
-
With some (very useful) help from encode.ru forum https://github.com/fcorbelli/ugo This is a ~350 lines of C (plus a single ASM) that show HW-accelerated SHA-1 hasher (for AMD Ryzen). The next step will be rewrite the .ASM to .S (to avoid asmc). Thanks
-
Thanks for the answer, but how to link the .asm in the Makefile? g++ -DUSE_HW_SHA -O3 ugo.c sha1.c sha1opt.c -o ugo.exe go to In file included from c:\mingw\lib\gcc\x86_64-w64-mingw32\7.3.0\include\immintrin.h:77:0, from sha1opt.c:58: c:\mingw\lib\gcc\x86_64-w64-mingw32\7.3.0\include\shaintrin.h: In function 'void Sha1_UpdateBlocks_HW(UInt32*, const Byte*, size_t)': c:\mingw\lib\gcc\x86_64-w64-mingw32\7.3.0\include\shaintrin.h:53:1: error: inlining failed in call to always_inline '__m128i _mm_sha1nexte_epu32(__m128i,...
-
My previous post is "awaiting moderation", it is Sunday after all. Can you please tell me how to link the .asm code, in fact the "mini Makefile" for SHA1? Thanks
-
Hello, I am trying to compile a trivial "hasher" to calc SHA-1 via HW accelerated instructions (AMD Ryzen). I can get the "soft" version work (brief file attached), but how to compile on Windows (gcc) to enable faster instructions? Thank to all reply
-
-
-
-
-
-
1