Raspberry Pi 4 Real World Tests

The Raspberry Pi 4 was launched on 24th June and has been well received, to say the least. The spec is a big step up on previous models. It has 4 CPU cores like the Pi 2, a gigabit port like the Pi 3, plus USB 3, a better SoC, a separated bus architecture, faster memory and more of it.

Over the years, many “home” devices have been launched with Gigabit Ethernet, promising lightning fast network speeds, only to disappoint due to their lack of overall grunt. The Linkstation Live, the Sheevaplug and, to a lesser extent the Pi 3 are all on that category, unable to push their gigabit ports to more than about 14, 8 and 12 megabytes/sec respectively, due to the limitations of the CPU and the board. Is the Pi 4 the same, or can it operate as a serious NAS ?

Short answer: Yes. The Pi 4 is a *serious* NAS contender. Sustained write speeds of over 68 MB/s were obtained, and over 105 MB/s for reading, including saturation of the Gigabit network. Yes, the Pi 4 can push even a 1000 MB/s network to 100%.

Network Speed Tests

Since the Pi 4 was launched, many sites have run the usual bench marking tools, and the results are widely available. They won’t be repeated here. This article is about real world testing. That is to say, making the Pi do a realistic job and measuring the actual time taken. Real files were transmitted, rather than auto-generated block streams or “dd” images. Realistic testing exercises the full stack: file system , CPU, USB and networking.

Local USB 3 Read/Write Speed

This test measures how fast the Pi 4 can read and write to a local USB 3 connected drive (a USB stick). Local performance needs to be established in order that the later network tests are meaningful.

A fast 128 GB memory stick was plugged into one of the Pi’s USB 3 ports. It was newly formatted with XFS (a file system commonly used in NAS applications). A large zip file (5.8 GB) was repeatedly copied to and from the drive, and the timings averaged.

Test No.DescriptionSourceTargetSpeed (Megabytes/s)Test File
1Read TestUSB Stick/dev/null113.15.8 GB
2Write Test/dev/shmUSB Stick68.61.1 Gb

Table 1. Raspberry Pi 4 Local USB 3 Read/Write tests. (It might be thought that the limiting factor is the speed of the drive. Not so. See the Control Testing at the end of the article).

The zip file was read from the USB stick into /dev/null, completing in less than a minute and achieving an average read speed of 113.1 GB/s. To test USB writing speed, a smaller zip file (1.1 GB) was placed into /dev/shm, the pi’s memory-based file system. It was copied to the USB drive at an average write speed of 68.6 MB/s. In both cases the copy was done with “cp“.

Network Read/Write Speed

The USB resident XFS file system was shared out from the Pi using Samba, and mounted as a CIFS mount on a fast, gigabit-equipped laptop. A large zip file (5.8 GB) was copied from the Pi to the laptop and back again, with the following results. The copy operation was a simple “cp” on the laptop.

Test NoDescriptionSourceTargetSpeedTest File Size
3Network ReadPi:USB Sticklaptop:/mnt105.05.8 GB
4Network Writelaptop:/mntPi: USB Stick64.75.8 GB

Table 3. Raspberry Pi 4 Network Read/Write Tests. The Pi acting as a NAS.

A average write speed of 67.4 MB/s was measured, a very good result, representing about 60% of maximum gigabit speed, and barely any less than the local write speed of 68.6. In reading, the measured speed was 105 MB/s, an astonishing figure, proving that the Pi 4 is (more or less) saturating the gigabit network.

Gigabit Saturation

Have a look at he network traffic during that network read test (Test 3), measured on the laptop using Gnome-system-monitor:

Illustration 1. Raspberry Pi 4 Saturates a Gigabit Network (Test 3). Also the biggest clobbering my humble Netgear switch has ever received.

It can be seen that the network is transmitting at almost maximum speed, i.e. nearly 1 Gb/s, for much of the copy time. Between 30 and 40 seconds it appears to hit saturation point. (It was actually running at 984 out of a possible 1000 MB/s. No testing I did could improve on that. Something always hangs on to those last 16 MB/s)

Usage of the Pi 4 as a NAS

Can the Pi 4 be used as a fast NAS? Obviously yes, and then some. For example, large files could be backed up to the Pi at speeds of over 60 MB/s, which even for a commercial NAS would be a healthy throughput. Reading is even better, with speeds of over 100 MB/s, the Pi’s speedy USB hardware pushing its gigabit interface (and your gigabit switch) to the maximum.

Effect of Caching

As a point of interest. Here is another chart that shows some of the effects/benefits of the Linux cache. Before all tests above, caches were dropped with the command “echo 3 > /proc/sys/vm/drop_caches“, both on the server (the Pi) and the client (the laptop). However, if we repeat Test 3, but don’t drop the Pi’s cache first, the effect can be seen, with the network being saturated more of the time:

Illustration 2. A repeat of Test 3 without caches being dropped on the Pi.

It seems that the first 2 GB or so of the 5.8 GB file were copied at maximum network speed. Then there were a couple of wobbles, then max speed again until the 30 second mark (half way through the copy). This is a 4 GB Pi, with the file cache defaulting to about 3 GB in size. It might well be that half of the big file’s pages were therefore still in the cache from the first test run, accounting for the extended saturation in this repeated test. (Except you might expect the cache to hold the last half of the file, not the first).


Acting as a NAS, the Pi 4 achieves over 105 MB/s for reading and over 60 MB/s for writing. An excellent result. Read speeds could likely go even higher with better hardware, nearer the 125 MB/s theoretical Gigabit maximum. My Grixx USB stick was just barely fast enough for the test, and an external SSD would have been preferable.

Incidentally, if the 5.8 GB file is targeted at the laptop’s /dev/shm memory file system, rather than its ext4 formatted SSD disk, the overall read speed increases to 108.2 MB/s. However this is not a realistic test, because users don’t store their data in /dev/shm, so it isn’t documented above.

I am not sure what is limiting the write speed to 68 MB/s. It might be my USB stick (notwithstanding its 117 MB/s write performance in the control testing, below). Testing points to the USB 3 interface but that should be equally fast in either direction.

Other Configurations

Samba sharing over CIFS provided much better performance than other configurations. If you want to use the Pi 4 as a NAS, that is the configuration I would recommend, along with XFS formatting. Update 22/11/20: If you are using the NTFS file system, (which I have not tested), then setting the NTFS big_writes parameter will likely improve performance, as testified by Frank in the comments.

The best I got from other configurations was:

SFTP performance was measured at about 39.9 MB/s for reading and 49.0 MB/s for writing.

SCP was slightly better with 41.8 (read) and 43.6 (write). Yes, write was faster.

Dragging and dropping in “caja” on the client (the file manager bundles with Linux Mint MATE) gave a read speed of 44.7 MB/s and wrote at 37.8 MB/s. This does not use CIFS.


It might be expected that faster results could be obtained with NFS. After configuring the Pi 4 as an NFS server, I repeated the above tests. The resulting transfer speeds were almost the same as under Samba/CIFS (fractionally slower, in fact). Faster speeds weren’t realized with NFS. Slightly disappointing, and points to the 68 MB/s limit being imposed by limitations elsewhere.

Test Equipment

  • A Raspberry Pi 4, 4 GB model, running Debian Buster (desktop).
  • A quad core i7 laptop, model MSI CX61 20D, containing 16 GB of memory, and a 1 TB Samsung Evo 850 SSD drive, and USB 3, running Linux Mint 18 MATE.
  • A Netgear Gigabit switch, model GS605 v2, 5 port.
  • A 128 GB memory stick, model Grixx.

Test Conditions

  • Caches were dropped before all tests (except the last one). Caches were dropped after all tests too, and the drop time included in the measured test time.
  • All tests were carried out three times and the speeds recorded above are averages.
  • The USB drive was formatted as XFS. Testing was also carried out with EXT4 but achieved much lower speeds.
  • The Pi’s core temperature was monitored throughout testing with “vcgencmd measure_temp“, recording a maximum of 74 C during the copies. Idle temperature was 69 C. Room temperature was 23 C.

Control Information

Before testing on the Pi, the USB stick performance was measured locally on the laptop, to prove it could sustain speeds high enough for significant testing. Results were as follows.

Test NoDescriptionSourceTargetSpeedTest File Size
0Read test 1USB StickInternal SSD118.45.8 GB
-1Read test 2USB Stick/dev/null126.55.8 GB
-2Write test 1Internal SSDUSB Stick117.05.8 GB

Table 4. Proving the USB stick prior to Pi testing.

The USB stick was able to perform at 126.5 MB/s for reading, 117.4 MB/s for writing. This can be taken as maximum performance for the stick. It exceeds read and write speeds on the Pi (just), and can be taken as the maximum stick performance.

50 thoughts on “Raspberry Pi 4 Real World Tests

  1. First off thanks for all the testing you’ve done! I was initially disappointed with the NAS / Samba performance of the Pi 4 as I was using a NTFS formatted 4TB 5400rpm HDD which only gave 54MB/s sequential reads, 28MB/s writes. I had tried using ext4 formatting but had seem similar & in some cases worse performance.

    Now using XFS, I’m able to get 75MB/s Read, 64MB/s Write to the same drive, with the exception of cached data which reads at a consistent 113MB/s. Big improvement thanks!

    In an attempt to replicate your 100MB/s+ sustained read I tried using a NVME SSD in a usb 3.1 gen 2 enclosure (XFS formatted) and somehow ended up with 34MB/s Read / 33MB/s Write, don’t suppose you might know whats going on there?

  2. Hi John,

    Cheers. Like you, I found that NTFS performance was very poor. NTFS isn’t native to Linux though, so it probably isn’t too surprising, as the data has to go through an extra stack of driver code.

    With your XFS, 75/64 MB/s isn’t a bad speed, over the network, for a 5400 RPM. An SSD or fast thumb drive (like the one I used) might achieve faster speeds, perhaps even a 7200 RPM spinning disk.

    Not sure why your SSD topped out at 34/33 MB/s. How was the data being transferred ? To get the 105 MB/s sustained, I was running Samba on the Pi 4, and using it to share out the USB 3 connected thumb drive. This was mounted on another Linux system (gigabit laptop) as a CIFS mount. Then a big file was copied into (and out of) the mounted area with a “cp” command, issued on the laptop.

    The CIFS mount gave the fastest speeds. All other arrangements seemed to result in transfer rated of 30 to 50 MB/s. Thanks for commenting, and good luck!


  3. Hello how about 4K content sharing to TV? Because when I stream 4K video, it buffering some times, disk it is a 1GB USB 3.0 ext4, on the router it is work ok.

    • Hi poczesaniec1. Sorry for the lateness in replying, which has been due to personal illness. TV pictures at 4K require a bandwidth of 15 to 25 Megabits/sec. The Pi4 can easily supply this (tests above gave better than 1000 Megabits/sec), so you shouldn’t see any buffering, unless, perhaps your house network is being heavily loaded with other traffic. Make sure the connection between the Pi and your TV is gigabit end-to-end. Also, I would recommend using XFS on the disk drive, rather than EXT4. Cheers, Jim.

  4. Hi. Thanks for publishing this. It’s proved useful to me as I was finding the write speed of the Pi 4 (1GB memory) somewhat less than I’d expected. I’m using an fast XQD (440MB/s in theory) in a reader over one USB 3 port and a 1TB Samsung T5 to write to over the other. My test case is copying approx 45GB of photos (roughly 25-30 MB per file) from one to the other for photo backup purposes (using rsync for this). In repeated tests I get a max sustained throughput of 64MB/s. Using a MacBook Pro with exactly the same cards & cables I comfortably get around the 160 MB/s (but using the regular ‘copy’ (drag & drop) command. From the above comments and your findings, the 63-68 MB/s mark looks fairly consistent. That makes me feel, it’s not something I’m doing but it does seem that there is some internal constraint in the Pi 4 that is the bottleneck here rather than attached devices. For the moment, I’m not too bothered as that’s about ‘good enough’ for my needs and the Pi 4 an effective tool for my needs but faster would be even nicer. Richard

    • Hi Richard. As I understand it, you are testing local transfer speeds on the Pi (no network involved). You are writing from a memory card to an SSD drive, all via USB3. The transfer involves rsyncing from one to the other and the speed is about 64 MB/s. This is fairly close to my local test above (test 2, 68.6 MB/s).

      In comparison, a Macbook Pro gives 160 MB/s with the same test, except that the copy is straightforward, and does not involve rsync.

      The Macbook is likely to be alot faster due to the much more expensive/powerful internal hardware. That is, the components and overall architecture connecting them. Also, the Mac was performing a simple copy, but the Pi was doing an rsync. For a proper comparison, they should both ideally be doing a straight copy (ie. no rsync).

      Can you run the tests again, but using a straight copy on the Pi, rather than rsync ? I guess the results will be similar, maybe a touch faster. Also, what happens if the copy is done in the other direction?

      Notwithstanding, it looks like 68 MB/s or so might be the maximum write speed on the Pi. It is hard to know exactly where the bottleneck is. The USB 3 bus doesn’t care if it is reading or writing. Your Macbook test proves the external hardware (cables etc.). Not quite sure.


  5. I don’t know how you guys tested. Running samba 4.10.8 and WD 5400rpm hdd connected via USB3 I copied an ISO file that is 6GB and saturated my Gigabit connection 112MB/s. Your samba server is likely not configured correctly. Not surprising given almost every guide out there is wrong, especially about socket_options. They are all outdated, and the current ones are based on the old ones. Here’s my config for reference:
    workgroup = WORKGROUP
    server string = MyRPi4
    netbios name = MyRPi4
    security = user
    map to guest = Bad User
    load printers = no
    disable spoolss = yes
    log file = /var/log/samba/%m.log
    max log size = 50
    deadtime = 30
    use sendfile = Yes
    write cache size = 262144
    min receivefile size = 16384
    aio read size = 16384
    aio write size = 16384

    path = /media/mystorage
    read only = no
    public = yes
    writable = yes
    force user = root

    • Hi Oleg. I can’t really comment on your test, as you haven’t given enough detail. You haven’t even told is if it was reading or writing.

      Anyway, I tried the Samba parameters you suggest, repeating exactly tests 3 and 4 above. The results were: read speed 48.4 MB/s, write speed 2.8 MB/s. That compares to 105 and 67.7 in the article. In other words, the new Samba parameters made reading 2 times slower and writing 24 times slower. Not good.

      There might be scope for improving the Pi 4 write speed with Samba tuning. But Samba tuning is a big subject. I would not recommend anyone try it on live systems. Not without extreme caution and exhaustive testing. It is too easy to damage the TCP stack, or to break Linux’s built in optimizations.

      Incidentally, 112 MB/s is not “saturating” a gigabit network. Saturation at about 125 MB/s can be checked with network monitor, you didn’t say if you used one.


      • Hi !

        Amazing achievement ! There are not many commercial NAS that can reach such speeds (in the real world) !

        Would you be so kind to share your smb configurations ?

        With kind regards,


        • Hi huitante. The SMB configuration (/etc/samba/smb.conf) was just the standard one distributed with Raspbian Buster. There were no special settings.

          The share was:

          comment = Test
          path = /mnt
          guest ok = yes
          public = yes
          writable = yes
          printable = no

          Note that “guest ok” and “public” are synonymous.

  6. Pingback: How to Watch and Record Live TV with a Raspberry Pi | Unix etc.

  7. After doing a lot of testing and tuning parameters I got the following results.


    Raspberry Pi 4 with 4GB
    500GB SSD (Transcend) on USB3.0 (on a USB hub powered externally)
    1Gbit Network

    [Samba Settings]

    max xmit = 65535
    max log size = 50
    deadtime = 30
    use sendfile = Yes
    write cache size = 2097152
    min receivefile size = 16384
    aio read size = 16384
    aio write size = 16384


    Write: 80 MB/s
    Read: 115 MB/s

    • Hi Muzhar, those are some good speeds. Can you share more details, such as: what was the speed with the default samba config ? Also about the size of the data files, method of copy, copy command, whether you cleared the caches before and after, average speed measurement over several runs, and so on.


      • Hi Jim,

        [Samba Default]

        Write: 63 MB/s
        Read: 101 MB/s

        [Test – Total 10 runs]

        sync; dd if=/dev/zero of=x bs=1M count=1024; sync; sudo /sbin/sysctl -w vm.drop_caches=3; dd if=x of=/dev/null bs=1M count=1024; rm -rf x

        The above was done on a separate system with SMB share mounted.

        Average Write: 77 MB/s
        Average Read: 114 MB/s


        • Hi Muzhar, thanks for coming back with more information. Those read and write speeds are good. They aren’t very relevant to the above article, however, which concentrates on “real world” tests. As stated under the section entitled Network Speed Tests, “Real files were transmitted, rather than auto-generated block streams or “dd” images. Realistic testing exercises the full stack: file system , CPU, USB and networking.“.

          A dd command to or from a pseudo device such as /dev/zero or /dev/null does not exercise the whole stack. Thanks all the same for providing these test results. Cheers, Jim.

          • Thanks Jim, and I’d agree a real copy would be realistic in the sense of file transfer, but as I mentioned in my comments the commands were run from a separate system that had the Samba share mounted.

            In this case, my test was focussed on the Samba performance and not the client. So even though the client was firing the dd commands it was stressing the entire Samba server stack i.e. the network, server CPU, memory, USB and disk.

            Now how we generate the data blocks is irrelevant for the exercise, it could be from the client files on its filesystem or using /dev/zero.

            On a separate note, the /dev/zero and /dev/null makes more send for these tests as the client test environment is consistent irrespective of the client state (i.e. client disk speed, cpu etc.)

            Once again the focus was on Raspberry Pi performance as a Samba server and not the client.

            I appreciate the feedback and conversation, Cheers …

          • Hi Muzar

            The article is about the “real world” performance of the Pi as a NAS. This is made clear in the title and explained the outset of the procedure. There are many Internet articles covering theoretical performance of the Pi4, often focusing on one sub system or another. But the purpose of this article is to measure real world performance that readers can expect to see when copying files in normal usage. Each test should therefore reflect the way the Pi will be used (as a NAS) day-to-day. “dd” and auto-generated block streams are therefore excluded, as stated in paragraph 4.

            Like your test, the article tests were performed on a remote client with the Samba share mounted, as explained under “Network Read/Write Speed”.

            In your test, the Pi is writing to (or reading from) a linear network stream, linked to a kernel stub device on the remote client. However, real network operations are not like this. In the real world, even on a quiet network, data streams are “lumpy” and somewhat unpredictable (see the charts above). In normal usage, the Pi has to do considerable work to buffer and smooth out this data as it passes up or down the TCP stack.

            In your test, the Pi is potentially doing much less of that, because it is being “spoon fed” an unrealistically smooth packet stream derived from remote stub device (/dev/zero), rather than a series of irregularly timed and ordered packets as happens when copying real data. Likewise, when writing, the Pi writes to an an unrealistically smooth and receptive network stream targeted at the remote stub /dev/zero, again reducing the buffering requirement. A pseudo device test, even with the pseudo device on the remote client, and the dd executing on the remote client, is therefore not reflective of real world usage and is not likely to achieve the same speeds. The easiest way to be sure is to exclude all these variables by just using real files.

            Having said all that, it is very interesting that you achieved higher speeds by altering the Samba parameters. It would be good if you could repeat the tests (but this time with real files and no pseudo devices) under both Samba configurations and see if a similar improvement can be had. I would try it myself but don’t have time at the moment.


          • Hi Muzhar

            I just repeated the write test, using your suggested Samba parameters. The results over 3 runs were:

            default Samba parameters – 59.9 MB/s (59.9/59.5/58.9)
            suggested Samba parameters – 57.3 MB/s (57.5/57.7/56.7)

            The suggested parameters resulted in a slight (but barely significant) decrease in write performance.

            On another subject, you didn’t mention if you were dropping the caches on the server too (ie. one the Pi). It has an important effect. The speed will look faster if the Pi’s caches aren’t dropped, as well as the client’s, between each run. Illustrations 1 and 2 show the effect for reading.


          • Hi Jim,

            Sorry I could not perform any more tests on this setup. Had to return the Raspberry PI due to horrendous performance with encryption. Tried eCryptFS, dm-crypt, Veracrypt with very bad results.


  8. Hi, thx for all those details.
    Did you by chance in the menawhile also have a look into the VPN performance?
    I have a 200/200 connection and am wondering what transfer speed might be.

    • Hi Adrian,

      I have not tested VPN performance. It will depend on the speed of your network and VPN software, among other things. Cheers, Jim.

  9. Thanks, very informative and detailed report.

    Did you try any RAID configurations? I am mostly thinking about striping, but that might have zero throughput improvement if the culprit is the Pi 4 itself.


    • Hi Oded. I didn’t try RAID storage. The equipment used was exactly as listed above. In general, faster storage hardware probably wouldn’t improve the read speed, with is very near saturating the network anyway. It might improve write speed, but I suspect the top write speed of about about 65 MB/s is a limitation of the USB bus, not the external disk. Cheers, Jim.

      • I agree that read speed is limited by GbE and hence will not improve by adding (faster) disks.

        However, I cannot see how the USB bus could be limiting write speed to 65 MB/s. USB-3 supports 5 Gbps so should not be an obstacle to reach much higher rates, and what’s more this is a symmetrical bus so it is difficult to see how it could limit write speed to lower values than read speed (which is still much less than the state bus data rate).

        I am asking about RAID as I have seen other reports where measured write speed was 50-70 MB/s, and this value was almost unchanged in RAID 0 mode, which leads me to suspect the limitation is in the S/W RAID (RPi 4) itself, not data I/O (GbE or USB-3) or hard disk write rate.

        • Hi Oded, Yes I know the theoretical limits of USB suggest higher speeds than the 65 MB/s documented. However this article is about “real world tests”, hence the title. Computer systems’ specifications and their realizable throughputs are often very different, as described in paragraph 2.

          I don’t know exactly what is causing the 65 MB/s limit, but it seems to be there nonetheless. Testing points to the USB, or the USB’s interaction with other elements, if only by eliminating other components as the cause. But it isn’t certain or settled. Still, 65 MB/s is very good and compares well with commercially available home NAS units.

          RAID is perhaps not likely to improve write speed significantly. Software RAID might even degrade performance, because it means all data has to traverse a longer software stack. An external storage unit with a dedicated hardware RAID controller would be better, albeit expensive and again, not guaranteed to improve much on 65 MB/s. The money might be better spent on an entirely separate NAS. For example the WD MyCloud costs about £120 (May 2020), reportedly manages about 70 MB/s write, and includes a 2 TB disk.


          • Thanks. WD’s mycloud solutions are a fairly attractive NAS option, cost-wise, but I like the versatility of the Pi.

            I already have a very basic NAS – a 2.5TB drive connected to a raspberry pi 3. It delivers ~10 MB/s, presumably limited by LAN speed. This is really too slow when transferring large files.

            I already placed an order for a Pi 4. I’m thinking of connecting my drive to the Pi 4 once it arrives; currently my drive is connected through a SATA-USB2 adapter which theoretically can reach 480Mbps. If I see such transfer rates running over GbE, I will buy a new SATA-USB3 enclosure and check for speed improvement. Then, will consider again the possible gains of adding another disk with or without a RAID config.


          • I have an ancient Buffalo Linkstation NAS that struggles up to about 15 MB/s, limited not by it’s network, which is gigabit, but by the low powered processor. Still, I find it fast enough for backups.

            I thought of removing the disk, putting it into a powered USB 3 enclosure and attaching it to the Pi4. It would be much faster. But the NAS is a neat solution, if slow. I’ll leave it as-is for now. Cheers Oded.

  10. Just thought I’d give a brief progress update.

    Got my rpi4 and installed it. My old NAS drive was displaying intermittent disconnects so I replaced my SATAII/USB2 adapter with a new SATAIII/USB3 adapter. Now it no longer disconnects; surprising how even such a dumb piece of circuitry can present puzzling faults.

    Now that the disk connection seems healthy, I started to look at transfer speeds. My network installation is not complete yet, so I copied files from the HD to a temporary ramdisk on the rpi4. Typical rsync transfer speeds were 75-85MB/s. This is more than reasonable for said drive – it’s a 10 year old desktop drive which at the time boasted ~50MB/s under windows, if memory serves.

    I transferred several ~100-800 MB files at ~80MB/s, but do sometimes see transfer speed drop to ~25MB/s, even though the rpi and the HD are idle except for the transfer under test. Not sure what could cause this; I’d like to say its because the disk is old, but honestly it seems unlikely.

    • Hi Oded, as I understand it, you have performed a read test on the disk by copying files from it to a memory backed area on the Pi (/dev/shm or similar). Read speeds of 75-85 MB/s are okay for a spinning disk. It isn’t exactly like any of the tests in the article, although there is some similarity to test number 1 (USB drive to /dev/null).


      • Right.

        This drive is ntfs formatted, and likely quite fragmented too (it’s 90% full), which probably accounts to a meager 25MB/s rate I got writing to the HDD from a ramdisk on the pi.

        Oh well, I can foresee a new HDD in the near future, and I suppose XFS or EXT4 will make more sense.

  11. Hey, thanks for the great article and follow up discussions, very informative. I recently setup a synology NAS, but have previously messed around with early Raspis. USB controller speed was a bottleneck back then too, it didn’t perform to USB spec in the real world.

    With a raspi nas I was concerned about fumbling a Linux command and vaporizing all my data. Or accidentally pulling out a flimsy USB power cable at the wrong time.

    A neat application for a RPI NAS would be a portable low power setup that can run off of solar power, with some flash based storage of some kind. Attach it to your car, now your car hauls data lol.

  12. hi,
    i have pi4 4gb and usb3 external 3tb desktop ntfs drive , when i transfer around 900mb file i get 15MB/s write and 30MB/s read speed
    any suggestion to improve speed

    • Hi Dpan,
      That is very slow. Try reformatting the drive with a native Linux file system such as ext4 or (better) XFS. Having the drive in NTFS format forces all the data to travel through an extra set of drivers and slows things down.

      A couple of warnings. Firstly, reformatting as XFS will erase all data currently on the drive. Secondly, once formatted in XFS, the drive will not be directly readable on Windows devices.


        • Hi dpan. You say that reformatting the drive to EXT 4 gave no performance improvement. That is a bit surprising. I would recommend reformatting again to XFS. As explained in the article, XFS was the fastest file system. Also make sure your disk is connected to one of the Pi’s USB 3 ports. The Pi 4 has 4 USB ports but only two of them are USB 3, indicated by the blue port insert. Jim.

  13. Hi, Thanks for sharing info. My test results are:

    Using WIFI 5Ghz(I dont have Ethernet 1Gb) .
    My Setup:
    RPi 4 4Ram, 1 hdd 4TB (sda2: EXT4, sda3: NTFS), dietPi OS

    sda2: Write: ~52 MB/s Read:~57 MB/s
    sda3: Write:~45 MB/s Read:~53 MB/s

    Samba Config:

    writeable = yes
    obey pam restrictions = yes
    server string = %h server
    max log size = 1000
    panic action = /usr/share/samba/panic-action %d
    unix password sync = yes
    passwd program = /usr/bin/passwd %u
    map to guest = bad user
    workgroup = WORKGROUP
    passdb backend = tdbsam
    disable spoolss = yes
    syslog = 0
    passwd chat = *Enter\snew\s*\spassword:* %n\n *Retype\snew\s*\spassword:* %n\n *password\supdated\ssuccessfully* .
    use sendfile = Yes
    deadtime = 30
    write cache size = 262144
    min receivefile size = 16384
    aio read size = 16384
    aio write size = 16384
    max xmit = 65535
    log file = /var/log/samba/log.%m
    syslog only = no
    auto services = global
    printcap name = /dev/null
    os level = 20
    revalidate = yes
    netbios name = Server
    path = /mnt/Data
    default = global
    valid users = @users,@root,@dietpi
    security = user
    load printers = no
    dns proxy = no
    pam password change = yes
    encrypt passwords = true

    revalidate = no
    valid users = root
    force group = users
    force directory mode = 777
    directory mode = 777
    force create mode = 777
    create mode = 777

    path = /mnt/Media

    • Hi Emanuel, thanks for posting. I guess EXT4 being faster than NTFS is as expected. The speeds measurements overall will be affected by the wi-fi performance. Cheers, Jim.

  14. Just in case anyone else comes across this site when looking at NTFS performance, I was able to drastically increase write speed to a USB drive formatted with NTFS by adding the big_writes option to my fstab. Where I was capping out around 20-24MBps, I hit 90MBps from a newer system and 65MBps from an older system.

    I found it referenced on a couple of other sites and gave it a shot (successfully), but this page was one of the early hits I had when I was looking for information on it, so I thought I’d leave a comment.

    • Cheers Frank. That looks like a very good idea. I have added a note about big_writes to the article, under the section entitled “Other Configurations”.


    • Hi Frank,

      I tried just adding big_writes as an option to my fstab, but it seems that as soon as i do that the directories in that drive “disappear.” I can cd /mnt/blue but when i go to ls, nothing appears! I then have to connect the drive back to windows and run chkdsk, remove big_writes from the fstab, and reboot to get the actual directories with my files to show up again. Any thoughts?

      UUID=F290B2EA90B2B507 /mnt/blue ntfs-3g defaults,rw,auto,nofail,big_writes

      • I also tried a variant like this (with my info above put in)
        UUID=0AC4D607C4D5F543 /mnt/volume ntfs-3g async,big_writes,noatime,nodiratime,nofail,uid=1000 [OPTIONAL U NEED TO LOOKUP USER IDs],gid=1000 [OPTIONAL U NEED TO LOOKUP GROUP IDs],umask=007 0 0

        • Hi Tom, it sounds like you are swapping an external drive between the Pi 4 and Windows. Unfortunately I can’t debug your /etc/fstab file or help with a disk you are connecting to multiple machines, as it is beyond the scope of the article and there are too many variables. Having said that, if you see no files under the mount point (and your comment implies /mnt/blue is the mount point), then the file system is probably not mounted. Cheers, Jim

  15. Just wondering how do you boot your Pi? On sdcard or on usb3 or ssd?
    I’m using os on sdcard, then testing the USB3 stick, but can only get SFTP&Samba writing speed (from Windows laptop to here) of:
    exfat = 2-3 MB/s++
    ext4 = 3-4 MB/s++
    xfs = 9-10 MB/s++
    ntfs = 4-5 MB/s++

    from usb xfs to sdcard rpi

    pi@ht-rpi:/mnt/mydisk/smb-mydata$ dd if=test-one-gb-out.img of=~/test/test-one-gb-back.img
    2097152+0 records in
    2097152+0 records out
    1073741824 bytes (1.1 GB, 1.0 GiB) copied, 23.2451 s, 46.2 MB/s

    from sdcard rpi to usb xfs

    pi@ht-rpi:/mnt/mydisk/smb-mydata$ rm -rf test-one-gb-out.img
    pi@ht-rpi:/mnt/mydisk/smb-mydata$ dd if=~/test/test-one-gb.img of=test-one-gb-out.img
    2097152+0 records in
    2097152+0 records out
    1073741824 bytes (1.1 GB, 1.0 GiB) copied, 13.9236 s, 77.1 MB/s

    from Windows SMB Client to RPi SMB USB XFS and vice versa

        • No issue for ethernet. But no luck to get the Wifi speed higher.

          Mode:Managed Frequency:5.2 GHz Access Point: xxxxxx
          Bit Rate=180 Mb/s Tx-Power=31 dBm
          Retry short limit:7 RTS thr:off Fragment thr:off
          Encryption key:off
          Power Management:off
          Link Quality=70/70 Signal level=-37 dBm
          Rx invalid nwid:0 Rx invalid crypt:0 Rx invalid frag:0
          Tx excessive retries:0 Invalid misc:0 Missed beacon:0

          Mode:Managed Frequency:5.18 GHz Access Point: xxxxxx
          Bit Rate=200 Mb/s Tx-Power=31 dBm
          Retry short limit:7 RTS thr:off Fragment thr:off
          Encryption key:off
          Power Management:off
          Link Quality=70/70 Signal level=-28 dBm
          Rx invalid nwid:0 Rx invalid crypt:0 Rx invalid frag:0
          Tx excessive retries:0 Invalid misc:0 Missed beacon:0

          [ 4] local x.y.z.8 port 5001 connected with x.y.z.2 port 54454
          [ 4] 0.0-10.0 sec 92.1 MBytes 77.2 Mbits/sec
          [ 4] local x.y.z.8 port 5001 connected with x.y.z.2 port 54485
          [ 4] 0.0-10.0 sec 99.4 MBytes 83.0 Mbits/sec
          [ 4] local x.y.z.8 port 5001 connected with x.y.z.2 port 54489
          [ 4] 0.0-10.0 sec 93.9 MBytes 78.6 Mbits/sec

          ^equals to ~10MB/s.

          For Windows client, able to get 780Mbps to the same Wifi, with iperf 302 Mbits/sec = ~38MB/s.

          • Hi nonsecure, I can’t help with your wifi unfortunately, as it is well beyond the scope of the article. Cheers, Jim.

  16. Hey! Thanks for this!

    I have these write/read speeds on RPi4 B 2 GB RAM:
    The RPi 4 is connected to an ASUS RT-AC56U, accessing it from an ASUS RT-AC66U (connected as an AP to the RT-AC56U)
    Accessing NAS Samba from 5 GHz Wifi notebook (866 MB/s max speed, iperf shows ~540 mbit/s bandwidth)
    Storage drive: 1 TB 2.5″ HDD on USB 3.0
    File: “Fedora-KDE-Live-x86_64-33-1.2.iso”, 1.9 GB
    Read: ~65 MB/s
    Write: ~45 MB/s

    While the speed is pretty much okay with large files, it’s struggling with many of smaller files (eg. many of ~1-10 KB files or ~1 MB files) when copying or deleting from SMB.
    It seems for me that it’s deleting one-by-one, so that’s why it’s way slower, not deleting more files simultaneously. Now I’m not an expert at this, so I just simply ask that is it normal with small files? Could I improve this somehow?
    Here is my smb.cfg:

    workgroup = WORKGROUP
    max xmit = 65535
    max log size = 50
    deadtime = 30
    use sendfile = Yes
    write cache size = 262144
    min receivefile size = 16384
    aio read size = 16384
    aio write size = 16384
    ; bind interfaces only = yes
    log file = /var/log/samba/log.%m
    logging = file
    panic action = /usr/share/samba/panic-action %d
    server role = standalone server
    obey pam restrictions = yes
    unix password sync = yes
    passwd program = /usr/bin/passwd %u
    passwd chat = *Enter\snew\s*\spassword:* %n\n *Retype\snew\s*\spassword:* %n\n *password\supdated\ssuccessfully* .
    pam password change = yes
    map to guest = bad user

    comment = sda3’s Files in ADATA HV620
    path = /mnt/sda3/Files
    dos filetimes = yes
    fake directory create times = yes
    valid users = pi
    invalid users =
    #read list = pi
    #write list = pi
    browseable = yes
    read only = no
    create mask = 0775
    writeable = yes

    • Hi Kushwaves. Yes it is normal for reading and writing to be slower (often much slower) with small files. Network file systems like SMB do thing one-file-at-a-time, as you surmise. Performance is always slower with small files.

      65/45 is pretty respectable, especially if you are going over a wireless link. Cheers, Jim.

Leave a Reply

Your email address will not be published. Required fields are marked *

This site uses Akismet to reduce spam. Learn how your comment data is processed.