Date: Sat, 2 Sep 2023 22:11:42 +0200 (CEST) From: Wojciech Puchar <wojtek@puchar.net> To: Wei Hu <weh@microsoft.com> Cc: Guido Falsi <mad@madpilot.net>, Mikhail Zakharov <zmey20000@yahoo.com>, "freebsd-hackers@freebsd.org" <freebsd-hackers@freebsd.org> Subject: RE: Very slow scp performance comparing to Linux Message-ID: <d77491c9-fe6e-22b0-ca7a-d17d1a5345c6@puchar.net> In-Reply-To: <SI2P153MB04418D609BBB9184FD7FFC4ABBE7A@SI2P153MB0441.APCP153.PROD.OUTLOOK.COM> References: <SI2P153MB0441858EC3FE24D5B7A6B34DBBE0A@SI2P153MB0441.APCP153.PROD.OUTLOOK.COM> <6952b7fd-f90f-2677-1997-d0c708cb559e@yahoo.com> <SI2P153MB04412D004F9930203B04A032BBE0A@SI2P153MB0441.APCP153.PROD.OUTLOOK.COM> <455dc69a-dd15-18d9-8e93-91bbff3997e4@madpilot.net> <SI2P153MB04418D609BBB9184FD7FFC4ABBE7A@SI2P153MB0441.APCP153.PROD.OUTLOOK.COM>
next in thread | previous in thread | raw e-mail | index | archive | help
> The throughput on FreeBSD went up significantly from 50 MB/s to 630 MB/s with > NIC interface. Linux went up modestly form 550 MB/s to 660 MB/s. > > So, looks in the non-tmpfs case, the Linux ext4 filesystem does cache large amounts > of data in memory, much larger than FreeBSD ufs. > linux filesystem caching is just stupid, optimized to show up good in benchmarks. It just accepts writes as long as there is available memory, without writing anything to disk, then if it cannot do it anymore or some time passed, schedules huge amount of writes, often stalling whole system. This is how it was almost 20 years ago when i was still using linux, seems like didn't change much. Just think how much data loss and inconsistency would occur if there will be crash or power loss after "writing" 100000 files of 10GB which can easily be done in short time as linux just doesn't block writing process at all and fill memory. Since i started using FreeBSD UFS, many machines, lighter of heavier workload, always mixed workload, i never ever have more that a few files loss on power outage.
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?d77491c9-fe6e-22b0-ca7a-d17d1a5345c6>