Hello, For the ease of testing and reproduction we use fio and iozone benchmarking tools. The issue you desrcibe looks pretty similar. However it occurs using GPFS mount only. Here are some results from out testing environment:
Linux NSD server: Writes: 3472 MiB/s Re-writes: 3476 MiB/s Windows GPFS: Writes: 2487 MiB/s Re-writes: 250 MiB/s Windows Samba: Writes: 997 MiB/s Re-writes: 1269 MiB/s -- S přáním pěkného dne / Best regards Mgr. Peter Hruška IT specialista M Computers s.r.o. Úlehlova 3100/10, 628 00 Brno-Líšeň (mapa<https://mapy.cz/s/gafufehufe>) T:+420 515 538 136 E: peter.hru...@mcomputers.cz<mailto:peter.hru...@mcomputers.cz> www.mcomputers.cz<http://www.mcomputers.cz/> www.lenovoshop.cz<http://www.lenovoshop.cz/> [cid:a57a2d9ed2ea460d8bb2abefe678c4fab3cdaeeb.camel@mcomputers.cz-0] On Mon, 2024-03-11 at 17:35 +0000, Jonathan Buzzard wrote: EXTERNÍ ODESÍLATEL On 11/03/2024 16:43, Peter Hruška wrote: Hello, We've encountered yet another performance flaw. We have a GPFS filesystem mounted using GPFS binaries on Windows. When we try to rewrite a file on the GPFS filesystem rewriting speed is much slower than writing to a new file. The difference ratio we measured is about 3.5 times. From the task manager it is visible that there is excessive amount of reading from the network when rewriting. This is even visible on the NDS server as io activity. However when rewriting on a linux client there are no reads while rewriting. Has anyone encountered such problems? To replicate the issue is is possidle to run fio twice with the same configuration to achieve rewriting or to run iozone. Both tools return similar outputs. Kind of yes. What are you using to "rewrite" the file? What we saw initially over Samba was certain Microsoft applications when rewriting a file had truly abysmal performance. The same application when saving the same document to a new file and the performance was as expected. After much digging into it the cause (it was weeks of person effort) it was determined to be down to the application writing the file *one* byte at a time. Basically some idiot C++ developer at Microsoft decided to ignore the C++ library because it has "bugs" and write their own formatted output routines. It was not noticeable saving to a local disk, but the instant you tried saving to a network drive the performance was truly awful. Basically the increased latency of single character IO was the issue. Note that the issue was not confined to Samba and GPFS, as we verified the same abysmal performance with a Windows 2008 R2 server running on File and Print Sharing on NTFS on bare metal hardware. It was also not confined to just Windows the same awful performance happened on Macs too. In fact that is where it first came to light. Might be the cause of your problem, might not. JAB. -- Jonathan A. Buzzard Tel: +44141-5483420 HPC System Administrator, ARCHIE-WeSt. University of Strathclyde, John Anderson Building, Glasgow. G4 0NG _______________________________________________ gpfsug-discuss mailing list gpfsug-discuss at gpfsug.org http://gpfsug.org/mailman/listinfo/gpfsug-discuss_gpfsug.org
_______________________________________________ gpfsug-discuss mailing list gpfsug-discuss at gpfsug.org http://gpfsug.org/mailman/listinfo/gpfsug-discuss_gpfsug.org
