What is the proper way to format a USBDrive to store data?

I formatted one in macOS and notice that under Linux, there’s a small partition (usually Fat32) before the main one (exFat). Still new to Linux and I’m wondering if it’s normal for a USB Drive to have only 1 partition (EXT4) taking up all the available space? There isn’t a quick way to format a drive via right-click on the file manager for Linux to take care of it automatically. So I had to do it via KDE Partition Manager. This USB Drive has only one partition (EXT4) and I’m able to store files without any problem. Is this how it’s done?

I’m sure there’s something better - but I remember using Mintstick before - pamac search mintstick.
Sure, just one partition is fine - ext4 for linux but FAT32/exFAT/NTFS is okay - and mintstick will do the job double quick.

Install Mintstick and you get two new menu items (in the main menu) USB stick formatter and USB stick writer.

I don’t think so, this is the most reliable I have found :slight_smile:

1 Like

Use either Mintstick (from the repo) or a utility script like this - the latter defaults to the universal vfat but can be repurposed to use e.g. ext4

Recently I got my 1TB external harddrive (exFat) corrupted while under Linux. Luckily, I got the important stuff backed up. Because of this incident I am now looking more into EXT4 and Journalling (had no idea what it was / for). Anyway, here’s what happened: I copied files from NTFS hdd (running Windows 10) to EXT4 hdd running Linux. Then I transferred these files (from EXT4 running Linux) to my external SSD (exFat) inside Linux. While it was copying, I clicked on a file in this exFat and the copying progress stopped responding. Couldn’t shutdown the computer so I held down the power button. That somehow corrupted the 1TB exFat.

In all my years of using macOS, I had many unclean poweroff, and none of my hdd got corrupted (guess I didn’t use exFat back then), so this is the first time I’m experienced anything like it.

Filesystems are volatile by nature.

Even ext4 can get corrupted - there is no fail safe filesystem when you make forced shutdowns. No matter the device - always sync before removing. If in doubt execute in terminal

sync

Don’t remove the device until cache is flushed to disk.

1 Like

Well, another corruption, not the hdd itself but the filesystem and everything in it (just like the 1TB hdd above)… this time with another SSD (EXT4). I think I found what’s causing it.

There’s a video that is very old, recorded back in the 2000s. I opened it with VLC, then later I tried to unmount this SSD but couldn’t… had no idea why I couldn’t unmount it. Searched the net and found a way to find out what’s using the drive. Then I killed VLC and file.so via Task Manager. Then I was able to unmount it. So I plugged it in again to see if everything is okay, but Manjaro didn’t detect it, not even KDE Partition Manager or GParted, so I couldn’t format the SSD and had to boot into macOS and format it as ExFat and now the SSD is detected in Manjaro. (It’s a bit worrisome that Manjaro couldn’t detect the SSD but macOS could… wonder what I would do if I didn’t have macOS)

Looks like this was how the 1TB drive (ExFat) got messed up as well. Now I’m really nervous with using SSD in Linux. :smiley: Haven’t lost any important data yet, but if killing a process that is using the SSD can corrupt a HDD, it’s definitely making me anxious about what might happen in the future. Not sure if this movie file is infected with a virus or what. I have no idea.

I have 4 SSDs. The first 2 store data for use. The other two are mirrors/backup of the first two. I’m planning to use RSYNC for mirroring later on, but a bit nervous doing it at the moment until I found a way to prevent this type of hdd corruption.

I’ve been reading your post with great interest and have been waiting for answers to these type of questions:

  1. Are you using a current version of Manjaro KDE? I assumed KDE because the original post mentioned KDE Partition Manager.

  2. How are you mounting – what commands or what applications?

    • Are you using KDE’s Disk & Devices applet.
  3. Did you use lsof to find out what applications had files open on the drive?

  4. What commands are you using to unmount? Are you using sync? sync can take a long time (<>60 seconds maybe) depending on the type of data and the device.

  5. What’s being logged to the journal

    • Last boot in reverse (“q” to exit)
      journalctl -b -r

    • Or, follow the log messages as they occur (“ctrl-c” to exit). Note, start before you mount device
      journalctl -f

  6. Need to know more about your hardware:

Looks like I’ll be doing some more experiments to find out. I’m currently running Manjaro (latest and KDE Plasma) on a MBP that still has macOS intact. I boot into Manjaro via an external SSD to learn and explore Linux.

I use lsof | grep <drive> to find out what’s holding the HDD hostage. I now learn that file.so and VLC are the main apps that are holding the HDD hostage. What I do is fuser -k -9 <drive> which will kill anything that is using the HDD, in this case VLC but it can never kill file.so so I would have to do that via Task Manager. This time I learn that lsof gives the PID of the exact file.so, and so I only terminate the PID that is holding the HDD hostage. Whereas earlier I didn’t pay attention to the PID and randomly killed file.so that appeared on the screen. Not sure if killing the wrong PID caused the corruption or not because this time there’s no corruption whatsoever. In fact, I purposely did it again so that file.so held the HDD hostage, and then while the HDD is being held hostage, I shutdown the laptop by holding down the power button. Powered back on and the HDD is normal (accessed and can see files and even open them).

Hard for me to draw any conclusion at this moment, so I will have to do more tests, because this is a 1TB HDD with only 1 partition that is EXFAT. Whereas the one earlier (above your post), is an SSD that has a working Manjaro if booted from it. So that means it has two partitions (Fat32, and EXT4), and it was this one that got corrupted even after I killed file.so randomly and unmounted the drive via Disks & Devices found bottom-right of the Taskbar.

Even though this 1 TB EXFAT (1 partition total) isn’t having any problem now, yet it had problem way earlier on, see my second post in this thread. When it got corrupted, it was also EXFAT but it had 2 partitions (Fat32, and ExFat). Which makes me wonder if having two partitions will make it messier and more corruptible? I will have to conduct some experiments to find out.

Now here’s another problem. With this 1 TB HDD, that was held hostage by file.so and successfully killed and unmounted, I decided to format it via KDE Partition Manager. Only 1 partition and EXT4. Mounted it, and there is one folder: lost+found with a lock icon. I can’t create a folder or anything in this newly formatted 1 partition EXT4.

Well, I now learn that the hdd was formatted while under root access (KDE Partition Manager requires root access). And so it requires sudo to write anything on this drive. This whole users and permissions thing is new to me. So I have two questions:

  1. What do I do to make this drive writable as a regular user?

  2. If I copy files from Mac or Win filesystem to this EXT4… will I be able to access it again, let’s say 5 years later under a different Linux distro under different user/root access? Basically, what I want to know is this: Can I just copy files (regardless of where it’s coming from, and with whatever permissions encoded in these files) and not think about all this permissions stuff many years later? Or is this something I have to reconfigure and keep track whenever I move to another Linux computer/distro/user/root? In macOS and Win, people don’t have to think about file permissions.