USB drives and ext4 these days

[Mikx4]

Also asked this in subReddit Linux, and since it is driving me crazy, I thought what better than to hassle you all with the same.

Are there certain USB manufacturer sticks that we have to use when we format them as EXT4?

Testing:
I have a couple of USB3.1 Integral Courier USB sticks. 1x 256GB and 1x 64GB.

I have wondered why trying to install a Linux OS on them was taking do darned long so I have been doing a bit of testing on the 64GB stick.

The transfer speed of rsync when the stick is formatted EXT4 drops to around 1MB/s after the initial caching and writing some of the data to the stick, and rsync tells me I am going to wait hours for a 13GB file to be copied over.

Example:

root@RTS3050Mint:/home/mikx4# nocache rsync -v --progress /media/mikx4/NobaraHome/mikx4/Downloads/kali-linux-2025.2-installer-everything-amd64.iso /home/mikx4/USBstick1/kali-linux-2025.2-installer-everything-amd64.iso

kali-linux-2025.2-installer-everything-amd64.iso

3,922,034,688 29% 37.00kB/s 71:30:34


I formatted the stick to Exfat with gparted and 13GB took only 4 minutes.

I am only using the ISO as a large file test. I do not want/need to dd it directly to the USB stick. I have another Ventoy USB stick that I use exclusively to boot ISOs.

I am trying to use these USB sticks for temporary Linux OS installs, rather than a live ISO, and rather than trying to put a 4th OS on my two SSD drives, and wrecking efi and grub(which I am sure to do )

So the USB sticks must be formatted as some sort of Linux filesystems.


I am trying to mkfs.ext2 at the moment, but that is taking even longer than mkfs.ext4. I think I am at the 27minute marker trying to mkfs.ext2 and it has just finished.

root@RTS3050Mint:/home/mikx4# time mkfs.ext2 /dev/sdc1

mke2fs 1.47.0 (5-Feb-2023)

/dev/sdc1 contains a ext2 filesystem

created on Thu Sep 11 12:41:54 2025
Proceed anyway? (y/N) y

Creating filesystem with 15359488 4k blocks and 3842048 inodes

Filesystem UUID: a4086984-dcf2-46a2-95f3-4885ff19211e

Superblock backups stored on blocks:

32768, 98304, 163840, 229376, 294912, 819200, 884736, 1605632, 2654208,

4096000, 7962624, 11239424
Allocating group tables: done

Writing inode tables: done

Writing superblocks and filesystem accounting information: done

real 27m35.694s

user 0m0.015s

sys 0m0.117s


mksfs.btrfs -f takes mere seconds, and rysncing that same file takes approx the same time as exfat.


Here's the same stick reformatted back to EXT4, and copying this same file.

root@RTS3050Mint:/home/mikx4# time nocache rsync -v --progress --outbuf=N /media/mikx4/NobaraHome/mikx4/Downloads/kali-linux-2025.2-installer-everything-amd64.iso /home/mikx4/USBstick1/kali-linux-2025.2-installer-everything-amd64.iso

kali-linux-2025.2-installer-everything-amd64.iso

3,740,631,040 27% 90.50kB/s 29:47:16 and then I got fedup waiting and CTRL C'd it.


And again show that its really quick with btrfs:

root@RTS3050Mint:/home/mikx4# mkfs.btrfs /dev/sdc1 -f
btrfs-progs v6.6.3
See https://btrfs.readthedocs.io for more information.

Performing full device TRIM /dev/sdc1 (58.59GiB) ...
NOTE: several default settings have changed in version 5.15, please make sure
this does not affect your deployments:
- DUP for metadata (-m dup)
- enabled no-holes (-O no-holes)
- enabled free-space-tree (-R free-space-tree)

Label: (null)
UUID: a1427dfb-88c6-4da2-90d9-cc1a21d714bd
Node size: 16384
Sector size: 4096
Filesystem size: 58.59GiB
Block group profiles:
Data: single 8.00MiB
Metadata: DUP 1.00GiB
System: DUP 8.00MiB
SSD detected: no
Zoned device: no
Incompat features: extref, skinny-metadata, no-holes, free-space-tree
Runtime features: free-space-tree
Checksum: crc32c
Number of devices: 1
Devices:
ID SIZE PATH
1 58.59GiB /dev/sdc1

root@RTS3050Mint:/home/mikx4# mount /dev/sdc1 /home/mikx4/USBstick1
root@RTS3050Mint:/home/mikx4# chown mikx4: /home/mikx4/USBstick1
root@RTS3050Mint:/home/mikx4# time nocache rsync -v --progress --outbuf=N /media/mikx4/NobaraHome/mikx4/Downloads/kali-linux-2025.2-installer-everything-amd64.iso /home/mikx4/USBstick1/kali-linux-2025.2-installer-everything-amd64.iso
kali-linux-2025.2-installer-everything-amd64.iso
13,445,949,440 100% 27.48MB/s 0:07:46 (xfr#1, to-chk=0/1)

sent 13,449,232,261 bytes received 35 bytes 28,768,411.33 bytes/sec
total size is 13,445,949,440 speedup is 1.00

real 7m48.435s
user 0m11.274s
sys 0m33.033s


It does not seem to be the EXT4 journalling causing the issue:

root@RTS3050Mint:/home/mikx4# mkfs -t ext4 -O ^has_journal /dev/sdc1

mke2fs 1.47.0 (5-Feb-2023)

/dev/sdc1 contains a btrfs filesystem

Proceed anyway? (y/N) y

Creating filesystem with 15359488 4k blocks and 3842048 inodes

Filesystem UUID: 141ee131-7ae2-484e-bb63-bde15eccba02

Superblock backups stored on blocks:

32768, 98304, 163840, 229376, 294912, 819200, 884736, 1605632, 2654208,

4096000, 7962624, 11239424



Allocating group tables: done

Writing inode tables: done

Writing superblocks and filesystem accounting information: done



root@RTS3050Mint:/home/mikx4# mount /dev/sdc1 /home/mikx4/USBstick1

root@RTS3050Mint:/home/mikx4# chown mikx4: /home/mikx4/USBstick1

root@RTS3050Mint:/home/mikx4# time nocache rsync -v --progress --outbuf=N /media/mikx4/NobaraHome/mikx4/Downloads/kali-linux-2025.2-installer-everything-amd64.iso /home/mikx4/USBstick1/kali-linux-2025.2-installer-everything-amd64.iso

kali-linux-2025.2-installer-everything-amd64.iso

3,848,372,224 28% 914.29kB/s 2:54:57


Thank you.

 

[CaffeineAddict]

nocache rsync -v --progress /media/mikx4/NobaraHome/mikx4/Downloads/kali-linux-2025.2-installer-everything-amd64.iso /home/mikx4/USBstick1/kali-linux-2025.2-installer-everything-amd64.iso

Please test with:

cp /media/mikx4/NobaraHome/mikx4/Downloads/kali-linux-2025.2-installer-everything-amd64.iso /home/mikx4/USBstick1/kali-linux-2025.2-installer-everything-amd64.iso

Is slowness still problem with cp?

Also please post output of sudo fdisk -l /dev/sdX (replace /dev/sdX with your USB device path)
To get USB device path run lsblk

 

[Mikx4]

Please test with:

cp /media/mikx4/NobaraHome/mikx4/Downloads/kali-linux-2025.2-installer-everything-amd64.iso /home/mikx4/USBstick1/kali-linux-2025.2-installer-everything-amd64.iso

Is slowness still problem with cp?

Also please post output of sudo fdisk -l /dev/sdX (replace /dev/sdX with your USB device path)
To get USB device path run lsblk

What filesystem do I use to do the things you want me to do? If it is EXT4, I will definately be here all week waiting for it to finish copying.
I have tried to copy previously, which is why I am now using rsync, since rsync gives me a progress, and cp does not. and previously cp took forever.

I have also used rsync without nocache and ditto the above reason for using rsync.

OK, I tried pv <source> > <destination> on the EXT4 filesystem again after I did mkfs.ext4 /dev/sdb1 and it is again around 1MB/second transfer rate to USB, although other times is is maybe 2 or 3MB/s and other times it is below 100KB/s.

root@RTS3050Mint:/media/mikx4/NobaraHome/mikx4/Downloads# pv /media/mikx4/NobaraHome/mikx4/Downloads/kali-linux-2025.2-installer-everything-amd64.iso > /home/mikx4/USBstick1/kali-linux-2025.2-installer-everything-amd64.iso
5.16GiB 0:35:06 [44.0KiB/s] [===================================================> ] 41% ETA 1:37:25 ETA 1:04:58:39:43


I am running this on Mint Zara, but I have also tried doing the same copies in Nobara Linux, also installed in my system.

Here is my lsblk:

root@RTS3050Mint:~# lsblk
NAME MAJ:MIN RM SIZE RO TYPE MOUNTPOINTS
sda 8:0 0 953.9G 0 disk
├─sda1 8:1 0 264G 0 part
├─sda2 8:2 0 32G 0 part
├─sda3 8:3 0 3G 0 part
├─sda4 8:4 0 56G 0 part
├─sda5 8:5 0 24G 0 part /media/mikx4/NobaraHome
└─sda6 8:6 0 128G 0 part
sdb 8:16 1 58.6G 0 disk
└─sdb1 8:17 1 58.6G 0 part /home/mikx4/USBstick1
nvme0n1 259:0 0 476.9G 0 disk
├─nvme0n1p1 259:1 0 260M 0 part /boot/efi
├─nvme0n1p2 259:2 0 16M 0 part
├─nvme0n1p3 259:3 0 416.7G 0 part
├─nvme0n1p4 259:4 0 59G 0 part /
└─nvme0n1p5 259:5 0 1000M 0 part
root@RTS3050Mint:~#

root@RTS3050Mint:~# blkid | awk '{print $1,": "$2}' | sort
/dev/nvme0n1p1: : LABEL_FATBOOT="SYSTEM_DRV"
/dev/nvme0n1p2: : PARTLABEL="Microsoft
/dev/nvme0n1p3: : LABEL="Windows-SSD"
/dev/nvme0n1p4: : LABEL="LinuxMintZara"
/dev/nvme0n1p5: : LABEL="WINRE_DRV"
/dev/sda1: : LABEL="264GBWindowsBtrfs"
/dev/sda2: : LABEL="TshiftMintMate"
/dev/sda3: : LABEL="NobaraBootEfi"
/dev/sda4: : LABEL="NobaraExt4"
/dev/sda5: : LABEL="NobaraHome"
/dev/sda6: : LABEL="TShiftNobara"
/dev/sdb1: : UUID="7c6362e6-7857-4122-bef7-3d8ad5541aed"
root@RTS3050Mint:~#

In the Linux subreddit, I am trying this tonight/tomorrow.


sudo time shred -n 0 -vfz /dev/sdb1 (no passes but still does zeroing).

sudo time mkfs.ext4 /dev/sdb1

sudo mount /dev/sdb1 /home/mikx4/USBstick1

sudo chown mikx4: /home/mikx4/USBstick1

time echo 3 | sudo tee /proc/sys/vm/drop_caches

time pv /home/mikx4/Downloads/kali-linux-2025.2-installer-everything-amd64.iso > /home/mikx4/USBstick1/kali-linux-2025.2-installer-everything-amd64.iso

I think shred gives the correct write speed since it is not relying on writing to a filesystem, and iostat in another window while running shred gives a consistent approximate 46000KB_wrtn/S against /dev/sdb1 (The USB stick device partition). Yep, shred finished in 22minutes shredding a 64GB USB stick so that 48000KB/S writing speed.

The mkfs.ext4 only took 22seconds this time which is amazing.

root@RTS3050Mint:/home/mikx4/Downloads# sudo time mkfs.ext4 /dev/sdb1
mke2fs 1.47.0 (5-Feb-2023)
Creating filesystem with 15359488 4k blocks and 3842048 inodes
Filesystem UUID: c2408524-6d74-48ff-8789-35f0744fc021
Superblock backups stored on blocks:
32768, 98304, 163840, 229376, 294912, 819200, 884736, 1605632, 2654208,
4096000, 7962624, 11239424

Allocating group tables: done
Writing inode tables: done
Creating journal (65536 blocks): done
Writing superblocks and filesystem accounting information: done

0.00user 0.02system 0:21.69elapsed 0%CPU (0avgtext+0avgdata 3456maxresident)k
2288inputs+9480outputs (0major+431minor)pagefaults 0swaps
time echo 3 | sudo tee /proc/sys/vm/drop_caches
3

real 0m2.388s
user 0m0.003s
sys 0m0.009s

Looks like doing all the above has not fixed anyrthing. Writing to this 64GB USBstick with a EXT4 filesystem is just not good.

 

[Mikx4]

Today, shredding a 256GB microsd card plugged into a usb3 card reader, plugged into a usb3 slot and I am getting a consistent 74MB/s write speed with the shred command.
I will attempt to use this mirosd card to install various Linux Distros, and see how it goes.
Thank you for reading all the way to here .

 

[Brickwizard]

I have a couple of USB3.1 Integral Courier USB sticks. 1x 256GB and 1x 64GB.

I have wondered why trying to install a Linux OS on them was taking do darned long

Several things come into play, you may have usb3.1 drives but do you have 3,1 output from your machine [if not it will run at USB2 speed]
Then looking at the difference between ex-fats and EXT4 , EXT compresses the information more than EX FATS compression takes time.
When it comes to removable media [USB/SD/&Etc] the industry standard is EX-fats, so this is what they are optimised for

Personally I no longer use USB's for testing distributions, I invested in a m2 SSD [not Nvme] to USB3 caddy and a small m2 20x80 SSD, depending on which machine I plug it into I get the optimum speed for the socket [480mbs for USB2 and 5gbs for USB3

 

[wendy-lebaron]

usb3 generally has been awful. a complete engineering failure in my opinion. the problem is. stores still sell 64gb disks. at a significantly higher price than better stuff. still on "slow and outdated" usb 2.0.

i have had even sandisk letting me down. this year and last year. my problem for insisting to use them. to back up linux operating systems.

i had one of those disks. which look like silly dodge charger. diving right down below 1mib/second transfer rate. according to nemo or thunar. maybe it's nemo, such a trashy file manager. only one of them. which is orange. like "general lee" from "dukes of hazzard". still performs like it should. but i try not to use it a lot.

also my advice is to keep away from centon usb 3.0. i had one 64gb disk "get dirtied" in file table. for a reason withheld from me. it caused a failure to restore. a linux operating system with clonezilla. generally usb 3.0 disks. get crazy hot while plugged in. while transferring files from and to it. for at least 30 seconds.

sandisk still using that long black finger. for disks they have also sold as "cruzer edge" and "cruzer blade." like those funny-looking blue, red and black disks. that should have been for kids going to school. they are usb 2.0 but perform reasonably well. i hesitate yet to call them reliable. those plastic cases could break easily. that's why i desired to avoid them.

i have had also a sandisk ultra trek. this:

amazon.com/SanDisk-64GB-Ultra-Flash-Drive/dp/B07K7WYHDX

Amazon.com: SanDisk 64GB Ultra Trek USB 3.0 Flash Drive - SDCZ490-064G-G46,Black : Electronics

Amazon.com: SanDisk 64GB Ultra Trek USB 3.0 Flash Drive - SDCZ490-064G-G46,Black : Electronics

www.amazon.com

but i think it was 32gb. it had rubber exterior. so if it's dropped from small distance. it's not easily damaged. i never dropped it. but it "burned out its light" in about six months. this was mainly because i was trying. to use it like an internal hard disk in windows10. this was way back in 2019. not sure if it were usb 3.0.

i also have a pny 32gb disk. a square one. but that one could decide to stick up for several seconds. i have plugged it in regularly. for at least three years. only to get documents and programs from it. had to reformat and transfer again into it once. but no problems so far.

so far lexar hasn't failed me. if so i don't remember. but their disks are d-o-g--s--l--o--w. copying 5gb takes over three hours. it doesn't matter. if it has to transfer small rocks or little rocks. generally one model usb 2.0. does very well transferring a file as large as 256mib. but then it does a "sync". the user must wait for that. much longer than if it copied several files adding up to the same amount. but that's how it feels like.

those lexar disks usb 3.0. which have weird formatting like "vfat". which look like bricks. have been quite good so far. but because i try not to plug them in a lot. i also have a verbatim "seaglass". which is crap. sometimes i plug it into my computer. and it's not recognized. reminds me of the cheap junk. i once bought from walmart. for some reason. those disks just stopped being allowed to be read.

 

[Brickwizard]

Today, shredding a 256GB microsd card plugged into a usb3 card reader, plugged into a usb3 slot and I am getting a consistent 74MB/s write speed with the shred command.

Check your card's speed rating..

 

[Mikx4]

Used the 256GB microsd plugged into USB adapter. Works really well, but I used btrfs as the FS, so not 100% sure it is actually better since btrfs seemed to be good on native usb3 that I was testing. Anyway, I am done testing USB sticks. Lesson learnt. Sticking with the microsd method or external nvme/ssd.
Thanks for reading.
Bye for now

 

[MikeRocor]

I recently bought a 3-pack of Sandisk 64 GB USB 3.0 USB sticks and I've only put one of them into service.

• zeroed the first couple of GB using dd
• partitioned all but the last 10 MB as a linux partition and the final 10 MB as an EFI partition
• formatted the first partition as ext4 and and the second as vfat
• dual installed grub2 so it can boot in either a BIOS machine or a UEFI machine
• frugal installed Tiny Core 6.1 / x86_64 on the main partition

I didn't pay attention to speed during the install but I'm pretty sure I didn't put any stress on it at that time anyway.

Just now, I used dd to write a 20 GB file to it from /dev/zero and it took 5 minutes and 20 seconds.

When I ran the exact same test but waited for sync to finish before stopping the timer, it took 17 minutes and 19 seconds.

Reading the same file back, after clearing cache, took 2 minutes and 35 seconds.

I'll just leave this as raw data instead of trying to interpret it, since I see the OP has finished with the thread while I was fooling around with it.

 

[MikeWalsh]

@Mikx4 :-

A couple of observations:-

Personally, I wouldn't touch Integral's flash drives with a barge-pole. They are horrendously slow. Whether this is an issue with the controller chips, or whether they're simply using very old NAND chips, I wouldn't like to say.....but it's more fun watching paint dry than it is working with their drives.

I only ever tried one.....and that was enough for me. Never again.

~~~~~~~~~~~~~~~~~~~~~​

My biggest is a 512 GB Sandisk 'Fit' USB 3.0 'nano' thumb-drive. Formatting that to ext3 - standard practice for us with 'Puppy' - took, from what I recall, a little over 12 minutes. That's a frickin' BIG flash drive, capacity-wise. I actually find that, for flash drives, 256GB seems to be the "sweet spot" in terms of max capacity versus speed of operation & ease of use.

Never had problems with SanDisk, except once.....and that was as a result of a contractual disagreement between SanDisk & the Taiwanese chip-maker SK Hynix. A huge batch of faulty controller chips was involved.....but said issue affected millions of users, world-wide, and was only ever on the Cruzer 'Blades'. (The court case dragged on for more than 7 years; neither side would budge, and it was eventually settled out of court for somewhere in the region of $40 million, IIRC).

Aside from that, never had a moment's trouble with them.

Like many here, I'm steadily moving away from flash drives to portable, external SSDs and the like. More rugged, more reliable, and a LOT faster to use.


Mike.

 

[bob466]

I don't worry about the speed of Flash Drives but I don't buy the cheep ones...I've found Lexar and Sandisk ok. I also don't format them...if on the rare occasion I burn a Distros ISO...the Distro will format it.

 

[Trynna3]

I had a little used sandisk usb 128GB that cooked itself to file protected. I think that brand went down with quality. Some of their extrenal SSDs were notoriously known for failing and data loss, too.
I am now using mostly Kingston, bought directly from Kingston or their direct affiliates (if the link sends me to ebuyer), as I no longer trust anything on scamazon or other similar platforms when it comes to fine electronics.
I got a few Phillips usb sticks I bought locally, 16 to 64GB and when bench testing, the higher capacity performed slower than lower capacity, like if they compromised for hardware quality the higher they went in capacity, but still charging extra for larger capacity. A few components turned out to be anonymous, general Chinese stuff you cannot trace to the manufacturer.

 

[Trynna3]

I don't worry about the speed of Flash Drives but I don't buy the cheep ones...I've found Lexar and Sandisk ok. I also don't format them...if on the rare occasion I burn a Distros ISO...the Distro will format it. View attachment 27880

I also thought about that need to format them. Linux can handle NTFS format and others pretty well, too.

 

[rado84]

The majority of the USB stick brands support Spyware filesystems only. The only manufacturer I know first hand to support ext4, xfs, etc is Kingston, though not all of their models are built with linux FS support. You gotta look for "Linux compatible" in the model specifications.
If you format a USB stick with a linux FS and it doesn't support it, you're gonna brick the stick.

 

[CaffeineAddict]

The majority of the USB stick brands support Spyware filesystems only. The only manufacturer I know first hand to support ext4, xfs, etc is Kingston, though not all of their models are built with linux FS support. You gotta look for "Linux compatible" in the model specifications.
If you format a USB stick with a linux FS and it doesn't support it, you're gonna brick the stick.

I had no clue USB's don't support all FS's.
Anyway I have 3 sticks and one of them is Kingston 64G, but I see no reason to format them to anything because only purpose they serve me is to have a live stick and netinst which doesn't need any FS's, just ISO burn directly to device.

 

[MikeWalsh]

Well, I hate to say it, but I've never heard so much tosh in my life.

Hardware, with embedded software/controllers, yes; that I'll believe, but storage drives..? Nah. Not in a million years. Don't forget, more up-market drives - when you buy them - tend to come unformatted, and it's left to the user to format them, before use, in their preferred format.

I've lost track of the number of assorted drives of all kinds, that I've formatted/re-formatted into just about every format/file-system you can think of.....and not one of them has ever failed to behave in the expected manner.

This has to be the first time I've ever heard anyone make such a peculiar statement in regard to storage drives.

???

I don't make a habit of vehemently disagreeing with other folks, but I can't let such a statement go unchallenged.....because otherwise, the record remains one-sided, and anybody else visiting this site (especially noobs) will take it as gospel. And that's no good to anyone.

Frankly, I find it hard to fathom that any serious Linux user would ever take any such statement at face value, much less believe it.


Mike.

 

[f33dm3bits]

I had no clue USB's don't support all FS's.

In all my years of using Linux I've never went looking for ones with support for something specific. As usb devices are block devices and are shown to the host as storage device, it would be odd if some vendor got to decide what file-system you use and I've never seen storage device support sections with what file-system the device supports. The only thing I have seen is that some external disks have some form of encryption on them that only have Windows support and then can't be unlocked from a Linux system.

 

[MikeRocor]

I've lost track of the number of assorted drives of all kinds, that I've formatted/re-formatted into just about every format/file-system you can think of.....and not one of them has ever failed to behave in the expected manner.

Same here. Unless I'm planning on using a USB stick on a Windows computer (which is almost never) or sharing it with a Windows user (which is pretty rare), I always reformat a new stick. When I do so, I use dd to zero at least the first GB or so (usually the whole device) before repartitioning and formatting.

• Almost all of my USB sticks are Lexar, Sandisk or HP brand, though a few are Emtec (they were cheap). I use one of the Emtec ones for music in my car (with vfat) and it has proven to be less than "robust" in that very harsh environment. I've amassed quite the collection of ever bigger flash drives over the years.
  
• I usually partition the last ten MB as an EFI partition and format that as vfat. My OS is very small, so I at least do the partitioning/formatting as I would for making a stick bootable, even if I'm not installing the bootloader and OS right at the get-go.
• I usually use ext4 for the main partition
• I've installed an ext fs driver on my last remaining Windows 7 box, just in case.

 

[CaffeineAddict]

@MikeWalsh
Are you saying USB should be able to be formatted to ext4 or any other format without breaking them?
I'm asking because don't want to destroy my disk.

@f33dm3bits
Have you formatted your stick to ext4, and did it work?

 

[MikeWalsh]

@CaffeineAddict :-

At least a couple of my slightly "smaller" drives - 1st-gen, 128GB SanDisk USB 3.0 Ultra 'Fit' - have been "through the mill". Both of these have at various times been formatted to:-

• FAT32
• ExFAT
• Ext2
• Ext3
• Ext4
• ZFS
• BTRFS
• NTFS (!!), and Haiku's unique & proprietary
• BFS.....loosely based around Apple's HFS, dating right back to the NextStep days of the early 90s.

In every case, things always worked absolutely as expected. I can't guarantee it would be the same for YOU - YMMV, of course - but it certainly proves the point, wouldn't you say?

Entirely up to you as to whether you try it.....but I'm not the first one to successfully format USB flashdrives / external HDDs to Ext2, 3, or 4. Not by a long chalk.

~~~~~~~~~~~~~~~~~~~~~~~​

I've had an install of ZorinOS on an external USB 3.0 500GB Seagate HDD dating all the way back to Zorin 8.0. It's one of the extremely few "mainstream" distros I've ever had any real time for.....and like all such, it runs under Ext4.

(shrug...)


Mike.